From no MTA-STS to enforce, without blackholing your own mail

SMTP encryption is opportunistic by default. Two mail servers try TLS, and if anything goes wrong, a bad certificate, a stripped STARTTLS, an attacker in the middle, they quietly fall back to plain text and deliver anyway. The mail arrives. Nobody notices. That's the problem MTA-STS exists to fix.

The catch is that MTA-STS in enforce mode can refuse to deliver mail to you if you get the setup wrong. So you don't flip it on. You stage it, and you read the reports before you commit.

What are the two records doing?

There are two pieces, and they do different jobs. People conflate them.

TLS-RPT is the reporting channel. It's a TXT record that asks other mail servers to send you a daily JSON report of how their TLS connections to your domain went: the successes, the failures, and crucially why anything failed.

_smtp._tls.yourdomain.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

MTA-STS is the policy. It tells sending servers "you must use TLS with a valid certificate to deliver to me, and here are my real MX hosts." It lives in two places at once: a TXT record that advertises the policy and its version, and an actual policy file served over HTTPS.

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260618000000"

# https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: yourdomain-com.mail.protection.outlook.com
max_age: 604800

The single most important thing to understand: TLS-RPT works on its own and risks nothing, while MTA-STS is the one that can break delivery. That ordering is your whole rollout plan.

The staged plan

Four stages. Don't compress them.

Stage one is to publish TLS-RPT and wait. Just the reporting record. It changes nothing about delivery; it only asks senders to tell you how TLS is going. Leave it for a week or two and let reports accumulate. You'll want a mailbox or a parser ready, because the reports come as JSON, not prose.

Stage two is to publish MTA-STS in mode=testing. Testing mode is the clever bit. You publish the full policy, MX list and max_age and everything, but with mode: testing a sending server that hits a TLS problem will still deliver the mail and also report the failure. You get all the signal of enforcement with none of the risk. This is where you live for at least a couple of weeks.

Stage three is to read the reports and fix what they show. Now the TLS-RPT data earns its keep. Every failure report tells you about a sender who would have been blocked under enforce. Certificate mismatch? MX host not in your policy? You find out here, in safety, while mail still flows.

Stage four is to switch to mode: enforce. Only when testing mode has been quiet for a sustained period. Change mode: testing to mode: enforce in the policy file, and this is the part everyone forgets, bump the id in the TXT record so senders re-fetch the policy.

What actually goes wrong?

The failure modes are boringly consistent. Here are the ones that cost real afternoons.

The policy file 404s. The TXT record advertises a policy, but https://mta-sts.yourdomain.com/.well-known/mta-sts.txt returns nothing, or returns your website's HTML 404 page with a 200 status. The mta-sts. subdomain is a real host that needs real hosting and a valid certificate. A surprising number of setups stop at the DNS record and never serve the file.

The certificate on mta-sts. is wrong. The policy file must be served over HTTPS with a certificate valid for mta-sts.yourdomain.com. A wildcard that doesn't cover it, or an expired cert, and senders can't read the policy.

The id never changes. Senders cache your policy and only re-fetch when the id in the TXT record changes. Edit the policy file but leave the id alone, and your change is invisible for up to max_age seconds. Every policy edit needs a new id. A timestamp is the conventional choice for exactly this reason.

The MX list drifts. Your policy file lists your MX hosts. Change mail providers, add a host, or let the policy go stale, and a legitimate MX is suddenly not in the policy. Under enforce, mail to that host is refused. This is the classic way a forgotten MTA-STS policy blackholes mail months after anyone touched it.

Under enforce, an MX host that isn't listed in your policy file is treated as an attack. The sending server does the right thing and refuses to deliver. The "attacker" is you, six months ago, who changed providers and forgot the policy file existed.

Real scenarios

Take Microsoft 365, single tenant. That's the easy case. Your MX is one *.mail.protection.outlook.com host, Microsoft's certificates are valid, and the policy file is short. The only real work is hosting the mta-sts. subdomain and its file, and many teams use a small static host or a worker for exactly this. Testing mode will almost always be quiet within days.

Now take a mixed setup: hosted mailboxes plus an on-prem or appliance relay. This is where you earn your keep. Every MX host must be in the policy, and every one must present a valid certificate. The appliance relay nobody has touched since 2019, still presenting the self-signed cert it was born with, is precisely what testing mode will flag, and precisely what would have blackholed a slice of your mail under enforce. It has survived three IT managers. Do not let it survive stage four.

Our take

MTA-STS is worth doing, and it's safe to do if you respect the staging. The temptation is to publish enforce on day one because the docs make it look like three records. Resist it. Enforce-on-day-one is how you discover, in production, which of your senders were held together with optimism. The testing-mode window is not bureaucratic caution. It's the only place you find out which of your senders would break, while it's still free to find out.

What to do

1. Publish TLS-RPT first. One TXT record, zero delivery risk. Confirm it with the TLS-RPT checker and start collecting reports.
2. Stand up the mta-sts. host with a valid certificate and the policy file at /.well-known/mta-sts.txt, in mode: testing.
3. Live in testing mode for a couple of weeks. Read every failure report. Fix every flagged sender.
4. Switch to enforce and bump the id. Then verify the live policy with the MTA-STS checker.
5. Put a reminder on the MX list. Any time you change mail providers, update the policy file and the id in the same change. Stale policies are the thing that bites you a year later.