Email authentication
MTA-STS checker
Read a domain’s MTA-STS record and policy file, and check every mx pattern against its live MX records.
Free, no accountLive check
Result
The verdict appears here once you press Check MTA-STS policy.
What this is
This MTA-STS checker reads the three things that have to agree before a sender will require TLS for your mail: the TXT record at "_mta-sts", the policy file served at "mta-sts." plus your domain, and the MX records your domain publishes right now - which is the pair that quietly stops matching after a provider change.
MTA-STS (RFC 8461) is how a receiving domain tells sending servers that mail must arrive over TLS, to a host it has named in advance. It is published in two places at once: a small TXT record at "_mta-sts.<domain>" carrying a version and a policy id, and a policy file fetched over HTTPS from the fixed path "/.well-known/mta-sts.txt" on the host "mta-sts.<domain>".
The policy file names the hosts allowed to receive the mail, with one "mx:" line each, and a "mode" that says what a sender does when a host fails that check - refuse delivery, report it, or ignore the policy altogether. Because the list of allowed hosts is written down separately from the MX records themselves, the two can drift apart, and nothing in DNS notices when they do.
How to read the result
"Live MX hosts against the policy" is the table to read first. Each host the domain publishes is shown with the policy pattern that covers it, or "no match" - and a "no match" at mode enforce is a host that senders honouring MTA-STS will refuse to deliver to, however healthy the host itself is.
The discovery facts above it say what was found where: the exact TXT record, the policy id inside it, the URL the policy was fetched from and the HTTP status it answered with. A 404 or a redirect there is a complete failure of the policy even though the TXT record looks perfect, because RFC 8461 §3.3 only accepts a 200 and forbids following redirects.
Common mistakes
What goes wrong most often, and how to tell.
- Changing mailbox provider and leaving the old mx lines in the policyNew MX records go into DNS, the policy file keeps naming the previous provider’s hosts, and every sender that honours an enforce policy stops delivering - while senders that ignore MTA-STS carry on, so the domain appears to be receiving mail from some places and not others.
- Editing the policy file without changing the idThe id in the TXT record is the only signal a sender has that the file is worth fetching again. Correct the file but leave the id alone and senders holding a cached copy keep applying the old policy until its max_age runs out, which the RFC expects to be weeks.
- Serving the policy from a redirect or the wrong hostThe policy host is "mta-sts." prepended to the domain and the path is fixed, and RFC 8461 §3.3 says redirects must not be followed. A rule that sends the apex and all its subdomains to one canonical host turns a valid policy into no policy at all.
- Going straight to mode enforceTesting mode exists so a sender reports a policy failure instead of refusing the message, which is how you find a host you forgot to list before it costs you mail. Publishing a TLS-RPT record first is what makes those reports reach you.
Questions
What people ask about this tool.
- Because the policy file lists the hosts allowed to receive your mail by name, and a migration changes your MX records without touching that file. At mode enforce, a sender must not deliver to a host that matches no "mx" line, so the new provider’s hosts are refused until the policy is updated and its id changed.
- It identifies one revision of the policy file, in 1 to 32 letters and digits. A sender keeps the policy it fetched and compares the id in DNS against the one it cached, so changing the id is what tells every sender to fetch the file again - and not changing it is why a corrected policy appears to do nothing.
- No. RFC 8461 §4.1 allows "*" only as the entire left-most label, so "*.example.com" matches mail.example.com but neither example.com itself nor foo.bar.example.com. A host two labels deep needs its own pattern or its own wildcard.
- No, and that gap is listed under the limits on every result. Checking that would mean opening an SMTP connection to each host and inspecting the certificate it presents, which this page deliberately never does; it checks what is published in DNS and over HTTPS.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- IETF, “RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)” read 13 October 2026
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.