Three of thirty companies tell the internet to encrypt their mail. On one of the three, the instruction cannot be read.
SPF, DKIM and DMARC answer who sent the message. None of them says the connection has to be encrypted. I went to see who bothers with the record that does.
- Of 30 SaaS domains, 27 publish no MTA-STS record at all. Asana and Mixpanel serve a working policy in enforce mode.
- Cloudflare publishes a valid DNS record pointing at a policy host that does not resolve on any of three public resolvers, so nothing enforces anything.
- On apple.com the _mta-sts record exists and contains an SPF record, which is a different protocol entirely.
- Every large mailbox provider I checked has this switched on: Gmail, Google, Outlook and Microsoft in enforce, Yahoo and Fastmail in testing.
- Mixpanel caches its policy for one day. RFC 8461 expects weeks or more, and the short window is exactly when a downgrade attempt would work.
Somebody on a call asked me whether their invoices travel encrypted. I said almost certainly yes, because everything does now. Then I went to check, and the honest answer turned out to be that nobody involved actually knows.
STARTTLS is opportunistic. The sending server asks whether encryption is available, and if the answer never arrives, it delivers in plain text anyway. Nothing warns anyone. Both mail logs say delivered.
MTA-STS is the fix. A domain publishes a TXT record, serves a small policy file over HTTPS, and senders that support it are then required to use validated TLS to the named hosts or not deliver at all.
So I checked thirty SaaS domains that send a great deal of mail. Payment platforms, help desks, email tools, hosting.
Three had the record. Twenty-seven had nothing.
Then the mailbox providers, as a control. Gmail, Google, Outlook and Microsoft all run enforce. Yahoo and Fastmail run testing, which reports failures without acting on them.
Read those two groups next to each other. The companies receiving your mail have decided this matters. The companies sending mail on your behalf, in twenty-seven cases out of thirty, have not published the record that would let anyone insist.
The one that looks fine and is not
Cloudflare publishes v=STSv1;id=1769609691387; at _mta-sts.cloudflare.com. Correct syntax. A checker that reads DNS and stops there will show a green tick.
The policy lives at mta-sts.cloudflare.com, and that name does not resolve. I asked 1.1.1.1, which is their own resolver. Nothing. I asked 8.8.8.8 and 9.9.9.9. Nothing, no A record and no CNAME.
A sending server that cannot fetch the policy has no policy to apply, so it falls back to opportunistic TLS, which is where we came in. The DNS record is a note saying the rules are on the noticeboard, and the noticeboard is missing.
Apple is odder. There is a TXT record at _mta-sts.apple.com and it reads v=spf1 redirect=_spf.apple.com. That is an SPF record, sitting at the name reserved for a different protocol. Somebody, at some point, pasted something into the wrong row of a DNS panel, and it has been sitting there since.
The detail I nearly skipped
Asana and Mixpanel both serve a real policy in enforce mode, both naming the same five Google MX hosts.
Asana sets max_age: 31557599. That is a year, one second under the maximum the specification allows.
Mixpanel sets 86400. One day.
RFC 8461 says the value is expected to be in the range of weeks or greater, and gives the reason: the gap at refresh time is the moment an attacker has something to work with. A policy cached for a year survives a bad afternoon on your policy host. A policy cached for a day expires during one.
Not wrong. Not broken. Just a setting that gives away most of what the protocol was built to protect, and it takes one line to change.
Checking your own
Four commands, no tools:
dig +short TXT _mta-sts.yourdomain.com should return something starting v=STSv1.
curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt should return the policy. If it hangs, you have Cloudflare’s problem.
dig +short TXT _smtp._tls.yourdomain.com returns your TLS-RPT address, which is where failure reports go.
And read your own max_age while you are there.
Twenty-seven of thirty will have nothing to check, and that is the expected result rather than a scandal. What I have not worked out is why the three who did the work split the way they did: two of them configured it properly, and the third left a pointer to a host that has never existed as far as any resolver I asked is concerned. Somebody built that record on purpose. Then something else happened, and nobody was watching the part where it stopped.
Questions people ask about this
What does MTA-STS actually do?
It lets a domain say that mail sent to it must arrive over a validated TLS connection to a named set of MX hosts. Without it, STARTTLS is opportunistic: an attacker in the path can strip the offer of encryption and the sending server will deliver in the clear without telling anyone.
Is this the same as the padlock on a website?
The idea is similar, the failure mode is not. A browser shows the user when HTTPS is missing. In SMTP nobody is watching at the moment of delivery, so a downgraded connection looks exactly like a normal one from both ends.
Do I need it if I already have DMARC?
They answer different questions. SPF, DKIM and DMARC tell the receiver whether the message is really from you. MTA-STS tells the sender whether the pipe has to be encrypted. You can pass all three authentication checks over a connection that was never encrypted at all.
What do I need to publish it?
A TXT record at _mta-sts.yourdomain, a plain text policy file served over HTTPS at mta-sts.yourdomain, and a certificate on that host. Then a TLS-RPT record if you want to hear about failures. The policy file names your MX hosts, so it has to be updated when they change.
What about DANE, is that the same thing?
It solves the same problem a different way. DANE, defined in RFC 7672, puts the certificate fingerprint in DNS and relies on DNSSEC to make that record trustworthy. MTA-STS relies on the web certificate system instead, which is why it is easier to deploy and why a broken policy host takes the whole thing down. Nothing stops you running both.
Why does the policy host being down matter so much?
Because a sending server that cannot fetch a policy has nothing to enforce and falls back to opportunistic TLS. The record in DNS looks correct on every checker that only reads DNS. That is what makes this failure quiet.
- RFC 8461, SMTP MTA Strict Transport Security. Checked 2026-09-19.
- RFC 8460, SMTP TLS Reporting. Checked 2026-09-19.
- RFC 3207, SMTP Service Extension for Secure SMTP over TLS. Checked 2026-09-19.
- Google Workspace Admin Help, Set up MTA-STS and TLS reporting. Checked 2026-09-19.
- RFC 7672, SMTP Security via Opportunistic DANE TLS. Checked 2026-09-19.
- Google, Email sender guidelines. Checked 2026-09-19.
- Own measurement, 30 SaaS domains and 8 mailbox providers, 18 and 19 September 2026. Checked 2026-09-19.
Run the same check on your own domain. It reads live DNS, the same records Gmail reads, and tells you which of the three is missing.
Check your domain free → Open the glossary