MTA-STS and TLS-RPT Explained

The problem with opportunistic TLS

When a sending server, or MTA, delivers mail to example.com, it looks up the MX records, connects to one of those hosts on port 25, and issues STARTTLS if the server advertises it. Two weaknesses follow from that design. First, the STARTTLS advertisement travels in clear text, so an active attacker can remove it and the sender will fall back to unencrypted delivery. Second, most senders do not check the certificate against the MX host name, because historically too many legitimate servers had self-signed or mismatched certificates.

Neither weakness can be fixed by the receiving server alone. The sender needs some trusted signal, obtained in advance, that says this domain always supports valid TLS. MTA-STS and DANE are the two standards that provide that signal. DANE uses DNSSEC and is covered in DANE for Email. MTA-STS uses HTTPS and the ordinary web certificate system instead.

How MTA-STS works

An MTA-STS deployment has two parts that must agree. A TXT record at _mta-sts.example.com announces that a policy exists and carries an id that changes whenever the policy changes. The policy itself is a small text file served over HTTPS at a fixed location on the host mta-sts.example.com.

$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20261015T090000;"

$ curl -s https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
mx: *.mail.example.net
max_age: 1209600

Each mx line lists a host the sender may deliver to, and a leading *. matches one label, so *.mail.example.net covers hosts such as in1.mail.example.net. The max_age is in seconds; the example is two weeks, and RFC 8461 caps it at about one year. Because the policy is fetched over HTTPS from a host in your own domain, an attacker would need a valid certificate for mta-sts.example.com to forge it.

The model is trust on first use. A sender that has never seen your policy cannot be protected on that first delivery, but once it has cached a policy, a later attacker cannot remove it by tampering with DNS, because the cached policy stays valid until max_age runs out.

How TLS-RPT works

TLS-RPT is a single TXT record at _smtp._tls.example.com that names where reports should go. The destination can be a mailto: address or an https: endpoint.

$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Participating senders send one aggregate report per day as compressed JSON. Each report lists the policy the sender applied, whether MTA-STS, DANE TLSA, or no policy found, together with counts of successful and failed sessions and a breakdown of the failures. An excerpt looks like this:

{
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-domain": "example.com",
      "mx-host": ["mx1.example.com", "mx2.example.com"]
    },
    "summary": {
      "total-successful-session-count": 4120,
      "total-failure-session-count": 3
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "receiving-mx-hostname": "mx2.example.com",
      "receiving-ip": "192.0.2.25",
      "failed-session-count": 3
    }]
  }]
}

Result types tell you what to fix. certificate-host-mismatch means the certificate does not cover the MX name, certificate-expired and certificate-not-trusted point at the certificate itself, starttls-not-supported means a host did not offer TLS, and sts-policy-fetch-error or sts-policy-invalid mean the policy file could not be retrieved or parsed.

A safe rollout plan

1. List every MX host and confirm each presents a certificate from a public CA that covers its exact MX name, with automated renewal.
2. Publish the TLS-RPT record and confirm reports start arriving.
3. Stand up mta-sts.example.com with a valid HTTPS certificate and publish the policy in testing mode with a short max_age, such as one day.
4. Publish the _mta-sts TXT record with a new id.
5. Read reports for a few weeks. Fix every recurring failure.
6. Switch to enforce, raise max_age to weeks, and change the id.

1. Well before the move, publish a policy that lists both the old and the new MX hosts, and change the id. RFC 8461 asks you to update the HTTPS policy file first and the TXT record second, so a sender that sees the new id can fetch the new file.
2. Wait out the old policy. A sender that has not mailed you since it cached the old policy may still hold it until that policy's max_age runs out. If the old policy had a max_age of several weeks, start this step several weeks ahead. If you want a shorter wait, lower max_age (or switch to testing) early enough for the older, longer-lived copies to expire first.
3. Make sure the new hosts pass, with certificates that cover their exact MX names, before any sender is told to use them.
4. Change the MX records, and keep the old hosts accepting mail for at least the MX TTL, since senders with cached MX answers may still send there. The policy is an allow list, not a routing list: an old cached policy does not send mail to the old hosts, but if it does not list the new ones, delivery to them can be delayed until the sender fetches the new policy.
5. Remove the old hosts from the policy last, with a new id, once reports show no deliveries are still going to them.

The same reasoning applies when you retire MTA-STS: RFC 8461 section 8.3 says to publish a policy with mode: none and a short max_age, wait for the longest old max_age to pass, and only then remove the TXT record and the HTTPS host.

Remember that the HTTPS host is now part of your mail path. If mta-sts.example.com becomes a dangling CNAME to a retired web service, the policy fetch fails and, worse, someone else may be able to serve a policy for your domain.

MTA-STS vs DANE

The two can coexist. RFC 8461 says a sender that implements both must not let an MTA-STS policy override a failing DANE validation, so DANE stays in charge wherever a sender uses it. Publishing both gives the widest coverage, since different large senders implement different subsets.

How DNS Panopticon helps

Domain Visualizer is the tool for mail records. Its scan asks public resolvers for the _mta-sts and _smtp._tls TXT records, the MX records and their addresses, SPF, DMARC, DKIM at two common selectors, and DANE TLSA records at _25._tcp for each MX host. A missing MTA-STS record is reported as an informational finding. Visualizer reads DNS only: it does not fetch the policy file or test STARTTLS, so use the curl command above to check that the policy is served and matches your MX list. Results are cached (24 hours by default), so look at the scan time after an MX change.

Website Recon covers websites and registration and deliberately leaves mail records to Visualizer. For signing, see DKIM Explained: Selectors and Key Rotation.