Your DMARC is at p=reject. Your SPF is clean. Every outbound message carries a valid DKIM signature. By every measure the industry has defined, your domain’s authentication stack is complete.
And yet there is a class of attack that none of those records can stop – one that operates not at the policy layer, but on the wire itself, while your email is in motion between servers.
MTA-STS is the standard designed to close that gap. According to PowerDMARC’s 2026 United States DMARC and MTA-STS Adoption Report, only 1.7% of U.S. domains have deployed it. Globally, URIports’ 2026 survey of the top one million domains found fewer than 1% with an active MTA-STS policy. The standard has been published as RFC 8461 since 2018 – eight years old, widely available, and almost nowhere deployed.
The Attack DMARC Was Never Designed to Stop
DMARC, SPF, and DKIM address a specific threat: an attacker impersonating your domain by sending email that claims to come from your address. They answer the question “Is this email actually from who it claims to be from?”
They do not address what happens after the email leaves your mail server and before it arrives at the recipient’s mail server. That segment of the journey – server-to-server SMTP transit – is where a different class of attack operates.
SMTP uses a mechanism called STARTTLS to negotiate encrypted transport between mail servers. The problem is that STARTTLS is announced in cleartext. An attacker positioned between the two servers – either on the network or via a compromised routing node – can intercept the STARTTLS command, strip it, and replace it with a rejection message. The sending server, seeing no TLS offer from the destination, falls back to sending the email in plaintext.
At that point, the attacker can read every word of the message, modify the content before forwarding it, or capture credentials and attachments. Your DMARC record, your DKIM signature, your SPF alignment – none of them are visible to an attacker watching cleartext SMTP traffic. The authentication stack is intact and irrelevant.
This class of attack – known as a STARTTLS downgrade attack – has been observed at national scale. Researchers at the EFF and university teams documented its use by multiple nation-state actors to intercept international email traffic on major SMTP routes.
What MTA-STS Does
MTA-STS (Mail Transfer Agent Strict Transport Security) is the IETF’s answer to STARTTLS downgrade attacks.
The mechanism works in two parts. A domain publishes a text file at a well-known HTTPS path (https://mta-sts.yourdomain.com/.well-known/mta-sts.txt) declaring its TLS policy: the MX hostnames it expects, whether the mode is enforce or testing, and a policy maximum age. It then publishes a DNS TXT record at _mta-sts.yourdomain.com that signals the policy version.
When a sending mail server looks up MTA-STS for your domain and finds an enforce policy, it will only deliver mail to you over a TLS connection with a valid certificate matching the declared MX hostnames. If an attacker strips the STARTTLS offer or presents an invalid certificate, the sending server refuses to deliver – and you receive a TLS-RPT report explaining the failure.
The critical difference from STARTTLS alone: MTA-STS is fetched over HTTPS before the SMTP connection begins. An attacker on the SMTP path cannot tamper with an HTTPS-fetched policy without breaking certificate validation. The policy creates a commitment that STARTTLS negotiation alone cannot create.
TLS-RPT: The Visibility Companion
MTA-STS enforcement without reporting is protection without a dashboard. TLS-RPT (RFC 8460) is the companion standard that closes that loop.
By publishing a _smtp._tls DNS TXT record, you instruct sending mail servers to report every STARTTLS and MTA-STS failure they encounter when delivering mail to your domain. Reports arrive as JSON-formatted summaries once per day – similar in structure to DMARC’s aggregate reports – showing which sending servers attempted delivery, whether TLS negotiation succeeded, and the specific error when it did not.
TLS-RPT tells you whether anyone is actively attempting to downgrade your inbound mail connections, and which legitimate senders are experiencing TLS problems that may be quietly affecting deliverability. Like DMARC in p=none, MTA-STS in testing mode gives you this visibility without blocking any mail – a safe starting point for any domain.
The Adoption Gap
The global adoption figures for 2026 are striking for how low they remain despite the standard’s eight-year history.
PowerDMARC’s analysis found that while 95.7% of U.S. domains have SPF and 95.8% have a DMARC record, only 1.7% have deployed MTA-STS. Even among the 49% of U.S. domains enforcing DMARC at p=quarantine or p=reject, the vast majority have left the transit security gap open.
One bright spot is the United Kingdom. PowerDMARC’s UK report found MTA-STS adoption at 20.6% – more than twelve times the U.S. rate – largely attributable to NCSC (National Cyber Security Centre) guidance that explicitly recommends MTA-STS as part of the UK government email security baseline. Government domains lead at 39.9% adoption. When regulators set clear expectations, organizations respond.
URIports’ 2026 global survey found that MTA-STS deployment across the top one million domains has more than doubled over the past two years. The direction is correct. The pace is not sufficient given the eight years the standard has been available.
How to Deploy MTA-STS
Deploying MTA-STS is a three-step process that does not require on-premise software changes:
Step 1 – Start in testing mode. Before enforcing, publish your MTA-STS policy in mode: testing and enable TLS-RPT reporting. This gives you immediate visibility into TLS failures without blocking any mail. Collect reports for at least two to four weeks to establish a baseline.
Step 2 – Validate your MX configuration. Your MTA-STS policy declares specific MX hostnames. Those hostnames must resolve to servers presenting valid, unexpired TLS certificates from a trusted certificate authority. If any MX host has a certificate mismatch or expiry issue, moving to enforce mode will cause delivery failures for senders that respect MTA-STS. Fix those issues before enforcing.
Step 3 – Switch to enforce mode. Once TLS-RPT reports confirm clean TLS negotiation across your inbound mail flow, update your policy file to mode: enforce. Increment the policy version string in your DNS TXT record so sending servers know to re-fetch the updated policy.
The elapsed time from no MTA-STS to enforce is typically two to six weeks for organizations that manage their own MX infrastructure. Hosted email providers – Google Workspace, Microsoft 365 – handle the MX certificate side automatically, making the policy publication step straightforward.
DMARC and MTA-STS: Complementary, Not Competing
DMARC and MTA-STS protect different surfaces of the same email path.
DMARC answers: “Is this email actually from who it claims to be?” It operates on sender identity and message authentication. It protects against spoofing and domain impersonation – attacks that originate from outside your infrastructure.
MTA-STS answers: “Is this email being delivered over a secure, verified connection?” It operates on the transport layer. It protects against interception and modification while the email is in transit between servers you do not control.
A domain with strong DMARC enforcement but no MTA-STS is securing the identity of the sender while leaving the channel open to inspection. Both records work at the DNS level, both require no on-premise hardware or software, and both are free to publish.
The gap between DMARC’s 95.8% deployment and MTA-STS’s 1.7% is the gap between organizations that have addressed impersonation and organizations that have addressed transport security. Addressing only one side is not a complete email security posture – and the STARTTLS downgrade attack surface remains exactly as exploitable against a p=reject domain as against a p=none domain.
Ready to build a complete email security posture beyond DMARC? Excello Mail helps you configure and monitor the DMARC enforcement layer that underpins a secure email channel. Sign up for free to Excello Mail and see exactly where your domain stands on authentication and beyond.