What is MTA-STS (and TLS-RPT)?

Email's default encryption is optional by design: STARTTLS upgrades a connection to TLS if both sides agree, and silently falls back to plaintext if not. That "if" is the gap MTA-STS was built to close. SMTP was designed in 1982, long before encryption was a priority; TLS was bolted on later as the optional STARTTLS extension, and MTA-STS is the modern answer to making that optional encryption effectively mandatory for domains that want it.

Why opportunistic TLS isn't enough

Because STARTTLS can be downgraded, an attacker positioned on the network path can strip the TLS offer and force the message into plaintext — without either mail server noticing. MTA-STS removes the silent fallback: when a domain enforces a policy, mail to it is delivered over verified TLS or not at all.

How a sender uses the policy

The clever part of MTA-STS is where the “does this domain require TLS?” decision happens. With plain STARTTLS, that negotiation occurs inside the SMTP conversation itself — the exact channel an on-path attacker can tamper with. MTA-STS moves the decision out of that conversation and into a policy the sender fetches separately, over HTTPS, before it delivers. The attacker can’t strip a policy it never sees.

In sequence: a sending server about to deliver to your domain looks up the _mta-sts DNS record, sees a policy exists, and fetches the policy file over HTTPS from your mta-sts subdomain. It caches that policy for the duration of max_age and reuses it for subsequent mail rather than re-fetching every time. Then, on each delivery, it requires that the TLS connection to your MX is valid per the policy — and if it can’t establish that, an enforced policy means the message is held, not downgraded. Because the policy is cached, a change you make isn’t seen instantly; senders pick it up when their cached copy expires.

The three pieces

Piece	Where	Role
DNS TXT record	_mta-sts.yourdomain	Announces a policy exists; carries a version id
Policy file (HTTPS)	mta-sts.yourdomain	Lists MX hosts, mode, and max_age
TLS-RPT	_smtp._tls.yourdomain	Collects reports of TLS failures

The policy file is served over HTTPS by a web server — which is how it's deployed alongside an MTA whether or not the MTA hosts it natively.

What the record and policy look like

The DNS record is small — it just announces a policy and carries an id that you change whenever the policy changes, so senders know to re-fetch. The policy file itself lists your MX hosts, the mode, and how long to cache it:

# DNS: _mta-sts.example.com  TXT
v=STSv1; id=20260605T120000Z

# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.com
max_age: 604800

The mx: lines list which hostnames are allowed to receive your mail (wildcards are permitted, though not every sender implements wildcard matching perfectly). max_age is the cache lifetime in seconds. The id in DNS is just a label — commonly a timestamp — whose only job is to differ from the previous value so a change is noticed.

What actually gets validated

“Valid TLS” under MTA-STS is specific — it means more than “some encryption happened.” The standard requires the sender to confirm three things about the certificate your MX presents: it is signed by a trusted root CA, it is not expired, and its Subject Alternative Name matches the MX hostname the connection used. Fail any of those and validation fails, and under enforce the mail isn’t delivered.

This is why certificate hygiene on your MX suddenly carries real weight once you enforce MTA-STS: an expired cert, an incomplete chain, or — the classic — a certificate whose SAN doesn’t list your actual MX hostname will quietly pass ordinary opportunistic STARTTLS but fail MTA-STS validation outright. The same certificate requirements show up from the sending side as TLS handshake failures; MTA-STS simply makes them mandatory rather than optional.

Testing, then enforce

Roll it out in testing mode first: receivers report TLS failures via TLS-RPT but still deliver, so you can confirm legitimate senders connect cleanly before anything is blocked. Once the reports are clean, move to enforce. Going straight to enforce without watching the reports is how operators accidentally block their own inbound mail.

TLS-RPT: the feedback loop

MTA-STS without reporting is flying blind, which is why TLS-RPT (SMTP TLS Reporting, RFC 8460) is its companion. You publish a small TXT record at _smtp._tls.yourdomain naming a destination — an address or URI — and participating senders send you aggregate reports of how TLS delivery to your domain went: which connections succeeded, which failed, and why. Unlike DMARC’s dense XML, TLS reports are straightforward to read.

The failure categories are exactly what you’d want to catch: certificate validation errors, handshake failures, a policy that couldn’t be fetched, or TLS simply being unavailable. During a testing-mode rollout these reports are how you discover the problems that would otherwise become bounces under enforce — a forgotten backup MX with an expired certificate, a hostname your policy doesn’t cover, a sender that can’t reach your policy file. Wire up TLS-RPT first, read it for a few weeks, and you move to enforce knowing what will happen rather than hoping.

Deploying it safely

The standard rollout is deliberately gradual, and skipping steps is how people block their own inbound mail:

1. Publish in testing mode with a short max_age (say a day) and a policy that lists your real MX hosts. Senders behave as if TLS is required but still deliver on failure.
2. Enable TLS-RPT so you actually receive the failure reports the testing mode generates.
3. Monitor for two to four weeks, fixing anything the reports surface — certificate SANs, missing MX entries, an unreachable policy file.
4. Switch to enforce once the reports are clean, and lengthen max_age so the policy is cached longer and is harder to strip.

Two operational notes save grief. Change the DNS id every time you edit the policy, or senders will keep using the cached old one. And make sure the policy file is reliably reachable over HTTPS with its own valid certificate on the mta-sts subdomain — if senders can’t fetch the policy, they can’t honour it.

MTA-STS vs DANE

Both let a domain require TLS for inbound mail. DANE publishes a TLSA record and relies on DNSSEC; MTA-STS uses an HTTPS-hosted policy and the public certificate authority system, so it works without DNSSEC and is broadly supported. They're complementary — operators often run MTA-STS for reach and add DANE where DNSSEC is already deployed.

