MTA-STS explained — the HSTS for email you probably don't have yet

// published 2026-04-17

MTA-STS ("Mail Transfer Agent Strict Transport Security") is the email equivalent of HSTS. It tells senders: only deliver mail to me over TLS, and only to the MX hostnames I've whitelisted. It's one of those records that takes 15 minutes to set up and blocks a class of attacks that's invisible without it.

The problem MTA-STS solves

SMTP's STARTTLS upgrade is opportunistic — the sender asks "can we switch to TLS?", the receiver can say yes, but nothing requires it. A network-level attacker (a compromised router, a BGP hijack, a captive portal) can strip the STARTTLS advertisement, and the sender will fall back to plaintext SMTP. Your email goes over the wire unencrypted. Worse, the attacker can redirect the mail entirely via MX spoofing.

TLS certs on the receiving MX don't help alone — the sender has no way to know which certs are legitimate vs which were forged by the attacker-in-the-middle. MTA-STS solves this by publishing an authenticated policy out-of-band, over HTTPS.

How it works

Two parts:

1. DNS TXT record at _mta-sts.yourdomain.com. Just tells senders a policy exists — and versions it:
   v=STSv1; id=20260417T000000;
2. Policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Contains the actual rules:
   

   version: STSv1
   mode: enforce
   mx: aspmx.l.google.com
   mx: *.aspmx.l.google.com
   max_age: 604800

Modes

• testing — senders ignore policy on failures but report them via TLS-RPT. Start here.
• enforce — senders drop mail if TLS or MX match fails. This is the protected state.
• none — kills an existing policy. Used only during migration.

Pair it with TLS-RPT

TLS-RPT is a separate DNS record telling senders where to report TLS delivery failures:

_smtp._tls.yourdomain.com TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Without TLS-RPT, you're in enforce mode but have no visibility into mail that's being dropped. Always set them together.

Deployment checklist

1. Publish the TXT at _mta-sts.yourdomain.com.
2. Serve mta-sts.yourdomain.com over HTTPS with a valid cert. Cloudflare Pages, GitHub Pages, a tiny nginx — anywhere that can host a static file.
3. Put the policy file at /.well-known/mta-sts.txt. Set mode: testing first.
4. Publish TLS-RPT at _smtp._tls.yourdomain.com.
5. Wait a week, review TLS-RPT aggregate reports for failures.
6. Flip to mode: enforce. Bump the id in the TXT record so senders re-fetch the policy.

Who actually implements MTA-STS on the sending side?

Google (Gmail, Workspace) and Microsoft (Outlook, M365) both enforce it. Major corporate senders do. That covers most of your legitimate email — if MTA-STS blocks a delivery, the sender was almost certainly already going to be flagged by your other protections.

Check whether your domain publishes MTA-STS (and get TLS-RPT coverage too) with the Email Authentication Scanner. If either is missing, the score drops — but most domains are missing both, so this is an easy 10-point win.