SPF, DKIM, and DMARC authenticate a message’s sender, but none of the three protects the path a message takes between two SMTP servers. A malicious server sitting on that path can still offer a fallback to an unencrypted connection, intercepting or altering the content without either side noticing. MTA-STS (RFC 8461) closes that gap by enforcing TLS at delivery time, and TLS-RPT (RFC 8460) provides the means to monitor negotiation failures day after day.
The problem MTA-STS solves: the silent TLS downgrade
For years, most SMTP servers have negotiated STARTTLS before delivery. The catch is that this negotiation stays opportunistic: if it fails, the legacy SMTP protocol allows a fallback to an unencrypted connection rather than blocking the send. An attacker positioned to intercept traffic, through DNS hijacking, BGP hijacking, or a compromised relay, can force that fallback simply by breaking the TLS negotiation, without needing to crack any encryption at all. MTA-STS takes that choice away from the sending server: once the policy is published and honored, missing valid TLS becomes grounds to refuse the send rather than a silent downgrade. DANE, which relies on DNSSEC, aims at the same goal through a different route, but its rollout depends on a signed DNS zone that few hosts still offer as standard; MTA-STS, by contrast, only needs a TXT record and an HTTPS file.
Deploying an MTA-STS policy step by step
Three pieces make up an MTA-STS policy: a DNS record signaling its existence and version, a policy file served over HTTPS on a dedicated subdomain, and a valid certificate for that subdomain. None of this touches the mail server’s own configuration: the policy describes expected behavior for third-party sending servers, nothing changes on the receiving side.
The DNS record looks like this:
_mta-sts.example.com. IN TXT "v=STSv1; id=20261108000000;"
mta-sts.example.com. IN CNAME example.com.
The policy file itself must be reachable at https://mta-sts.example.com/.well-known/mta-sts.txt, served with the Content-Type: text/plain header:
version: STSv1
mode: testing
mx: mail.example.com
mx: mail2.example.com
max_age: 86400
The id field in the DNS record must change with every edit to the policy file: that’s what tells servers that already cached it a new version exists. A plain timestamp, as in the example above, is enough.
Understanding the three modes: none, testing, and enforce
The mode field in the policy file determines the actual behavior applied by sending servers that honor MTA-STS.
| Mode | Behavior on TLS failure | Recommended use |
|---|---|---|
none | No blocking, the policy is ignored in practice | Temporary deactivation without removing the policy |
testing | The email still goes out despite the failure, but it’s reported via TLS-RPT | Observation phase before going live |
enforce | The email isn’t delivered without valid TLS | Final policy, after validation in testing mode |
enforce without a testing phase risks silently blocking legitimate email if an MX record changes, a certificate expires without auto-renewal, or a misconfigured outbound relay fails TLS negotiation. The testing mode, kept running for several weeks, exists precisely to catch these cases before they cost a delivery.Turning on TLS-RPT to receive failure reports
TLS-RPT works independently of MTA-STS, but the two complement each other naturally: one enforces encryption, the other reports what happens when negotiation fails, whether the cause is MTA-STS, DANE, or a plain opportunistic TLS policy. Turning it on comes down to a single DNS record:
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Servers that support TLS-RPT then send an aggregate report, usually daily, as compressed JSON, to the address declared in rua. The principle echoes the aggregate reports described in the SPF, DKIM, and DMARC authentication guide: a regular summary rather than a real-time alert, built for automated processing rather than daily manual reading.
Reading and acting on a TLS-RPT report
A TLS-RPT report groups connection attempts by the policy observed, MTA-STS, DANE, or none, and by failure type: expired certificate, certificate name not matching the MX, the negotiation itself failing, or an MTA-STS policy that couldn’t be found despite being published. A failure count that jumps right after a change of host or certificate is often the first visible sign of a misconfiguration, before any recipient even reports a delivery problem.
A TLS downgrade to an unencrypted connection raises no alert on the sending side if nothing watches for it: TLS-RPT is, for SMTP transport, what aggregate DMARC reports are for authentication.
Common pitfalls and deployment best practices
Three mistakes come up most often in deployments run by small sending-infrastructure teams. First, forgetting to auto-renew the mta-sts subdomain’s certificate, which turns an enforce policy into a delivery block the moment a renewal is missed. Second, changing the MX list without republishing the policy file with a new id, which leaves sending servers relying on a cached, now-incorrect policy until max_age expires. Third, letting the mx list declared in the policy drift from the domain’s actual MX records: any mismatch flips sender-side validation to failure, regardless of the chosen mode.
Full deployment, for a domain that already handles the usual causes of landing in spam and its SPF, DKIM, and DMARC authentication, typically takes two to four weeks, with most of that time going into observing the testing mode rather than the technical setup itself, which comes down to a handful of DNS records and a static file. The most widely used transactional sending platforms now document their own MTA-STS procedure, which simplifies the certificate and policy-file hosting side for anyone not running their own outbound servers.
What to remember
- MTA-STS stops the silent fallback to an unencrypted SMTP connection by enforcing TLS at delivery time.
- Deployment involves a DNS record, an HTTPS policy file, and a staged mode:
testingbeforeenforce. - TLS-RPT delivers aggregate reports on TLS negotiation failures, whether they come from MTA-STS, DANE, or an opportunistic policy.
- An unrenewed certificate or a policy left unpublished after an MX change are the two most frequent causes of blocking once in
enforcemode.
MTA-STS remains largely under-deployed among shared hosts and small infrastructures, even though its technical setup is noticeably simpler than DMARC’s. The real obstacle is the discipline of republishing the policy with every change to sending infrastructure, not the protocol’s complexity. On domains tracked after adopting it, the testing phase has consistently uncovered at least one misconfigured secondary MX that no one had noticed before, a good reason to treat it as a free audit rather than a security formality. — Simon Janvier
Further reading: the MTA-STS specification (RFC 8461) and the TLS-RPT specification (RFC 8460).
