MTA-STS Checker
We Fetch the Policy File, Not Just the DNS Record

What This MTA-STS Checker Tests, and Why the DNS Record Proves Nothing

MTA-STS tells other people’s mail servers to require TLS when they deliver to yours, and to refuse to deliver at all if they cannot. Setting it up takes two pieces: one TXT record in DNS, and one file on a web server. The record is trivial. The file is hosted infrastructure, with a certificate, a DNS name and a deploy pipeline of its own — and that is where setups die.

The evidence for that is not a hunch. On 22 September 2026 we resolved _mta-sts across 196 large, well-known domains. Twenty-eight of them publish a record. All twenty-eight records were syntactically perfect — correct version tag, valid id, nothing malformed. The DNS half is the easy half and everybody gets it right, which is exactly why a checker that stops there tells you almost nothing.

So this one does what a sending mail server does, in the same order:

1. Reads the TXT record at _mta-sts.yourdomain.com and checks that exactly one exists and that its id is legal.
2. Resolves the policy host, mta-sts.yourdomain.com, for A and AAAA records — and for a CNAME if neither answers, so a dangling alias can be named rather than guessed at.
3. Fetches the policy over HTTPS from /.well-known/mta-sts.txt, without following redirects and without reading anything from cache, because RFC 8461 forbids a sender doing either.
4. Parses the file against the specification’s own grammar: version, mode, max_age and every mx: entry, including the bounds on max_age and the exact wildcard rule.
5. Compares the policy against your live MX records, both ways — every MX host that no pattern covers, and every pattern that matches no host.

Three of those checks catch things that look fine in an editor. A byte-order mark at the start of the file is three invisible bytes that stop a sender recognising the first field — and the checkers we tried report it as a missing version line, about a line you can see with your own eyes.

Letter case matters more than almost anyone realises. The grammar in both specifications is written with the %s prefix of RFC 7405, which makes version, mode, mx, v=STSv1 and v=TLSRPTv1 case-sensitive strings. To a sender that follows the grammar, Mode: Enforce is simply not the mode field.

And a null MX — the single 0 . record RFC 7505 defines as “there exists no mail exchanger for a domain” — sits oddly beside a policy naming servers that may receive mail, and is invisible to a checker that just lists MX hostnames.

None of the three is reported as fatal, because senders in the wild are mostly lenient about all of them. They are reported as what they are: places where you are relying on that leniency rather than on the specification.

MTA-STS is not DMARC, and the two protect different things

This is the confusion that sends people to the wrong tool. SPF, DKIM and DMARC are about identity: they let a receiver decide whether a message really came from your domain. MTA-STS is about transport: it decides whether the connection carrying that message is encrypted, and whether the server on the other end is the one you said it would be. A domain can pass DMARC perfectly while every message reaching it travels in clear text, and it can encrypt everything while being trivially spoofable.

They also fail differently. A DMARC misconfiguration usually costs you protection. An MTA-STS misconfiguration in enforce mode can cost you mail, because the whole design is that a compliant sender refuses to fall back. If it is the identity layer you are actually here for, the DMARC record checker resolves the policy for your domain, your subdomains and names that do not exist. Both layers ultimately serve the same goal, which is mail that arrives — and that sits downstream of sender reputation more broadly, which the guide to IP reputation scores covers end to end.

Your MTA-STS Policy File Is a Web Page, and Web Pages Rot

Once you publish the DNS record, your MTA-STS deployment depends on an HTTPS endpoint staying up forever. Not up in the sense a browser cares about — up in the much narrower sense a sending mail server cares about. Three things break it, and all three are invisible from the DNS side.

The redirect that only a browser forgives

This is the trap, and it is worth understanding precisely. RFC 8461 §3.3 says of the policy fetch that “HTTP 3xx redirects MUST NOT be followed, and HTTP caching … MUST NOT be used”. So if mta-sts.yourdomain.com is pointed at your main website, and that website redirects everything to www, or to a canonical host, or to a marketing page, then you will open the policy URL in a browser and see a perfectly good policy file — while every sending mail server on the internet sees a 3xx and stops. Nothing logs an error. Nothing bounces.

Of the five page-1 checkers whose own descriptions we could read in September 2026, not one mentioned redirects. This tool reports the status code and the redirect target, because knowing it went to www.yourdomain.com is usually the whole diagnosis.