The trade-off is a trust-model choice. DANE is arguably stronger because it doesn’t depend on the public CA system at all — the TLSA record, anchored in DNSSEC, pins exactly which certificate is valid — but it requires DNSSEC, which remains unevenly deployed and adds operational complexity. MTA-STS deliberately trades that for reach: by leaning on HTTPS and CAs, it works for any domain that can host a web page, no DNSSEC required, at the cost of a narrow downgrade risk DANE doesn’t have. One important rule when both are present: a sender that validates MTA-STS must never let it override a failing DANE check — DANE wins where it applies. Running both is a sensible defence-in-depth posture rather than a contradiction.

For most senders the practical takeaway is simpler than the protocol detail: honour whichever policy a recipient publishes, keep your own TLS and certificates clean so you pass either kind of check, and — if you publish for your own domain — pick MTA-STS for breadth, add DANE if you already run DNSSEC.

Where the sender and receiver sides meet

MTA-STS is easy to misread as a single feature when it’s really two obligations that happen to share a protocol. As a receiver, you publish a policy to protect mail arriving at your domain from being downgraded in transit. As a sender, you honour the policies other domains publish — fetching them, validating TLS, and holding mail you can’t deliver securely rather than quietly sending it in the clear. The two are independent: you can do either without the other, and a complete setup does both.

For a self-hosted operation this maps cleanly onto how the engine works. The sending side is automatic in a correctly configured PowerMTA or KumoMTA — it should fetch and respect recipients’ MTA-STS and DANE policies as part of normal delivery, which is exactly why keeping your own outbound TLS current matters. The receiving side — publishing your own policy — is DNS-and-HTTPS work that sits alongside the MTA rather than inside it: a DNS record, a small file on a web server, and a TLS-RPT record. Neither is heavy; the discipline is in the rollout, not the setup.

When and why to bother

MTA-STS isn’t yet a hard regulatory requirement the way SPF, DKIM and DMARC have effectively become for bulk senders, so it’s reasonable to ask when it earns its place. The answer is whenever the confidentiality of mail in transit matters — which, for most organisations handling anything sensitive, is always. Transport encryption is now the overwhelming norm, and the small slice of mail that still falls back to plaintext is precisely where interception happens. MTA-STS removes that fallback for your domain.

There’s also a signalling benefit. A domain that publishes and enforces MTA-STS, alongside clean authentication and modern TLS, looks like a well-run operation to the mailbox providers and security teams that increasingly notice such things. It’s not a deliverability lever in the way authentication is, but it’s part of the same picture of a domain that takes its mail seriously — and for a self-hosted sender building reputation from scratch, every such signal is worth having.

Common deployment mistakes

A handful of issues account for most MTA-STS problems, and all of them surface in TLS-RPT if you’re watching. The most common is certificate-host-mismatch: the certificate your MX presents doesn’t list the MX hostname in its SAN. A frequent version is a hosting provider whose mail server holds a certificate for its own name while your MX points at a hostname under your domain — fine for opportunistic STARTTLS, fatal for MTA-STS.

Next is an unreachable or mis-served policy file. The file must sit at the exact well-known path on the mta-sts subdomain, be served over HTTPS, and that subdomain needs its own valid certificate — separate from your MX certificate. If a sender can’t fetch and trust the policy, it can’t enforce it. Then there’s forgetting to bump the id after editing the policy, which leaves senders honouring a stale cached version, and wildcard MX errors, since not every sender implements wildcard matching identically — list explicit hostnames where you can.

The last is simply jumping to enforce without a testing period, which converts every one of the above from a quiet report line into a blocked message. None of these is hard to fix; the point of the testing-mode rollout is to surface them as reports before they become bounces, which is exactly why the gradual path is worth the patience.

Adoption: you’re already meeting it

Even if you never publish a policy of your own, MTA-STS already affects your sending, because the largest mailbox providers publish enforced policies for their own inbound mail. The big consumer and business platforms — the same Gmail, Microsoft and Yahoo destinations most senders care about — expect a clean, validated TLS connection, and Microsoft even documents how its customers host their MTA-STS policy. So a sender that can’t negotiate valid TLS to those domains isn’t hitting a theoretical edge case; it’s failing a policy that’s live in production today.

That reframes the sender-side obligation from “nice to support” to “necessary to keep working.” Your outbound TLS stack and certificate handling have to be good enough to pass these providers’ validation, which loops straight back to the certificate and protocol hygiene covered earlier. Publishing your own policy is optional and situational; honouring everyone else’s is increasingly just part of delivering mail at all, and a well-configured engine does it without you thinking about it — right up until a certificate lapses and the mail to those domains stops.

The bottom line

MTA-STS fixes a real weakness in email: STARTTLS is optional and strippable, so “encrypted in transit” was never guaranteed. By publishing a policy a sender fetches over HTTPS before delivering — out of reach of an on-path attacker — a domain can require that inbound mail arrives over valid, authenticated TLS or not at all. Three pieces make it work: a DNS record announcing the policy, an HTTPS-hosted policy file with your MX hosts and mode, and TLS-RPT for the failure reports that make a safe rollout possible.

Deploy it in testing mode, watch TLS-RPT for a few weeks, fix what the reports surface — usually certificate SANs and missing MX entries — then move to enforce and lengthen the cache. Treat it as the transport-security layer that sits beside SPF, DKIM and DMARC, not a replacement for them, and add DANE if you already run DNSSEC. If you’d rather not hand-assemble the DNS record, policy file and TLS-RPT, the Auto PMTA Configurator publishes all three at deploy alongside SSL and DMARC, and keeps the sending side honouring recipients’ policies automatically, so the strict, validated TLS that the big mailbox providers now expect on inbound is something your mail simply passes cleanly rather than trips over and gets held on — for legitimate, opt-in sending.