MTA-STS: a verifiable TLS policy for your mail transport

The policy protects transport only where the sending mail server supports it and has obtained a valid policy. It replaces neither sender authentication through SPF, DKIM and DMARC nor end-to-end encryption of message content.

Why STARTTLS alone leaves a gap

DNS signal, HTTPS policy and SMTP verification

For ordinary direct delivery to person@example.com, example.com is the policy domain. Explicit routing rules to a smart host can change the next transport hop and thus policy selection. A policy for the main domain is not automatically sought for every subdomain: a different policy domain requires its own queries. RFC 8461 §3.4

The DNS record announces a version

The following synthetic zone example uses example domains only. It has not been published or tested in practice.

_mta-sts.example.com. IN TXT "v=STSv1; id=2026091301"

v=STSv1 comes first. The id consists of 1 to 32 letters or digits and must uniquely identify the relevant policy version. A date format is possible but not required; a new time or sequential identifier can distinguish several changes on the same day. A larger number has no special meaning in the protocol.

After discarding unrelated TXT records, exactly one matching, syntactically valid record must remain. Multiple strings within the same TXT record are concatenated without extra spaces. Discovery can also be delegated through a CNAME. However, a missing or unusable record does not delete a previously valid cached policy. RFC 8461 §3.1

The policy comes from a fixed HTTPS destination

For this example domain, the full address is:

https://mta-sts.example.com/.well-known/mta-sts.txt

This HTTPS host's certificate must match the name mta-sts.example.com, be valid and chain to a certification authority trusted by the sender. A CNAME pointing to a hosting provider does not change the name to be checked. The response must return HTTP 200 directly; redirects must not be followed when retrieving the policy. The file should be served as text/plain; RFC 8461 describes the sender's media type check as a SHOULD. An HTML error page is not a policy. RFC 8461 §3.2–3.3

Synthetic file example for a testing phase with two intended MX hosts:

version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

mx: *.example.com matches exactly one additional leftmost label, such as mail.example.com. It matches neither example.com nor a.mail.example.com. Use several mx: lines for several names. For internationalised domain names, the policy expects the ASCII representation as an A-label. The example value 86400 is one day; it is not a mandatory default.

For the SMTP MX, the sender separately checks whether its name matches the policy, STARTTLS is usable and a valid certificate with a trusted chain matches the actual MX hostname. The policy's HTTPS certificate and the MX's SMTP certificate are two separate pieces of evidence. RFC 8461 §4–5.1

Understand testing, enforce and none

enforce is an operational commitment you make deliberately. An MX name that no longer matches, an expired certificate or absent STARTTLS can prevent transmission. This also applies to a rarely used backup MX. Uneventful traffic to the primary MX is not evidence for every fallback route. RFC 8461 §8.4

TLS-RPT: understand reports on transport attempts

TLS-RPT is described in RFC 8460, separately from MTA-STS. Supporting senders can transmit aggregate information about TLS connections and policy problems. The receiving domain publishes a reporting destination for this purpose. It can help during introduction, but does not provide complete observation of all senders or messages.

A synthetic DNS example for a receiving mailbox set up beforehand:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Multiple destinations are possible, shown here as an alternative example configuration with an HTTPS receiver already set up:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://reports.example.com/tlsrpt"

Enter only destinations for whose reception and analysis you are responsible or have an appropriate agreement. With several destinations, a reporting sender may select one; not every destination necessarily receives every report. A statically hosted policy file is not an HTTPS report receiver. RFC 8460 §3, verified erratum 8070

Reporting period, counts and transmission

A report contains a period, identifier, information about the reporting operator, the observed policy and aggregate results. A full UTC day is the standard's recommendation. Delayed transmission and missing reports are possible. Success counts refer to the corresponding TLS sessions, not messages received in an inbox. Failure categories can overlap; they cannot be added arbitrarily to produce a count of independent failed messages. RFC 8460 §4

Special rules apply to report transport: emailed reports need a valid DKIM signature from the reporting domain without an l= limit. In RFC 8460, s=tlsrpt on the DKIM key is a SHOULD, not a general additional MUST; open or held errata concern its registration. Absence of a valid DKIM signature is a different case. When transmitting failure reports, SMTP TLS problems must not themselves suppress the report; the report may be transmitted unencrypted as a result. For HTTPS reports, the standard permits the sender to ignore certificate errors. This exception does not apply to HTTPS retrieval of the MTA-STS policy. RFC 8460 §3, erratum 8303, status Reported