The certificate that does not cover the name

§3.3 also requires the policy host to present a certificate “valid for the ‘mta-sts’ DNS-ID” that chains to a trusted root and has not expired. A wildcard for *.yourdomain.com covers mta-sts.yourdomain.com. A certificate for the bare domain does not, because a wildcard stands for exactly one label and a bare name has no label to stand in for. The checker above verifies the certificate the way a sender would — the connection simply fails if it does not validate — and then reports which name on the certificate matched, which is the part that tells you whether the match was intentional.

What it deliberately does not do is grade the certificate. Chain depth, cipher suite, OCSP stapling and an expiry countdown are a different job, and running that job here would put two of our own pages in competition for the same question. Put the policy host through the put the policy host through our certificate checker if that is what you need.

The file that was never deployed, or was deployed once

The third failure is the simplest: the DNS record is published, and the file is not there. A 404, a host that resolves to nothing, an mta-sts subdomain that existed on the old hosting and was never recreated after a migration. In our survey, one of the 28 domains publishing a record had no A record, no AAAA record and no CNAME at the policy host at all — provably unreachable, from a domain that has otherwise done everything right.

If the checker reports the host as unresolvable and you believe it should resolve, confirm what public DNS actually returns rather than what your panel shows you — a see what public DNS actually returns on mta-sts.yourdomain.com settles it in one query.

The mx: Entries: the One MTA-STS Misconfiguration That Loses Mail

Everything above this heading costs you protection when it breaks. This one costs you messages.

A policy file lists the mail servers that are allowed to receive your mail. RFC 8461 §3.2 is explicit that each one needs its own line: “If a policy specifies more than one MX, each MX MUST have its own ‘mx:’ key.” A sending server connects to one of your MX hosts, and then checks that host against the patterns in your policy. If it matches nothing and your mode is enforce, the sender does not deliver. It does not fall back to an unencrypted connection, and it does not pick a different server. Refusing is the design.

So the policy has to keep up with your MX records. It does not, on its own. Changing mail provider, adding a regional server, moving from one filtering service to another, or a tenant migration that renames your inbound hosts — each of those edits DNS and leaves a static text file on a web server saying something that is no longer true. None of the five checkers we could read performs this comparison. They validate the policy’s syntax and stop, which means a file that is perfectly formed and points at servers you retired last year passes every one of them.

The wildcard rule, which is narrower than it looks

An mx: entry may start with *., and the wildcard may only stand for the entire left-most label. The specification spells out its own example, and the three things it does not match are the ones people get wrong:

The second row is the one that bites. A domain whose MX record points at the bare domain name — which is a perfectly ordinary setup — is not covered by a wildcard policy, and the policy file will look correct to every syntax validator you try it on.

Patterns that match nothing are a fingerprint, not a fault

The comparison runs both ways, and the reverse direction is diagnostic rather than dangerous. An mx: entry that matches none of your current MX hosts breaks nothing — a sender only ever tests the host it connected to. But it is almost always the residue of a provider migration where the new entries were added and the old ones were never taken out, which tells you the file has not been reviewed since. That is worth knowing before you switch to enforce. If mail landing where it should is the broader problem you are working on, the roundup of roundup of email deliverability tools covers the rest of the stack.

testing, enforce and none — and the max_age Nobody Thinks About

The mode line is the only part of the policy that changes what happens to your mail, and there are exactly three legal values.

Start at testing. It is not a weak setting, it is the setting that tells you what enforce would have broken — and because testing only produces useful information through TLS-RPT, the two really are one deployment rather than two features. Publishing enforce on day one means the first you hear about a gap is a customer asking why their mail bounced.

max_age is a security control, not a caching detail

This is the field people set to a small number because small numbers feel safer, and it is backwards. MTA-STS does not protect the connection where the policy is fetched. It protects the connections afterwards: a sender that has your policy cached will refuse to be downgraded on a later connection, even by an attacker sitting in the path. That memory is what max_age controls. A short value means senders forget quickly, re-fetch often, and spend most of their connections unprotected. max_age: 0 disables the mechanism entirely while leaving every check looking green.

