MTA-STS record published but the policy file is unreachable
The DNS record announces an MTA-STS policy, but the policy file cannot be fetched. Senders that look for it find nothing valid and fall back to opportunistic TLS, so the protection is not in effect: the domain has the appearance of MTA-STS without any of its benefit, and nothing reports the discrepancy.
Check your own domainMTA-STS checker
What causes this
MTA-STS has two halves: a TXT record that announces a policy exists, and a policy file served over HTTPS. Senders that see the record then fetch the file. When the fetch fails, senders cannot apply the policy, so the configuration provides no protection while appearing to be in place.
What it breaks
MTA-STS gives you no protection. Senders fall back to opportunistic TLS.
What the receiving server does
A sender sees the _mta-sts TXT record and requests https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. If the host does not resolve, the certificate is invalid or expired, the request redirects, or the file is missing or malformed, the sender has no usable policy and reverts to delivering as it would for a domain with no MTA-STS at all. Because a missing policy is a fallback rather than an error, mail continues to flow and the failure is invisible from the sending side and the receiving side alike.
Where the fetch fails
The failures are all at the HTTPS layer rather than in DNS, which is why the DNS record continuing to resolve is no evidence that anything works.
How to fix it
Serve the policy file over HTTPS with a valid certificate.
- Confirm https://mta-sts.yourdomain.com/.well-known/mta-sts.txt returns the policy with content type text/plain.
- Confirm the certificate for the mta-sts subdomain is valid and not expired.
- Confirm the mta-sts subdomain has DNS records pointing at the host serving the file.
If you send with
- Certificate renewal
- The most common cause is an expired certificate on a host nobody looks at, because the domain serves nothing else. If mta-sts.yourdomain.com is a separate host, it needs the same renewal monitoring as your main site, or it will lapse without anyone noticing.
- Redirects
- The policy must be served at the exact URL. A redirect from mta-sts.yourdomain.com to www.yourdomain.com, or an HTTP to HTTPS chain that adds a hop, will cause conforming senders to reject the policy. Serve the file directly at that hostname.
Confirming the fix worked
- Request the policy URL over HTTPS and confirm it returns 200 with content type text/plain and no redirect.
- Confirm the certificate is valid for mta-sts.yourdomain.com specifically and is not close to expiry.
- Confirm the mx lines in the file match the hostnames in your MX records exactly.
- Confirm the id value in the DNS record was changed when the policy last changed, since senders use it to decide whether to refetch.
Common questions
- Mail is still being delivered. Is this urgent?
- Mail flows normally, because senders fall back to opportunistic TLS. What you have lost is the protection you believe is in place: connections can still be downgraded to plaintext by an attacker in the path.
- Does the id value in the DNS record matter?
- Yes. Senders cache the policy and use the id to decide whether to fetch a new one. If you change the policy without changing the id, senders continue using the cached version until it expires.
- Can I host the policy file anywhere?
- No. It must be at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, on that exact hostname and path, with a certificate valid for that name. The location is what makes it verifiable.
- Do I need a separate web server for this?
- Not a separate server, but a hostname that serves HTTPS with a valid certificate and returns the file as plain text. A static host or object store is entirely sufficient, and is often the more reliable option.