MTA-STS and TLS-RPT Explained: Locking Down Email in Transit

When people talk about "securing email," they usually mean SPF, DKIM, and DMARC — the trio that proves who sent a message. But there's a separate question those three don't answer at all: while an email travels between mail servers, is it actually encrypted? For a long time the honest answer was "maybe, and you'd never know." MTA-STS and TLS-RPT are the standards that fix that.

They're less famous than their authentication cousins and a little more fiddly to deploy, but the problem they close is real — and surprisingly old.

The STARTTLS loophole

When one mail server hands a message to another over SMTP, it can encrypt the connection using a mechanism called STARTTLS. The catch is in how it begins. The two servers first connect in plain text, and the receiver advertises that it supports STARTTLS; the sender then upgrades the connection. That negotiation happens in the clear.

Which means a network attacker sitting in the middle can simply delete the STARTTLS advertisement. The sending server, seeing no offer of encryption, falls back to delivering the message in plain text — and neither side raises an alarm. This is a downgrade attack, and classic SMTP has no defence against it. On top of that, mail servers have traditionally been lax about checking the certificate on the other end, so even when TLS was used, there was little guarantee you were talking to the right server. Email in transit was encrypted on a best-effort basis — and best-effort is exactly what an attacker exploits.

What MTA-STS does

MTA-STS — SMTP MTA Strict Transport Security — lets a domain publish a policy that says, in effect: always deliver mail to me over TLS, with a valid certificate, on these named mail servers; if you can't, don't deliver at all. Sending servers that support MTA-STS fetch that policy, cache it, and enforce it — so a stripped STARTTLS or a bogus certificate causes delivery to fail rather than quietly drop to plain text.

If that sounds familiar, it should: it's the email equivalent of HSTS on the web, where a site tells browsers to refuse anything but HTTPS. MTA-STS does the same job for the hop between mail servers.

How it's set up: a record and a file

MTA-STS has two moving parts. The first is a DNS TXT record at _mta-sts.yourdomain.com that signals a policy exists and carries a version ID:

v=STSv1; id=20260613000000

The second — and this is the clever bit — is a policy file served over HTTPS at a fixed location: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. It lists the mode, the valid MX hostnames, and how long to cache the policy:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
max_age: 604800

Serving the policy over HTTPS is what makes it trustworthy. Because a sending server retrieves it through a TLS connection with a valid certificate, an attacker can't forge or tamper with the policy without breaking the web's certificate trust — the same chain of trust that secures any HTTPS site. MTA-STS effectively borrows the web's certificate system to protect email.

The three modes

The mode field is how you roll this out safely:

• testing — sending servers check your policy and report failures, but still deliver the mail. This is where you start.
• enforce — a TLS or certificate failure now blocks delivery. This is the real protection.
• none — used to cleanly withdraw a policy.

Jumping straight to enforce is how people break their own inbound mail — which is exactly why the second standard exists.

TLS-RPT: the visibility half

MTA-STS on its own is flying blind — if a policy is misconfigured, mail just fails, and you hear about it from frustrated senders. TLS-RPT (SMTP TLS Reporting) fixes that with another small DNS TXT record, at _smtp._tls.yourdomain.com:

v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com

It asks sending servers to send you a daily aggregate report of how TLS delivery to your domain went — how many connections succeeded, how many failed, and why. With it, the rollout becomes safe and obvious: publish your policy in testing mode, watch the TLS-RPT reports for a couple of weeks, fix anything that turns up, and only then switch to enforce. If you've read about DMARC, this is the same reporting idea its aggregate reports brought to authentication, applied to transport.

The other way: DANE

MTA-STS isn't the only way to force encrypted SMTP. The alternative is DANE, which pins your server's certificate directly in DNS using TLSA records. DANE is arguably stronger, but it has a hard prerequisite: it only works if your domain is signed with DNSSEC, because the certificate pin itself has to be tamper-proof in DNS. MTA-STS was designed precisely for the large majority of domains that don't have DNSSEC, leaning on HTTPS and the web's certificate system instead. Many big providers support both, and they coexist happily — if you have DNSSEC, doing both is reasonable; if you don't, MTA-STS is your route.

Who actually enforces it

This only matters if real senders honour your policy — and they do. Gmail, Microsoft 365, and Yahoo all support MTA-STS when sending mail, which covers a large share of the messages most domains receive. Worth being clear on the direction: MTA-STS protects mail flowing in to your domain, and it's the sending servers that enforce the policy you publish. So the value of setting it up is that the big mailbox providers will refuse to hand your inbound mail over an insecure connection.

What it does and doesn't do

MTA-STS and TLS-RPT secure one specific thing: the encrypted transport of mail between servers, and your visibility into it. They don't authenticate the sender — that's still SPF, DKIM, and DMARC. They don't encrypt a message end-to-end so that only the recipient can read it — that's PGP or S/MIME. And they only protect hops where the sending server supports the standard. Think of it as a transport-security layer beneath the authentication layer you've probably already built, not a replacement for any of it.

The takeaway

SPF, DKIM, and DMARC prove who sent an email; MTA-STS and TLS-RPT make sure it can't be silently read or downgraded on the way to you, and let you watch that it's working. The safe path is always the same: publish a policy in testing with TLS-RPT switched on, read the reports, then move to enforce. You can check how a domain's MTA-STS policy and TLS-RPT record are configured with our MTA-STS & TLS-RPT checker.