Read the MTA-STS record a domain publishes, then paste the policy file it points at and see what it really does: enforcing or only testing, how long senders cache it, and whether it covers every mail server the domain actually uses. It runs free in your browser, with no signup and nothing stored.
Create a free Unspam account to save your results and re-run these checks anytime, so you catch a broken setup before it costs you. No credit card.
MTA-STS is how a domain tells the rest of the internet that mail arriving for it has to be encrypted, and delivered to a server whose certificate matches. Without it, SMTP encryption is opportunistic: a sender offers STARTTLS, and if anything goes wrong, an expired certificate, a capability stripped in transit, an attacker sitting in the path, it falls back to plain text rather than not delivering. That fallback is the whole problem, because it means the encryption can be switched off by anyone able to interfere with the connection. MTA-STS closes it by naming which servers may receive the domain’s mail and asking senders to refuse everything else. It is deliberately two pieces: a short DNS record at _mta-sts saying a policy exists and carrying a version id, and the policy itself, a plain text file served over HTTPS from mta-sts.example.com behind a certificate that has to validate. The DNS half is the part an attacker can tamper with, and it is the part that carries nothing worth tampering with. The policy half is the part that decides anything, and it is fetched over a channel that proves who served it.
The DNS half, and both tags are required. The version has to be spelled exactly that way, in that case, and a sender that does not find it treats the domain as having no policy rather than trying to repair the record. The id is how a sender notices the policy changed: it is compared against the one cached, so editing the file without changing the id leaves everyone on the old policy until it expires.
The only line that decides whether MTA-STS does anything. Enforce means a sender refuses to deliver over a connection it cannot authenticate. Testing means it reports the failure and delivers anyway, which is identical in outcome to having no policy at all. None means the domain is withdrawing, which is a real configuration and the documented way to retire a deployment.
How many seconds a sender may cache the policy, and the specification expects a value in weeks rather than hours. A long lifetime is the security property: once a sender has the policy, an attacker who blocks every future fetch still cannot get the domain downgraded. A short one hands them a fresh opportunity every day.
One line per mail server the policy covers, and the list is exhaustive: in enforce mode, a sender refuses to deliver to any host the list does not match. A wildcard may replace the whole leftmost label and nothing else, so *.example.com matches mx1.example.com and matches neither example.com itself nor a.b.example.com.
Testing was designed as a first step and has become a resting place. A policy in testing mode delivers exactly the mail an absent policy would, so nothing is protected, and the domain looks configured to anyone who checks only DNS. It is worth knowing that a large share of the domains publishing MTA-STS today are in testing, which is why this checker never reports a pass until the policy has been read.
A DNS record with no policy file behind it protects nothing, because senders fetch the file and find nothing to apply. A policy file with no DNS record is never fetched at all, because nothing tells a sender to look. Both halves have to be live, and the file has to be served over HTTPS with a certificate that validates for mta-sts.example.com.
Senders decide whether to re-fetch by comparing the id in DNS with the one they cached. Editing the policy while leaving the id alone means every sender that already has a copy keeps applying the old one until max_age runs out, which on a correctly long lifetime can be weeks.
This is the failure that stops mail rather than merely failing to protect it. Adding a mail server, moving to a new provider or keeping a backup MX that never made it into the policy means senders in enforce mode refuse to deliver to it. Comparing the mx lines against the MX records the domain publishes right now is the single most useful thing to check, and it is what this tool does with the policy you paste.
mx.*.example.com and *example.com are both invalid, and *.example.com does not cover example.com itself. The rule is narrow on purpose, and a pattern written the way a shell glob would be leaves the hosts it was meant to cover uncovered.
MTA-STS tells senders to refuse a connection it cannot authenticate. It does not tell you when that happened. Without a reporting record, a certificate that expires on a Friday produces silence rather than an alert, and the first signal is somebody saying their mail bounced.
