MTA-STS in Practice: Adoption, Tooling, and Real Implementation

MTA-STS closes the STARTTLS downgrade hole by letting domains require verified TLS for inbound mail. The policy file, the DNS record, and the gotchas in between.

SMTP encrypts opportunistically: a sending server offers STARTTLS, and if the negotiation fails or an attacker strips the capability from the conversation, delivery proceeds in plaintext. Nothing in the original protocol lets a domain say encryption is mandatory here. MTA-STS (RFC 8461) is the fix that works with plain DNS and a web server, and it costs an afternoon to deploy properly.

The downgrade problem MTA-STS solves

A machine-in-the-middle between two mail servers can remove the STARTTLS advertisement from the SMTP greeting, and a standards-compliant sender will fall back to plaintext without complaint. The sender also performs no meaningful certificate validation by default, so even an encrypted session can terminate at an impostor. Opportunistic TLS protects against passive observation on a good day and against active attackers not at all.

MTA-STS moves the trust decision out of the SMTP session. The receiving domain publishes a policy over HTTPS, whose certificate chain an attacker on the mail path cannot forge, stating that its MX hosts always support TLS with valid certificates. A compliant sender caches that policy and refuses to deliver through anything less for as long as the policy is valid.

The two artifacts

Deployment is a TXT record plus a text file. The record at _mta-sts.yourdomain.com announces that a policy exists and carries an id value that senders use to detect policy changes. The policy itself is served at a fixed well-known URL on the mta-sts subdomain.

version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

The mx lines must cover every hostname in your MX record set, and wildcards like *.mail.protection.outlook.com are permitted for hosted setups. max_age tells senders how long to cache the policy; short values (a day) suit the rollout phase, long values (weeks) harden the steady state, because a cached policy protects even while DNS is under attack.

Rolling out without breaking inbound mail

Where deployments go wrong

The policy host is the classic failure. The HTTPS endpoint serving mta-sts.txt needs its own valid certificate for the mta-sts subdomain, and teams park it on a CDN or static host that silently drops the file or lets the certificate lapse during some later migration. A missing policy fails open for new senders, but senders holding a cached enforce policy will hard-fail deliveries against MX hosts that drift out of compliance.

MX changes are the second trap. Adding a backup MX, switching mail providers, or renaming hosts requires updating the policy's mx list in the same change window. An MX host absent from the policy is, to a compliant sender in enforce mode, indistinguishable from an attacker.

For senders the obligations are lighter: honor policies when transmitting if your MTA supports it (Postfix via the postfix-mta-sts-resolver, Exim natively, most commercial gateways), and never disable certificate verification to work around a destination's broken policy. Their policy, their outage.

MTA-STS and DANE

DANE achieves the same goal with TLSA records secured by DNSSEC, which is cryptographically stronger but requires DNSSEC on the receiving domain and validation support at the sender. MTA-STS was designed as the deployable alternative for the majority without DNSSEC. They coexist: publish both if you can, and senders that support both will prefer DANE. Microsoft and Gmail both evaluate MTA-STS on outbound mail, which is precisely why a broken enforce policy is a real incident rather than a theoretical one.

MTA-STS is one of the rare security upgrades with a clean rollback path and built-in reporting. Audit your MX certificates, publish in testing mode with TLS-RPT, and promote to enforce when the reports go quiet. The next article covers reading those TLS-RPT reports in detail.