How it works
Out of the box, encryption between mail servers is optional. A sending server tries STARTTLS, and if that fails it simply delivers in plain text, usually without checking the receiving server's certificate at all. MTA-STS (RFC 8461) lets you publish a policy that turns this into a requirement for your domain.
It has two parts. A TXT record at _mta-sts.example.com announces the policy, for example v=STSv1; id=20261109120000. The policy itself is a plain text file at https://mta-sts.example.com/.well-known/mta-sts.txt containing version: STSv1, a mode (none, testing or enforce), one or more mx lines and max_age in seconds. The mta-sts subdomain needs its own valid HTTPS certificate to serve it.
A sender that supports MTA-STS, such as Google and Microsoft, fetches the policy, caches it for max_age seconds and, in enforce mode, delivers only to MX hosts listed in the policy that present a valid certificate for their name. In testing mode it still delivers and reports failures through TLS-RPT.
Whenever the policy changes, the id in the TXT record has to change too. Otherwise senders keep using their cached copy until max_age runs out.
Why it matters
Without MTA-STS, anyone who controls the network path between two mail servers can strip the STARTTLS offer from the session or intercept it with any certificate they like. The sending server has no way to notice and hands over invoices, contracts and password reset links in readable form.
A badly maintained policy does damage in the opposite direction. If an MX host is missing from the mx lines in enforce mode, typically after switching mail providers, or its certificate has expired, senders refuse to deliver. Messages pile up in their queues and bounce back as undeliverable a few days later.
How to prevent it
- Start with mode: testing, publish a TLS-RPT record at the same time and review the reports for a few weeks before switching to enforce.
- List every MX host in the mx lines; for providers that rotate hosts, use a wildcard such as *.mail.protection.outlook.com for Microsoft 365.
- Serve the policy file directly with status 200 and no redirect, and have the certificate for mta-sts.example.com renew automatically.
- Change the id in the TXT record every time you edit the file, for example to the current timestamp.
- In production, set max_age to at least one day (86400), preferably several weeks; before switching providers, add the new MX host to the policy first.
- If you don't want to run a web server just for this file, let DomainWarn host the policy and its certificate; your client then only sets a CNAME and the TXT record.
How DomainWarn detects it
The MTA-STS check reads the TXT record at _mta-sts, fetches the policy file over HTTPS and compares its mx lines with the domain's actual MX records. It flags a missing id tag, multiple competing records, a policy that cannot be fetched or is redirected, an invalid version line, an invalid mode, and a missing max_age or missing mx entries. If such an error persists for two runs, DomainWarn opens an “MTA-STS invalid” incident.
MX hosts not covered by the policy in enforce mode are rated critical, because senders will stop delivering. Modes none and testing, a max_age under one day and a missing TLS-RPT record show up as notices. Changes to the record, mode or mx list are reported as “MTA-STS changed”, and a weaker policy as “MTA-STS weakened”.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.