MTA-STS needs a DNS record, an HTTPS-served file, and a web server with a valid certificate on a specific hostname. Three components, three independent ways to be broken, and only one of them lives in DNS.
The three
| Piece | Where | What it does |
|---|---|---|
TXT at _mta-sts.example.com | Your zone | Announces a policy exists, and carries an id that changes when the policy does. |
https://mta-sts.example.com/.well-known/mta-sts.txt | A web server | The policy itself. |
A certificate valid for mta-sts.example.com | That web server | The entire basis of trust in the policy. |
"v=STSv1; id=20190429T010101;"
Note how little the DNS record contains. It does not carry the policy — it says one exists and gives a version. A sender that sees an id different from the one it has cached refetches over HTTPS; a sender that sees the same id does not.
The hostname is not negotiable
- The policy host must be exactly
mta-sts.plus your domain. - The path must be exactly
/.well-known/mta-sts.txt. - The certificate must be valid for that hostname — not a wildcard mismatch, not a redirect to somewhere else with a different name.
- Redirects are not followed in the way a browser follows them. A policy host that 301s to your main site does not serve a policy.
Where each piece fails
TXT record missing or unparseable
-> no sender ever looks for a policy. Silent no-op.
Policy file 404s, or the host is unreachable
-> senders with a cached policy keep using it until max_age.
Senders without one deliver normally. Fails open.
Certificate expired or wrong name
-> the fetch fails. Same as above — but the expiry is on a
host nobody monitors, because it serves one text file.The certificate is the piece that will break
The DNS record does not expire and the text file does not rot. A TLS certificate on a host that exists solely to serve one file is exactly the certificate that falls out of a renewal process, and its failure is invisible until you look for it. Monitor that expiry specifically.