97.8% of the top 10,000 domains have no MTA-STS. Here's how to be in the other 2%

Of the 10,000 most-visited domains on the web, 97.8% have no MTA-STS policy at all. Not misconfigured. Not weak. Just absent. I scanned the Tranco top 10,000 in June and MTA-STS is the single most-ignored email-security control I measured, by a wide margin.

For comparison, in the same scan a third of those domains had no DMARC, which people already treat as a problem worth writing about. Missing MTA-STS is nearly three times as common as that, and almost nobody mentions it.

What MTA-STS actually protects

SMTP encryption is opportunistic. When one mail server hands a message to another, it tries STARTTLS to upgrade the connection to TLS, but if the upgrade fails it usually just delivers in plaintext instead of refusing. That fallback is the hole. An attacker positioned between the two servers can strip the STARTTLS offer, or present a bad certificate, and the sending server shrugs and delivers over an unencrypted connection anyway. The mail goes through, and nobody sees a downgrade happen.

MTA-STS (RFC 8461) closes that hole. You publish a policy that says, in effect, "mail for my domain must be delivered over TLS, to a server whose certificate actually validates and matches one of my listed MX hosts." A sending server that supports MTA-STS reads that policy and, in enforce mode, refuses to deliver if the connection can't be secured. Downgrade stripped? Certificate wrong? The message is held, not leaked.

TLS-RPT (RFC 8460) is the companion. It's a DNS record that asks other providers to send you a daily report of how TLS negotiation went for mail to your domain, including failures. It's how you find out something is wrong before it becomes a habit. In the scan, 97.1% of domains had no TLS-RPT record either, so almost everyone who skips the policy also skips the reporting that would tell them they need one.

Why adoption is this low

Two reasons, and neither is that MTA-STS is hard to understand.

The first is moving parts. DMARC is one DNS record. MTA-STS is a DNS record plus a policy file served over HTTPS at a fixed well-known URL on a dedicated subdomain, plus your MX hosts presenting valid certificates that match the policy. That's a web endpoint, a DNS entry, and mail-server TLS all having to agree. None of it is difficult, but it's more surface than pasting one TXT record, and more surface is where adoption goes to die.

The second is that nothing forced it. DMARC adoption jumped when Google and Yahoo made authentication a requirement for bulk senders, a hard deadline with deliverability consequences. MTA-STS has no equivalent forcing function. No inbox provider bounces your mail for lacking it, so it sits permanently at the bottom of the list, behind every task that has a deadline attached.

Here's the part that surprised me: it isn't a small-domain problem. Among the top 1,000 domains, 96.9% still have no MTA-STS, barely better than the long tail. And the few that do adopt it tend to mean it. Of the roughly 220 domains publishing a policy, 59% run it in enforce mode and most of the rest in testing. So this isn't a case of people turning it on and leaving it half-configured. It's a case of almost nobody turning it on at all.

How to be in the other 2%

The rollout mirrors DMARC's, and you should treat it the same way: report first, enforce later.

1. Stand up the policy file. Serve https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with your MX hosts listed, max_age set, and start at mode: testing. Testing mode changes nothing about delivery yet; it just makes your policy visible.
2. Publish the DNS record. Add the _mta-sts TXT record with a version and an id. You bump the id whenever the policy changes so senders know to refetch.
3. Turn on TLS-RPT. Add the _smtp._tls TXT record pointing at a mailbox. Now you get reports about TLS successes and failures to your domain.
4. Read the reports, then enforce. Watch a couple of weeks of TLS-RPT data. If your MX hosts are negotiating TLS cleanly, flip the policy from testing to enforce. If something's failing, you'll see it in the reports before it can hurt you, which is the whole point of starting in testing.

The certificate on your MX hosts has to be valid and has to match a name in your policy, so the most common snag is a mail server with a self-signed or mismatched cert that was fine under opportunistic TLS and isn't fine under a policy that checks. Testing mode surfaces exactly that, which is why you don't skip it.

The takeaway

MTA-STS is the rare control where the hard part is genuinely just doing it. The spec is stable, the failure mode it prevents is real, and adoption is at 2% not because it's controversial but because nothing makes anyone finish it. If you already run DMARC, you've done the harder conceptual work; MTA-STS is mostly plumbing on top. The 2% who bothered aren't smarter, they just got to it.

I published the full aggregate from this scan as an open dataset (SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI across the Tranco top 10,000, aggregate only) here: https://github.com/relaymetry/state-of-email-authentication — it's CC BY 4.0, so use the numbers however you like.

Disclosure: I'm the founder of Relaymetry, a free SPF/DKIM/DMARC/MTA-STS checker. If you want to check your own domain's MTA-STS policy and TLS-RPT record, Relaymetry walks through it here, no signup required.