What is MTA-STS? TLS policy for email explained

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) lets a receiving domain declare that its mail servers always support TLS with valid certificates, and that senders should refuse to deliver through anything less. It closes a hole as old as SMTP: transport encryption between mail servers is opportunistic by default, and an attacker on the path can strip the STARTTLS offer and force plaintext delivery. With MTA-STS, a compliant sender that cannot negotiate verified TLS holds the mail instead of downgrading.

The downgrade problem it solves

Server-to-server SMTP encrypts only if the receiving server advertises STARTTLS and the negotiation succeeds; on any failure, standard behaviour is plaintext delivery. A machine-in-the-middle can simply delete the STARTTLS capability from the greeting, and the sender complies. Certificate validation is equally optional in practice, so even an encrypted session may terminate at an impostor. MTA-STS moves the trust decision out of the attackable channel: the policy is fetched over HTTPS, whose certificate an attacker on the mail path cannot forge, and cached so that protection persists even while DNS or the path is under attack.

Two artifacts, three modes

The complete deployment surface

11. DNS record announcing the policy and its version:
2_mta-sts.example.com. IN TXT "v=STSv1; id=20260714T120000"
3
42. Policy file served over HTTPS at a fixed URL:
5https://mta-sts.example.com/.well-known/mta-sts.txt
6
7version: STSv1
8mode: enforce
9mx: mx1.example.com
10mx: mx2.example.com
11max_age: 1209600

The mode line sets the stakes. none declares no policy (useful for clean rollback), testing asks senders to evaluate and report failures without blocking delivery, and enforce means non-compliant delivery attempts fail rather than downgrade. The mx lines must cover every hostname in the MX record set (wildcards like *.mail.protection.outlook.com are allowed for hosted mail), and max_age tells senders how long to cache the policy, short during rollout, one to two weeks in steady state, because a cached policy is exactly what protects you while under active attack.

Rolling out without losing mail

Staged deployment

1
Audit every MX certificate first
Each MX host needs a valid, unexpired, publicly chained certificate matching its hostname. Self-signed and mismatched certificates pass unnoticed under opportunistic TLS and become delivery failures under enforce.
openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com
2
Publish TLS-RPT before the policy
The companion reporting record gets large senders to mail you daily failure summaries, which is your visibility for everything that follows.
3
Host the policy in testing mode
Serve mta-sts.txt over HTTPS with a valid certificate for the mta-sts subdomain, mode: testing, short max_age.
4
Watch reports for two to four weeks
TLS-RPT failures during testing surface certificate problems, missing mx entries, and middleboxes while the cost is a report line instead of held mail.
5
Promote to enforce
Switch mode, bump the id, and raise max_age once the reports run clean.

Where deployments fail

The policy host is the classic casualty: the HTTPS endpoint needs its own valid certificate for mta-sts.example.com, and it gets parked on static hosting that someone later migrates or lets lapse. MX changes are the second: adding a backup MX or switching mail providers without updating the policy's mx list makes the new host indistinguishable from an attacker to every sender holding a cached enforce policy. Both failure modes argue for treating the policy file and its hosting as part of the mail infrastructure change checklist, not as a one-time setup artifact.

MTA-STS coexists with DANE, the DNSSEC-based alternative that binds certificates via TLSA records: publish both if you can, and senders supporting both prefer DANE. Gmail and Microsoft both honor MTA-STS policies on their outbound mail, which is why a broken enforce policy is a real incident rather than a theoretical one, and why the TLS-RPT reporting channel belongs in place before enforcement, as the eyes on all of it.

Frequently asked questions

Does MTA-STS protect the mail I send?

Publishing a policy protects mail sent to you. Protecting outbound mail requires your MTA to fetch and honor other domains' policies when transmitting, which Postfix supports via the postfix-mta-sts-resolver and commercial gateways support natively.

What happens if my policy host goes down?

Senders holding a cached policy keep enforcing it until max_age expires; senders without one behave as if no policy exists. Brief outages are survivable. The dangerous combination is a lapsed policy-host certificate during an MX migration.

Do I need MTA-STS if I already have DMARC?

They protect different layers: DMARC authenticates who sent a message, MTA-STS protects the transport channel inbound mail travels over. A complete posture wants both, and compliance frameworks like NIS2 increasingly read encryption in transit as expected practice.

Is enforce mode risky for a small domain?

Not after the staged rollout: the risks are operational (certificates, MX list currency), not scale-dependent. Small domains on hosted mail (Google Workspace, Microsoft 365) can usually deploy with wildcard mx entries and near-zero ongoing effort.

Key takeaways

MTA-STS lets a domain require verified TLS for inbound mail, closing the STARTTLS downgrade attack
Deployment is one DNS record plus one HTTPS-hosted policy file with none, testing, and enforce modes
Every policy edit requires bumping the id in the DNS record, or cached policies persist until max_age
Roll out via certificate audit, TLS-RPT, testing mode, then enforce once reports run clean
The recurring failures are lapsed policy-host certificates and MX changes that skip the policy update