I moved robswain.au to MTA-STS enforce mode on 10 August, and published a policy for the second domain I run in the same week. The part worth writing down is the order I did it in.
The certificate on the policy host was issued first. Then I fetched the policy file myself and confirmed it came back as plain text, with no redirect sitting in front of it. Only after that did I publish the DNS record that tells sending servers a policy exists. Doing it the other way round takes the same amount of time and produces a domain that reads as protected and is not.
MTA-STS lives in two places. There is a TXT record at a fixed name under the domain, which tells a sending mail server that a policy exists and carries an id so the sender can tell when that policy has changed. Then there is the policy itself, a plain text file served over HTTPS from a dedicated host under the same domain, listing the mail exchangers a sender is allowed to use, the mode, and how long the policy may be cached. The record is one line of DNS and takes a minute. The file needs a hostname, a web server, a certificate that stays valid, and someone who notices when any of those three stop working.
Publish the record and skip the file and the domain reads as enabled. A DNS lookup finds the record, an inventory tool ticks the row, and the answer to the question on the form is yes. No sending server ever retrieves a policy, because there is nothing at the address the record points to, so no sending server ever requires TLS on the way in. The domain has the announcement and not the thing it announces.
This is not a hypothetical ordering mistake. URIports has now published three comparable snapshots of the top million domains, taken in the first week of 2024, 2025 and 2026. Adoption has more than doubled over that period and is still very small, 7,377 domains, or 0.7 per cent, at the start of this year. The more useful number is underneath. Roughly one in five published policies is invalid, and the single most common reason, at 34 per cent, is a missing address record for the policy host. A quarter more fail on HTTPS certificate problems. Between them those two account for well over half of everything broken, and both are the same shape, the record went up and the file behind it is unreachable.
The organisation this lands on does not find out. That is the part that separates it from most misconfigurations. When SPF breaks, mail bounces and someone rings. When the MTA-STS policy is unreachable, a sender that would have required an encrypted connection quietly falls back to whatever the receiving server offers, delivery succeeds, and the mail arrives. Nothing in the mailbox looks different. The only place that failure is visible is TLS-RPT, a second record that asks sending servers to report their transport results back to an address you nominate, and TLS-RPT is published even less often than MTA-STS is. So the reporting channel that would tell you the policy is broken is usually missing on exactly the domains whose policy is broken.
Worth saying who those organisations are. Nobody ends up with an MTA-STS policy by accident. Somebody read about it, decided it mattered and went and did the work. So the one in five holding a broken policy are not the careless end of the internet, they are the diligent end, and they are the ones with a result that protects nothing. Everybody else did not attempt it and has nothing to be wrong about.
The honest concession is that most small businesses do not urgently need this. SPF, DKIM and DMARC address someone sending mail as your domain, which is the thing that actually happens to a ten-person firm, repeatedly, usually attached to an invoice. MTA-STS addresses something else, an attacker positioned on the network path between two mail servers who strips the offer of encryption and reads what follows. That is a real attack and it is a rarer one. A firm that has not deployed MTA-STS in 2026 is not negligent, it is normal, and the sub-one-per-cent adoption figure says more about how hard the thing is to operate than about anyone's diligence. I would not put it ahead of DMARC enforcement for any business I work with.
What I would object to is the checklist version. The guidance that exists mostly treats this as a setup task, publish the record, publish the file, done. It is not a setup task. The policy file has to stay reachable indefinitely, which means the certificate on the policy host is now a mail dependency rather than a web one, and it will expire on a schedule nobody has connected to email. Changing your mail exchangers becomes an ordered operation rather than a DNS edit, because a policy that still names the old hosts will cause senders to refuse the new ones, and the cached copy outlives the change by however long the policy said it could. Backing out is not deletion either. Removing the record does not retract a policy that senders are still holding. Each of those is a way for a domain that was configured correctly on Tuesday to be failing silently by the following quarter, with the record still sitting there answering yes.
There is a version of this that has nothing to do with mail. The pattern is a protection whose enabled state is recorded in one system and whose working state lives in another, with no path between them. DMARC at p=none is the same shape, the record is published, the policy asks for nothing. A backup job that reports success having written a zero-byte file is the same shape. Windows folder redirection logging a successful redirect for files that never moved is the same shape, and I have spent more of my career on that one than I would like. In each case the check and the thing being checked sit in different places, and the check is the one that gets looked at, because it is the one that is easy to look at.
The second of my two domains sits in testing mode until 17 August. Testing mode publishes the record, serves the file, and asks sending servers to report what they found and to change nothing about how they deliver. For this week the domain has the entire apparatus and none of the protection. That is the correct way to do it, a week of reports is what tells you the policy is right before you make it binding, and it is also indistinguishable from the outside from a domain that stopped there and never went back.