MTA-STS Not Enforced: Record Published but Policy File Missing

Why it matters

The point of MTA-STS is to stop active downgrade attacks on inbound SMTP, a man-in-the-middle stripping STARTTLS or spoofing your MX so mail is delivered in cleartext or to an attacker's server. With the policy file unreachable, sending MTAs silently fall back to opportunistic TLS, which offers no such protection, so you gain none of the security you appear to have advertised. The dangerous part is the false sense of security: dashboards and DMARC/BIMI checklists show "MTA-STS present," but real senders enforce nothing. Note this rarely blocks legitimate mail - delivery continues over opportunistic TLS - so the failure is invisible unless you also run TLS-RPT, which is exactly why it goes unnoticed. This is governed by RFC 8461 (SMTP MTA Strict Transport Security).

Common causes

• The `_mta-sts` TXT record was added, but the `mta-sts.<domain>` policy host was never provisioned: no A/AAAA/CNAME record, or no web server answering on port 443.
• The file is served at the wrong location, missing the `.well-known/` prefix, a typo/wrong case in `mta-sts.txt`, or on the apex/`www` host instead of the `mta-sts.` subdomain.
• The TLS certificate on `mta-sts.<domain>` is expired, self-signed, name-mismatched, or missing intermediates; RFC 8461 requires a non-expired cert valid for the `mta-sts` DNS-ID chaining to a trusted root, so any cert error makes the policy unfetchable.
• The endpoint returns a 3xx redirect (e.g. redirecting `mta-sts.example.com` to `www.example.com` or forcing a path change), RFC 8461 says redirects MUST NOT be followed; only a direct HTTP 200 is valid.
• The web server returns the file with a non-200 status (404/403/500), or with the wrong media type, senders SHOULD validate that the media type is `text/plain`, so a non-text type can cause the policy to be rejected.
• The policy file body is malformed or incomplete - missing `mode`, missing `max_age`, wrong `version`, or CRLF/encoding issues - so it parses as invalid and is treated as no policy.
• A CNAME to a static host or CDN (GitHub Pages, Cloudflare Worker/Pages, S3) that isn't fully provisioned for the custom hostname, so the HTTPS fetch fails even though DNS resolves.
• The `id` in the TXT record was bumped but the file was never deployed/updated, or a firewall/geo-rule blocks the crawler's HTTPS request to the policy host.

How to fix MTA-STS Not Enforced

1. Confirm the advertisement: `dig +short TXT _mta-sts.example.com` should return exactly one record like `v=STSv1; id=20240101T120000Z;` (id is 1-32 alphanumeric characters). Note the id value.
2. Provision the policy host: create a DNS record for `mta-sts.example.com` (A/AAAA or CNAME) pointing to a TLS-capable endpoint, and issue a valid, non-expired certificate for the hostname `mta-sts.example.com` (e.g. Let's Encrypt) with a complete chain and correct SAN.
3. Publish the file at exactly `https://mta-sts.example.com/.well-known/mta-sts.txt`, served with HTTP 200, `Content-Type: text/plain`, and NO redirect (do not 301/302 to another host or path).
4. Write correct contents, starting in testing mode: version: STSv1 mode: testing mx: mail.example.com mx: *.example.net max_age: 86400 Every required field (version, mode, mx, max_age) must be present; max_age is non-negative integer seconds with a maximum of 31557600 (~1 year).
5. Make the `mx:` patterns match your live MX exactly, run `dig +short MX example.com`, list every MX hostname, and use a wildcard (`*.example.net`) only where the entire leftmost label varies (`*.example.net` matches `mail.example.net` but not `example.net` or `a.b.example.net`).
6. Verify the fetch end-to-end: `curl -sSv https://mta-sts.example.com/.well-known/mta-sts.txt`: confirm HTTP 200, `text/plain`, valid TLS (no cert warnings), no redirect, and the exact policy body.
7. Enable TLS-RPT so failures become visible: add a TXT record at `_smtp._tls.example.com` like `v=TLSRPTv1; rua=mailto:[email protected];`, then watch the reports for successful policy application.
8. Once testing mode reports clean policy fetches and TLS success from real senders, change `mode: testing` to `mode: enforce` in the file, and bump the `id` in the `_mta-sts` TXT record (e.g. a new timestamp) so caching senders re-fetch the updated policy.
9. Re-validate with an external checker (Hardenize, MXToolbox, or an MTA-STS-specific validator) and, going forward, bump the TXT `id` every time you edit the policy file and monitor certificate expiry on the `mta-sts.` host.

Related