MTA-STS and TLS-RPT: Encrypting Email in Transit

Most email between mail servers is now encrypted, but in a way that can be quietly switched off by anyone positioned in the middle of the connection. MTA-STS (Mail Transfer Agent Strict Transport Security) lets your domain tell sending servers: "only deliver my mail over a properly verified, encrypted connection". Its companion, TLS-RPT, sends you reports when that fails. Together they close a long-standing gap in email security, and they need nothing more than two DNS records and a small text file on a web server.

The problem: opportunistic encryption

When one mail server delivers to another on port 25, it connects in plain text and checks whether the receiver offers STARTTLS. If it does, the two switch to an encrypted connection. If it does not, the sender usually delivers the message unencrypted anyway, because refusing would break mail with servers that do not support TLS.

That fallback is the weakness. An attacker who can interfere with the connection can strip the STARTTLS offer from the receiving server's response, and the sender will carry on in plain text. Even when TLS is used, senders often do not verify the receiving server's certificate, so a connection could be encrypted to an impostor. This is called a downgrade attack, and opportunistic TLS cannot detect it.

How MTA-STS fixes it

MTA-STS, defined in RFC 8461, lets a receiving domain publish a policy saying:

• which host names are its legitimate MX servers,
• that those servers must present a valid certificate, issued by a trusted authority and matching the host name, and
• whether senders should refuse to deliver if those conditions are not met (enforce) or just report it (testing).

The policy is fetched over HTTPS, which an attacker on the mail path cannot tamper with without a valid certificate for your domain, and senders cache it for a period you specify. Major mailbox providers, including Google and Microsoft, honour MTA-STS when delivering to domains that publish it.

The three pieces of MTA-STS and TLS-RPT

Step 1: List your MX hosts and check their certificates

Look up your MX records with the DNS lookup tool. Every MX host needs a valid TLS certificate covering its name. Hosted providers such as Google Workspace and Microsoft 365 already have this. If you run your own mail server, check it with:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Look for a certificate chain that verifies and a name that matches. An expired or self-signed certificate here would cause mail to be refused once you enforce.

Step 2: Publish the policy file

Create a host named mta-sts under your domain, with a valid HTTPS certificate, and serve this file at /.well-known/mta-sts.txt with a text/plain content type:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.mailprovider.net
max_age: 604800

• mode: testing (report only), enforce (refuse non-compliant delivery) or none (policy withdrawn).
• mx: one line per permitted MX host; a leading *. wildcard matches one label.
• max_age: how long senders may cache the policy, in seconds. 604800 is one week; the maximum is 31557600, about a year.

Any small static web host works. The file must be reachable without redirects, and the mta-sts host name's certificate must be valid. Confirm with the SSL checker.

Step 3: Publish the DNS records

_mta-sts.example.com.     TXT  "v=STSv1; id=20261003001"
_smtp._tls.example.com.   TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

The id is any short alphanumeric string. Senders use it to notice when your policy has changed, so change the id every time you edit the policy file; a date-based value makes this easy.

The TLS-RPT record (RFC 8460) asks senders to email you a daily JSON report summarising successful and failed TLS connections to your mail servers, with failure reasons such as certificate expiry, host name mismatch or STARTTLS not offered.

Step 4: Test, then enforce

1. Run in testing mode for a few weeks. Mail is delivered as usual, but senders report problems through TLS-RPT.
2. Review the reports. Failures should be zero or explained.
3. Change mode: enforce in the policy file and update the id in DNS.
4. Keep reviewing reports. When you change mail providers, update the mx lines before changing MX records, and update the id.

Things that can go wrong

• Forgetting MTA-STS during a provider migration. Senders with a cached enforce policy will refuse to deliver to new MX hosts not listed in it. Add the new hosts to the policy, bump the id and allow time for caches before switching MX.
• Letting the mta-sts web certificate expire. Senders cannot fetch a fresh policy. Automate renewal.
• Mail server certificate expiry under an enforce policy, which blocks inbound mail from compliant senders.

MTA-STS or DANE?

DANE (RFC 7672) achieves a similar goal using TLSA records secured by DNSSEC instead of an HTTPS-hosted policy. It is stronger in some respects but requires DNSSEC on your domain and support from the sender. Some organisations deploy both; for many businesses without DNSSEC, MTA-STS is the practical starting point.

Key takeaways

• Opportunistic STARTTLS can be silently downgraded; MTA-STS lets you require verified TLS for inbound mail.
• You need a TXT record at _mta-sts, a policy file on https://mta-sts.yourdomain, and ideally a TLS-RPT record.
• Start in testing mode, read TLS-RPT reports, then enforce.
• Update the policy and its id before any change of mail servers.