MTA-STS explained: make mail to your domain use verified TLS

Mail servers try to encrypt the connection to the next server with STARTTLS, and quietly fall back to plain text when that fails. Someone on the network path can force that fallback. MTA-STS (RFC 8461) is a policy your domain publishes so that senders deliver to you only over TLS they have verified.

The two parts

A TXT record at _mta-sts.example.com says 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 https://mta-sts.example.com/.well-known/mta-sts.txt.

A policy file for a domain with two mail servers looks like this:

version: STSv1
mode: testing
mx: mail1.example.com
mx: mail2.example.com
max_age: 86400

Testing, enforce and none

mode: testing asks senders to apply the policy but only report failures; mail is still delivered. mode: enforce tells senders to hold or bounce mail that cannot be delivered over verified TLS to one of the listed mx hosts. mode: none switches the policy off cleanly. Start in testing, and move to enforce only after the reports have been clean for a while.

max_age

max_age is how many seconds senders may remember your policy. Start with one day (86400) in testing, use one week (604800) when you first enforce, and move to 30 days (2592000) or more later. A long max_age is the protection: a sender that has your policy cached keeps enforcing it even if an attacker blocks the policy file. It is also the risk: if you break a mail server’s certificate, senders keep refusing for that long.

What your mail servers need

Every host in an mx line must present a valid certificate for its own name, from a CA that senders trust, and not expired. A self-signed certificate, a certificate for a different name or an expired one fails in enforce mode. The mx lines must also cover every host your MX records point to: an MX that is not listed cannot receive mail from senders that use MTA-STS.

The MTA-STS tool fetches the policy, compares it with your MX records and tests the certificate of each mail server.

Hosting the policy file yourself

The file must be served from the host mta-sts.example.com over HTTPS, with a valid certificate for that name, status 200 and no redirects. Any web server can do it: add an A or CNAME record for mta-sts, get a certificate, and serve one static file as text/plain. A short site block in Caddy or nginx is enough, and so is a static host. ProbeKit does not host the file for you.

Changing the policy

Senders read the file again only when the id in the TXT record changes. Edit the file, then change the id; if you forget, senders keep the old policy until max_age runs out. ProbeKit’s monitor checks that you changed the id when you changed the file.

TLS-RPT: the feedback loop

MTA-STS without reports is flying blind. A TLS-RPT record asks senders for a daily report of how many connections worked and why the others failed, so you see a broken certificate before it costs you mail. Stay in testing until the reports have shown no failures for 14 days.

ProbeKit’s builder writes the exact policy file and both records, tests each mail server first, and blocks enforce while any of them fails, because enforcing a broken setup makes mail bounce.