Mail between servers is usually encrypted, and that encryption is usually opportunistic — the sending server offers STARTTLS, the receiving server accepts, and if anything goes wrong the message is delivered in plaintext instead. Nobody is told.

MTA-STS closes that gap. It lets a domain declare that mail to it must use TLS with a valid certificate, and that a sender should refuse to deliver rather than fall back. TLS-RPT is the reporting half: it tells you when delivery failed for a TLS reason you would otherwise never have learned about.

Adoption is low and coverage is high

Early 2026 figures put MTA-STS at roughly 0.7% of the top million domains. That has more than doubled since 2024, and it still sounds like a rounding error.

It is not, because adoption is not evenly distributed. Google and Microsoft implemented support early, so for a typical sender more than half of outbound traffic goes to domains with a policy. The percentage of domains is small; the percentage of mail is not.

How a policy is published

Two pieces, and both are required:

A TXT record at _mta-sts.yourdomain holding a version and an ID:

v=STSv1; id=20261005120000

And a policy file served over HTTPS at https://mta-sts.yourdomain/.well-known/mta-sts.txt, listing the mode, the MX hosts it applies to, and a lifetime in seconds.

The ID is what signals a change. A sender caches your policy for its lifetime and only re-fetches when the ID in DNS differs from the one it has. Change the policy file without changing the ID and nobody notices for up to the cached lifetime.

The three modes, in the order you should use them

none — a published policy that asserts nothing. Used to retire a policy cleanly rather than deleting it, which would leave caches holding the old one.

testing — senders evaluate the policy, do not act on failures, and report what happened via TLS-RPT. This is where you start and where you stay until the reports are clean.

enforce — senders refuse to deliver when the policy cannot be satisfied. This is the point of the exercise and also the point at which a certificate mistake stops your inbound mail.

A phased rollout is becoming the standard approach for good reason. Testing mode costs nothing and tells you whether enforce would have broken anything.

Setting up TLS-RPT first

Publish the reporting record before the policy, so you have data from the moment the policy goes live:

_smtp._tls.yourdomain TXT "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain"

Reports arrive daily as JSON, usually gzipped. Each one covers a reporting domain's attempts to reach you and includes the policy they found, successful and failed connection counts, and a reason for each failure.

The failures worth acting on are certificate name mismatches, expired certificates, and MX hosts listed in your policy that no longer exist. All three are invisible without this reporting.

What breaks

In practice, three things:

An MX host missing from the policy file. Add a backup MX and forget the policy, and enforcing senders will refuse to use it — which is exactly when you need it.
Certificate renewal that changes the name. The certificate must match the MX hostname, not your domain.
The HTTPS endpoint going down. Senders with a cached policy are fine; senders without one cannot fetch it. Serve the file from something at least as reliable as your mail.

Is it worth doing

For inbound mail to a domain that receives anything sensitive, yes. It is the only mechanism that prevents a downgrade attack on mail addressed to you, and in testing mode it carries no delivery risk at all.

The reporting alone justifies it. Most operators who publish TLS-RPT find at least one thing they did not know was failing.

Note that this is about mail to your domain. For mail you send, the equivalent concerns are authentication and alignment — start with the DMARC checker and the policy guide.

MTA-STS and TLS-RPT: 0.7% adoption, half your traffic