The grammar allows up to ten digits, and the specification sets “a maximum value of 31557600” — one year. A week or more is normal once you are past testing. The checker flags anything under a day, anything at zero, and anything above the ceiling — none of which the five page-1 tools we read in September 2026 mentioned.

The id, and the edit that never takes effect

The id in the DNS record is how a sender knows your policy changed. RFC 8461 §3.1 defines it as 1*32(ALPHA / DIGIT) — letters and digits, up to thirty-two of them, and nothing else, which rules out the colons and dashes people copy out of a timestamp. Senders compare the id against the one they cached; if it has not changed, they keep using the policy they already have until max_age runs out.

So the order matters: edit the file, then change the id. Change the id first and a sender can re-fetch before your deploy lands, cache the old file under the new version number, and sit on it for a week. This is the single most common reason a correct fix appears not to work. It is the same class of problem as publishing a policy record and then wondering why nothing happened — if it is a DMARC record you are about to change rather than this one, the our DMARC builder builds it on the current tag set.

TLS-RPT: the Only Way You Will Ever Hear About a Failure

MTA-STS has no error channel of its own. When a sender cannot honour your policy it just stops, and nothing about that stop is visible from your side — no bounce you receive, no log you own, no alert. TLS reporting is the entire feedback mechanism, which is why this page checks it rather than making you visit a second tool.

It is one TXT record. At _smtp._tls.yourdomain.com, publish v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com and participating senders will post you a daily summary of how encryption to your mail servers went, including the failures.

Two rules in RFC 8460 that quietly switch it off

The first is the destination scheme. §3 states that “Two URI schemes are supported: ‘mailto’ and ‘https’.” An http:// endpoint, or an FTP address, or a bare email address with no mailto: in front of it, is written into a record that validates as a record and receives nothing.

The second is harsher, and the checker treats it as an error for that reason. If more than one record at _smtp._tls begins with the version tag, §3 says “senders MUST assume the recipient domain does not implement TLSRPT”. Two records is not two destinations — it is zero. To send reports to more than one place, put several comma-separated URIs inside a single rua value.

The opposite combination is the one to be uncomfortable about. A policy with no TLS-RPT record means you have asked the internet to change how it delivers your mail and given yourself no way to find out whether it worked. If ongoing visibility rather than a one-off check is what you are after, the comparison of how continuous reputation monitoring is usually set up covers the continuous-monitoring side of the same problem.

Setting MTA-STS Up, in the Order That Does Not Break Anything

The order below exists because two of these steps are irreversible in practice: once senders have cached a policy, you cannot un-cache it, and if you publish the DNS record before the file is live you have advertised a policy that is not there.

1. Create the host first. Point mta-sts.yourdomain.com at a web server over HTTPS, with a certificate that covers that exact name. It does not have to be your main website — a static host or an object store with a custom domain is fine, and arguably better, because it has nothing to redirect.
2. Publish the file at /.well-known/mta-sts.txt, served as text/plain, with LF or CRLF line endings. One mx: line per mail server, matching the MX records you publish today.
3. Open the URL yourself and confirm you get the file and not a redirect. The checker above is the more useful test here, because a browser will follow a redirect and show you a file that no sending mail server can reach.
4. Publish the TXT record at _mta-sts with v=STSv1 and an id — and only now, because this is the step that starts senders looking.
5. Publish TLS-RPT at _smtp._tls in the same sitting. Without it, the testing period you are about to start produces no information.
6. Leave it in testing until the reports have been quiet for a few weeks, then change the file to enforce and change the id, in that order.

What this tool cannot tell you

Being clear about the boundary is more useful than implying a check we do not run. MTA-STS makes two promises: that a policy exists and is fetchable, and that the MX hosts it names present valid certificates when a sender connects to them on port 25. This page verifies the first promise and not the second. Confirming the second means opening an SMTP connection to each of your MX hosts and inspecting the certificate offered during STARTTLS, which this server is not in a position to do reliably — so rather than claim it, we say so. A policy that passes every check here can still fail in the wild if one of your mail servers has an expired certificate, and TLS-RPT is how you would find that out.

Similarly, if what you actually have is one message that did not arrive and a set of headers from it, this is the wrong tool — paste them into the email header analyzer, which reads the authentication and transport results for that specific message.

MTA-STS Checker: Frequently Asked Questions