STARTTLS was bolted onto SMTP as an afterthought, and it shows: because encryption is negotiated in the clear, an attacker sitting between two mail servers can simply strip the STARTTLS offer and watch the message deliver in plaintext, with neither side raising an alarm. MTA-STS is the fix that doesn’t require rebuilding SMTP. It lets your domain publish a policy that says, in effect, “senders, when you deliver to me, you must use TLS with a valid certificate for one of these named MX hosts — and if you can’t, don’t deliver in cleartext, defer instead.” A sender that supports MTA-STS caches that policy and enforces it, so a downgrade attempt fails closed instead of silently succeeding.
The two pieces it needs
MTA-STS, specified in RFC 8461, is deliberately split across DNS and HTTPS so that neither alone can be spoofed to weaken it:
- A DNS TXT record at
_mta-sts.yourdomain, e.g.v=STSv1; id=20260719T000000. Theidis a version stamp — bump it whenever you change the policy, and senders know to refetch. - A policy file over HTTPS at
https://mta-sts.yourdomain/.well-known/mta-sts.txt, served with a valid certificate. This is where the real policy lives.
This tool fetches both and checks that they agree — a common failure is a TXT record whose id was updated but a policy file that was never redeployed, or an mta-sts subdomain whose certificate has expired.
Inside the policy file
The policy file is a few lines of plain text:
version: STSv1 mode: enforce mx: mail.example.com mx: *.example.net max_age: 604800mode—enforce(fail closed on TLS problems),testing(report failures via TLS-RPT but still deliver), ornone(used to retire a policy).mx— the MX hostnames allowed to receive your mail; wildcards are permitted. These must match your actual MX records and the names on their certificates.max_age— how long, in seconds, senders may cache the policy. A week or two is typical; a longer cache is more resilient but slower to change.
Roll out in testing mode first
Never start at enforce. A wrong MX name, a certificate mismatch, or a missing SAN can cause standards-compliant senders to defer mail — a self-inflicted outage. The safe path:
- Publish TLS-RPT first so you have visibility into TLS results.
- Deploy MTA-STS in
mode: testing. Failures are reported but mail still flows. - Watch the reports until they’re clean and every legitimate sender negotiates TLS successfully against your listed MX hosts.
- Switch to
mode: enforceand bump theidin the TXT record so senders refetch promptly.
MTA-STS and DANE target the same downgrade threat with different trust anchors — the web PKI here, DNSSEC there — and many domains run both. Verify the handshake itself with the SMTP Test, and see it alongside SPF, DKIM and DMARC in the Email Health Check.
Frequently asked questions
- Why does MTA-STS use both DNS and an HTTPS file?
- Splitting it across channels resists spoofing: the DNS record only announces a policy and its version, while the enforceable rules live in an HTTPS file behind a valid cert. A sender needs both.
- Should I start MTA-STS in enforce mode?
- No — start in
testing, watch TLS-RPT until clean, then switch toenforce. Enforcing with a wrong MX name or bad cert can defer your inbound mail. - What does the id field in the TXT record do?
- It’s a version stamp. Senders cache the policy up to
max_age; bumpingidtells them to refetch. Change the file but forget theidand cached senders keep the old policy. - How is MTA-STS different from DANE?
- Same threat, different trust anchor — MTA-STS uses the web PKI and needs no DNSSEC; DANE uses DNSSEC-signed TLSA records. Many domains run both for coverage.