Reports may arrive as JSON or compressed with gzip. An HTTPS receiver must return a successful response, typically 200 or 201; processing may follow later. Neither successful HTTP acceptance nor an existing email attachment proves completed analysis. TLS-RPT reports are not Wolf report files.

An invented report as a reading aid

The following JSON model shows a single policy version and one failure type. The operator name, identifier, reporting period, addresses and all numbers are invented. It is neither a received report nor test evidence; the email/HTTP envelope is not shown.

{
  "organization-name": "Example Sender",
  "date-range": {
    "start-datetime": "2026-09-11T00:00:00Z",
    "end-datetime": "2026-09-12T00:00:00Z"
  },
  "contact-info": "postmaster@sender.example.net",
  "report-id": "example-report-01",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mx1.example.com",
          "max_age: 604800"
        ],
        "policy-domain": "example.com",
        "mx-host": ["mx1.example.com"]
      },
      "summary": {
        "total-successful-session-count": 120,
        "total-failure-session-count": 2
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "192.0.2.10",
          "receiving-mx-hostname": "mx1.example.com",
          "receiving-ip": "203.0.113.20",
          "failed-session-count": 2
        }
      ]
    }
  ]
}

In the model, the report describes an expired certificate in two recorded sessions. It proves neither the cause of every missing message nor an attack. Investigation should consider the stated period, affected host, policy at the time and relevant server logs.

Assign failure labels precisely

These categories do not replace root cause analysis. A report need not include every transient network error. A syntactically valid policy can also exclude a needed MX; a syntax check alone is insufficient. RFC 8460 §4.3

Plan introduction, changes and removal

The time needed for introduction depends on your infrastructure and the observations actually available. Two error-free calendar weeks alone establish neither sender coverage nor a working backup MX.

When making a change, publish the new HTTPS policy first, followed by the new DNS id. A DNS update alone does not replace every sender's cache. Longer max_age values can preserve the requirement through retrieval outages, but also prolong the possible effect of old rules. A new, shorter lifetime does not retroactively shorten every previously cached policy. RFC 8461 §8.1

For planned removal, the standard provides mode: none. Publish this valid policy with a short lifetime and a new id. Keep DNS and the HTTPS endpoint available until all previously served policies have expired. This may include older versions with longer lifetimes. Immediately deleting the TXT record and file is not reliable removal. RFC 8461 §8.3

MTA-STS and DANE use different trust models

MTA-STS is neither a replacement for DNSSEC nor certificate pinning. SMTP DANE, in turn, is not end-to-end encryption. Which option a provider supports for inbound and outbound messages needs separate checking. Read your sending service's specific documentation, including the connectors and routing cases used. RFC 8461 §2, RFC 7672 §3

Limits of the evidence: transport, law and check results

MTA-STS can make a limited contribution to protecting the transport path. It neither authenticates the visible sender nor assesses message content. Encrypted transport does not make a phishing message harmless. More context: email threats and DNS security.

Legal requirements depend on scope and risk. Article 21 NIS2 calls for appropriate risk management measures, including cryptography, from covered entities; article 32 GDPR addresses security of processing appropriate to risk. Neither supports a blanket claim that every domain must specifically use MTA-STS. BSI TR-03108 addresses email service providers and describes its own requirements for secure transport. A single policy or scan is not certification of compliance with these rules. This interpretation concerns the cited EU/German sources, not a worldwide legal assessment. NIS2 article 21, GDPR article 32, BSI TR-03108

The free Email Security Check examines published DNS records, the retrievable MTA-STS policy and its coverage of the DNS MX names known to the check. This proves neither actual enforcement by every sender nor TLS connections to every MX address or the state of other senders' caches. The TLS-RPT DNS check reads reporting destinations; it does not receive or analyse JSON reports or confirm report delivery. A retrieval or measurement failure must be distinguished from a confirmed misconfiguration.

A free finding may be enough for your next correction. To verify a change, add the specific operational evidence needed; DNS observations, policy retrieval, SMTP connection and a received report remain separate pieces of evidence.

Related fundamentals

Previous chapter: DMARC enforcement. Next chapter: SMTP TLS and certificates.