Two parts that have to line up
MTA-STS consists of two separate things in two separate places. In DNS, _mta-sts.<domain> holds nothing but a pointer with a version identifier. The actual policy is a text file that has to be served from https://mta-sts.<domain>/.well-known/mta-sts.txt — from a hostname of its own, with a valid certificate.
That split is the most common source of failure: the DNS record is set, while the file is missing or answers with a redirect, a 404 or an expired certificate. The record alone then does nothing — and nobody notices.
What this tool checks
- DNS record at
_mta-sts, including theid=version identifier. Without it, sending servers cannot tell that the policy changed. - Policy file — actually fetched over HTTPS rather than assumed. Certificate errors and HTTP status are reported.
- Mode —
enforce,testingornone. - max_age — how long sending servers cache the policy.
- MX coverage — every published MX host is matched against the policy's
mx:patterns, wildcards included. - TLS-RPT — whether a feedback channel exists at all.
The check that matters
The MX comparison is the reason this tool exists. A policy that does not name one of your MX hosts makes exactly the deliveries through that host fail in enforce mode. The sending server aborts before the message reaches you — so there is no log entry on your side, no bounce copy, nothing. The sender sees an error, you see nothing at all.
This typically happens after a change to the MX records: a backup MX is added and the policy file is forgotten. Or a provider change alters the hostnames while the old policy still names the old ones. Both show up here immediately.
What this test cannot see
Whether your MX servers actually present a certificate matching the names in the policy is answered by the MX check, which opens a real SMTP connection. And whether other servers are failing against your policy in practice is something only TLS-RPT can tell you — the feedback channel this tool checks for but cannot read.