MTA-STS and TLS-RPT

Mail between servers is encrypted opportunistically. A sending server asks the receiving server whether it supports TLS, and uses it if the answer is yes. The weakness is that the question is asked in plain text. An attacker on the network path can strip the offer, and the sender then falls back to delivering the message unencrypted, with no warning to anyone. Mail is also delivered to whichever server DNS names, so a forged answer redirects it altogether.

MTA-STS closes this by letting you publish a policy that says: these are my mail servers, and senders must reach them over TLS with a valid certificate or hold the message. The policy is fetched over HTTPS, so an attacker cannot rewrite it the way they can a plain mail exchange. TLS-RPT is its companion: it asks senders to send you a daily summary of the deliveries that failed, which is how you find a broken certificate before mail is lost.

The two records and the policy file

_mta-sts.example.com.   TXT  "v=STSv1; id=20260101T000000"
_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

The policy itself is a text file served at https://mta-sts.example.com/.well-known/mta-sts.txt, over HTTPS with a certificate that is valid for that hostname:

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

• •mode — testing (deliver anyway, but report failures), enforce (refuse to deliver if TLS cannot be validated) or none (switch the policy off).
• •mx — one line per permitted mail server. Every host in your MX records must match one of them, or senders will refuse to deliver.
• •max_age — how long, in seconds, senders may cache the policy. A week or more is typical. Caching is what makes the policy hold even when an attacker blocks the fetch.
• •id — in the DNS record, a string that you change whenever the policy changes. Senders only re-fetch the file when the id differs.

Rolling it out

Publish TLS-RPT first and use testing mode for a few weeks. Read the reports to find mail servers or certificates that do not validate, fix them, and only then move to enforce. Going straight to enforce with a mail server whose certificate has expired means senders will queue and eventually bounce your mail.

Common failure modes

• •The TXT record is published but the policy file is not served, or is served with an invalid certificate. Senders then ignore the policy, so you have the appearance of protection and none of the substance. Surface fetches the file for this reason.
• •Changing the policy without changing the id, so senders keep using the cached version.
• •A mail host missing from the mx lines after a provider change, causing deliveries to be refused in enforce mode.
• •Publishing MTA-STS on a domain that receives no mail. It has no effect there, which is why Surface treats it as not applicable for domains that declare no mail.