MTA-STS Checker

MTA-STS (RFC 8461) lets a domain tell sending mail servers to deliver to its MX only over TLS, to a server with a valid certificate for its name. Without it, STARTTLS is opportunistic: an attacker in the path can delete the server's STARTTLS offer, and the message travels in plain text although both servers support TLS.

The policy also keeps a sender from handing mail to an impostor. Each MX must match a name in your policy and present a certificate for that name from a public certificate authority, so an attacker who redirects the connection, by spoofing the MX record or rerouting traffic, is refused unless it holds a valid certificate for a name in your policy. In enforce mode the sender doesn't deliver; it treats the failure as temporary and retries later.

The protection starts once a sender has fetched and cached your policy, and it applies only to senders that check MTA-STS. Mail between two domains is held back only when both sides use MTA-STS and a check fails; everyone else's mail flows as before.

The MTA-STS record is a TXT record at _mta-sts.<domain> with two fields: v=STSv1 first, then an id of 1 to 32 letters and digits that changes whenever the policy does. The MTA-STS policy is a text file with four keys: version, mode, max_age and one mx line per allowed mail server.

Both are strict and case-sensitive. Senders discard TXT records that don't begin with v=STSv1;, and when more than one remains they assume there's no policy at all. The record may be split into several strings, which senders join without spaces, or be a CNAME to a provider's record. In the file, a key is followed directly by its colon, lines may end in LF or CRLF, a repeated key counts only the first time, and unknown keys are ignored.

The file must answer 200 at https://mta-sts.<domain>/.well-known/mta-sts.txt, as text/plain, without a redirect and within 64 KB. Google adds two rules for its own console: version on the first line, and a max_age of at least 86400. Microsoft suggests a UTC timestamp as the id, such as 20261101093000Z, and a TTL of 3600 on the record.

Start in testing and switch to enforce once every mail server passes and your TLS-RPT reports are clean: Google recommends two weeks of testing, Cloudflare a few weeks. In testing, senders deliver even when a check fails and only report it; in enforce, they refuse.

Every change to the file needs a new id in the TXT record, and the order matters: publish the new file first, then the new id. A sender that sees a new id fetches the file again; one that saw the id before the file changed could keep the old policy for max_age. Microsoft's way out of an incident is the same move in reverse: back to testing, then a new id.

To remove MTA-STS, publish mode none with a short max_age, change the id, wait until every earlier max_age has passed, then delete the record and the file. Deleting the record alone doesn't clear a policy senders already cached.

Anywhere that serves https://mta-sts.<domain>/.well-known/mta-sts.txt with a certificate for that name, a 200 answer, Content-Type text/plain and no redirect. A static host is enough, as long as only you can publish files on it: RFC 8461 warns that a host where others can upload could serve a policy of their own.

Each host has a setting that can break the file. GitHub Pages runs Jekyll, which skips folders that start with a dot, so .well-known needs a .nojekyll file or an include line in _config.yml. Netlify's docs don't say which Content-Type a .txt file gets, so set it in _headers. On nginx and Apache, a site-wide redirect to www or to an app also catches the policy URL; give mta-sts.<domain> its own server block. On Cloudflare, bot protection that covers static resources covers /.well-known/ too.

Exchange Online can't host the file for you: Microsoft recommends Azure Static Web Apps, which issues the certificate itself, over Azure Functions, where you bind your own. Cloudflare Email Routing customers can delegate the whole policy to Cloudflare with a CNAME and a small Worker.