MTA-STS DNS (SMTP TLS)

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) tells sending MTAs to use TLS when delivering mail to your domain, and to refuse delivery if the cert is invalid. It is the SMTP equivalent of HSTS for HTTPS. The mechanism has two parts: a tiny DNS TXT record advertising the policy ID, and an HTTPS-served policy file with the actual rules. This check validates only the DNS record. The policy file must also be in place for MTA-STS to work end-to-end.

This check only runs when your domain has a non-null MX. If you have only a null MX or no MX, it shows as not applicable rather than failing.

How the verdict maps to evidence

• Pass: a v=STSv1 TXT record exists at _mta-sts.yourdomain.tld with an id= value.
• Warn: a TXT record exists but id= is missing or unparseable.
• Fail: no v=STSv1 TXT record found at _mta-sts.yourdomain.tld.

What this check does not verify: whether the HTTPS policy file at mta-sts.yourdomain.tld/.well-known/mta-sts.txt actually exists, is reachable, has a valid TLS cert, or matches your real MX records. Pass on this DNS check is necessary but not sufficient for working MTA-STS. Test the policy file separately.

Fail or warn: publish both the DNS record and the HTTPS policy file

MTA-STS rollout is four steps. Do them in order, ideally with TLS-RPT already configured (see the TLS-RPT fix) so you have visibility into delivery failures during the rollout.

1. Host the policy file

MTA-STS requires an HTTPS endpoint at mta-sts.yourdomain.tld serving a policy file at /.well-known/mta-sts.txt. The subdomain needs an A or AAAA record and a valid trusted TLS cert that includes mta-sts.yourdomain.tld in its SAN. Static hosting works fine: a basic web server, a CDN, or an object-storage bucket with HTTPS.

version: STSv1
mode: testing
mx: mail.yourdomain.tld
mx: *.mail.yourdomain.tld
max_age: 604800

List every MX hostname you actually use. Wildcards are supported but only one level deep. max_age is in seconds; 604800 is one week, the recommended floor during testing. Production policies typically use a much longer value (a month or more) once stable.

2. Publish the DNS TXT record

The TXT record at _mta-sts.yourdomain.tld carries only the policy ID. Receivers fetch the actual policy file via HTTPS. The id= must be unique per policy version; a timestamp works well.

_mta-sts.yourdomain.tld.   IN  TXT  "v=STSv1; id=20260503T000000Z;"

3. Wait and watch TLS-RPT reports

With mode: testing, receivers report TLS failures via TLS-RPT but still deliver mail. Watch reports for two to four weeks. Look for any sender that fails to negotiate TLS or fails certificate verification. Common findings: an MX hostname not in your mx: list, a cert that does not chain to a public root, or a cert that matches the MX hostname but not the policy.

4. Switch to enforce

Once TLS-RPT shows clean delivery, edit the policy file: change mode from testing to enforce, bump the id= in DNS, and republish both. Receivers will then refuse to deliver mail without verified TLS.

version: STSv1
mode: enforce
mx: mail.yourdomain.tld
mx: *.mail.yourdomain.tld
max_age: 1209600

Verify the fix

• Run dig +short TXT _mta-sts.yourdomain.tld @1.1.1.1 and confirm v=STSv1 with an id= value.
• Open https://mta-sts.yourdomain.tld/.well-known/mta-sts.txt in a browser. The file should load with no cert warnings and contain the policy you expect.
• Test with hardenize.com, internet.nl, or another third-party MTA-STS validator. They check the DNS record, the policy file, the cert, and the mx: list together.
• Watch TLS-RPT reports for at least two weeks under testing before switching to enforce.
• Re-run the RedScore lookup.

Common pitfalls

• DNS record but no policy file. Receivers fetch the policy via HTTPS; if it is missing or unreachable, MTA-STS does nothing. Always confirm both pieces are live.
• Cert mismatch on mta-sts subdomain. The TLS cert must include mta-sts.yourdomain.tld in its SAN. Wildcard certs (*.yourdomain.tld) cover it; bare apex certs do not.
• Forgetting to bump id= when changing the policy. Receivers cache the policy by id; if you edit the file but reuse the old id, receivers may serve a stale cached copy until max_age expires.
• mx: list out of date. The hostnames in the policy must match your real MX records, including any new transactional or backup MX hosts. Adding an MX without updating the policy breaks delivery in enforce mode.
• Going straight to enforce. Mail bounces. Always run testing for at least two weeks with TLS-RPT enabled.
• max_age too short. Receivers refresh the cached policy after max_age. A short value (under one day) means the policy is barely useful; receivers keep checking it instead of relying on it. RFC 8461 recommends 604800 as a minimum.