What is MTA-STS? Enforcing TLS on inbound email (with TLS-RPT)

Published October 26, 2026 · about an 8-minute read

Most teams who've done SPF, DKIM and DMARC think they've finished their email security. Those three prove who sent a message. None of them guarantees the message actually traveled encrypted. That's a different problem, and MTA-STS is the fix. It's the least-known of the email standards and, with mailbox providers tightening expectations, one worth doing. Let me walk through it and its reporting companion, TLS-RPT.

The gap MTA-STS closes

When one mail server delivers to another, it's supposed to negotiate TLS using a command called STARTTLS. The problem: classic SMTP encryption is opportunistic. If TLS isn't available — or an attacker on the path strips the STARTTLS command, which is trivial in a man-in-the-middle position — the servers quietly fall back to sending your mail in plaintext. No warning, no failure. Your carefully authenticated email crosses the internet readable by anyone on the wire.

MTA-STS (SMTP MTA Strict Transport Security, from RFC 8461) removes the fallback. It lets your domain publish a policy that says: mail to me must use TLS, with a valid certificate matching my MX hosts — and if it can't, don't deliver it in the clear. It's conceptually the email cousin of HSTS for websites: both turn "encryption if convenient" into "encryption required."

One thing to be clear about: MTA-STS protects inbound mail — messages other people send to your domain — and only works if the sending server honors MTA-STS. The big providers do. Senders that don't support it still deliver normally, so you lose nothing by publishing a policy.

The three pieces

MTA-STS has an unusual shape: it's mostly a file served over HTTPS, anchored by a small DNS record.

1. The policy file

You host a text file at a fixed URL on an mta-sts subdomain:

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

version: STSv1
mode: testing
mx: mail.yourdomain.com
mx: *.yourprovider.com
max_age: 604800

One mx: line per mail host (wildcards allowed), and max_age in seconds — the RFC points at roughly one to two weeks (604800–1209600) so senders cache the policy.

2. The MTA-STS DNS record

A TXT record at _mta-sts.yourdomain.com tells senders a policy exists and carries a version id:

_mta-sts.yourdomain.com. TXT "v=STSv1; id=20261026T000000"

The id is the important detail: you must change it every time you edit the policy file, or senders keep using their cached copy and never notice your update. I use a timestamp so it's obvious when it last changed.

3. The TLS-RPT DNS record

This is the one that makes the whole thing safe. TLS-RPT (RFC 8460) asks sending servers to email you daily reports on how TLS delivery went:

_smtp._tls.yourdomain.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

You'll get a compressed JSON attachment per reporting sender per day, listing successful TLS sessions and any failures with reasons. It's the visibility that tells you whether enforcing is safe.

The mode field, and why you start in testing

The mode in the policy file is where the care goes. Three values:

Always start in testing. Publish everything, turn on TLS-RPT, and watch the reports for a few weeks. Testing mode is genuinely safe — you learn about every TLS problem without a single message being blocked. Only once the reports come back clean do you flip mode: enforce and bump the id. This is the same discipline as moving DMARC from p=none to enforcement: observe first, enforce once you've proven nothing legitimate breaks.

The gotcha: it lives or dies on a certificate

Here's where MTA-STS quietly fails, and it's squarely in my wheelhouse. The policy file must be served over HTTPS with a valid certificate on the mta-sts subdomain — not expired, not mismatched, properly chained, no redirects, served as text/plain. If the certificate on mta-sts.yourdomain.com expires or breaks, senders can't fetch your policy, and in enforce mode that can start interfering with your inbound mail.

So turning on MTA-STS doesn't reduce your certificate surface — it adds one more certificate you absolutely cannot let lapse, on a subdomain nobody visits in a browser and therefore nobody notices. That's exactly the kind of certificate that silently expires. And an incomplete chain on that host will trip up the stricter mail servers just like it trips up curl.

If you enforce MTA-STS, that mta-sts subdomain's certificate becomes part of your mail deliverability. Monitor it like one.