2026-08-11 · RESEARCH · The Offensive Technology team

SMTP TLS Downgrade: The 92% Gap Behind DMARC

An SMTP TLS downgrade attack strips the encryption off email while it is in transit, and most domains cannot stop it. Classic SMTP encryption is opportunistic: servers offer STARTTLS, but if an on-path attacker removes that offer the sending server quietly falls back to cleartext instead of refusing. The only records that make TLS mandatory are MTA-STS and DANE. We resolved the public DNS of the Tranco top 25,000 sites and read those records for the 18,012 domains that receive mail. The result is a sharp split. Authentication is common: 79.3% publish DMARC and 55.2% enforce it. Transit encryption enforcement is rare: only 3.3% publish an MTA-STS policy, 3.6% publish a DANE record, and just 6.5% publish either. Put the two together and the gap is stark: of the domains that enforce DMARC, 92% publish no MTA-STS and no DANE, so their mail is authenticated against spoofing but still downgradeable in transit.

What an SMTP TLS downgrade attack actually is

SMTP between mail servers begins in plaintext. The receiving server advertises its capabilities, and if it supports encryption it lists STARTTLS among them. The sending server then issues STARTTLS and the two negotiate a TLS session. The weakness is in the word opportunistic. If the STARTTLS capability is not advertised, or the TLS handshake fails, or the certificate does not validate, the historical default is not to abort. It is to send the mail in cleartext anyway, on the theory that delivering the message matters more than encrypting it.

That default is what an attacker exploits. An adversary with a position on the network path, an operator at a transit provider, someone who has compromised a router, a state actor at a border, watches the opening plaintext exchange and deletes the STARTTLS line from the receiver's capability list before it reaches the sender. The sender, seeing no offer of encryption, delivers over cleartext. This is STARTTLS stripping, and it is a downgrade rather than a break: nothing is cracked, the protocol is simply steered back to its unencrypted fallback. The message, its attachments, and any password-reset or invoice content ride the wire in the clear. The APNIC operations community has a plain writeup of the mechanism (SMTP downgrade attacks and MTA-STS) if you want the packet-level view.

Two standards close the fallback. MTA-STS (RFC 8461) lets a domain publish a policy that says, in effect, "for my inbound mail, TLS with a valid certificate is required, do not fall back." A sender that has fetched and cached that policy will refuse a stripped connection instead of downgrading. DANE for SMTP (RFC 7672) does the same job by publishing a TLSA record in DNS, authenticated by DNSSEC, that pins what certificate the mail server must present. Either one turns a silent downgrade into a refused delivery. Neither is on by default, and that is the whole story of the numbers below.

Why DMARC does not help here

It is worth being precise about this, because the two problems are constantly conflated. DMARC, SPF, and DKIM are authentication. They let a receiver decide whether the visible From address is legitimate, and DMARC tells the receiver what to do when it is not. That is how you stop someone forging your domain. We measured that layer in an earlier post on the gap between publishing and enforcing DMARC, and it matters. But authentication and encryption are orthogonal. DMARC operates on who the message claims to be from. A downgrade attack operates on the transport carrying the message. You can pass every authentication check with flying colours and still have the connection stripped to cleartext, because DMARC never had an opinion about the transport in the first place.

So a domain at p=reject with perfectly aligned SPF and DKIM has solved spoofing and done nothing about interception. The mail that arrives is provably from the right sender and was readable by anyone on the path. That is the confusion this measurement exists to correct: a green DMARC check is not a lock on the envelope.

The data: authenticated, not encrypted

Here is the adoption picture across the 18,012 mail-receiving domains in the sample. The authentication bar is tall. The two bars that actually stop a downgrade are stubs.

The transport-security mechanisms broken out, with what each one buys, are below. Read the last two rows together: adding up MTA-STS and DANE, only a small minority of mail domains have any enforcement against a downgrade, and almost none run both.

One detail in that table is worth pausing on. DANE (3.6%) is marginally more common than MTA-STS (3.3%), which cuts against the usual assumption that MTA-STS won because it needs no DNSSEC. The two barely overlap: only 0.3% of mail domains publish both. In practice these are two camps. Providers and country-code zones that already sign with DNSSEC lean DANE, everyone else who bothers at all leans MTA-STS, and the union of both efforts still leaves 93.5% of mail domains with no enforcement at all.

The 92% gap

The number worth remembering is the cross-tab. Of the 9,945 domains that enforce DMARC at quarantine or reject, 9,192, or 92%, publish neither an MTA-STS policy nor a DANE record. These are not stragglers who ignored email security. They are the domains that did the harder, more visible work of getting DMARC to enforcement, and then stopped one layer short. They have decided that a forged sender is unacceptable, which is correct, while leaving the real message readable in transit to anyone positioned to strip the session.

Frame it from the attacker's chair, because that chair decides whether a control matters. Suppose you want to read or alter mail flowing to a target, not forge it. You are looking for a position on the path and a domain that will downgrade. You check the target's DNS the same way we did. If the domain publishes an MTA-STS policy in enforce mode, or a DANE record on a signed zone, a sending server that respects it will refuse to hand you a cleartext session, and your downgrade fails at the sender. If the domain publishes neither, which describes 92% of the enforcing set and 93.5% of all mail domains, opportunistic STARTTLS is the rule and a strip returns cleartext. The DMARC posture you also see in that DNS lookup changes nothing about this outcome. You were never going to forge the sender. You were going to read the mail.

What makes this number worth citing is how it was produced. This is independent passive measurement, not vendor telemetry. We did not report on mail some product of ours filtered, and we did not extrapolate from one provider's inbound stream. We read the public policy records that every sending server on the internet reads, for a fixed sample on a fixed date. Prior adoption surveys reach the same conclusion from different vantage points: independent trackers such as the URIports MTA-STS survey put adoption in low single digits and rising slowly, which lines up with what we see in the raw DNS.

How to check and fix your own domain

You do not need a tool or a signup. A DNS query is a passive read of records that are already public, so you can run these against your own domain right now.

• Check for MTA-STS. Run dig TXT _mta-sts.yourdomain.com +short. A record starting v=STSv1 means you announce a policy. If it is empty, you have no MTA-STS. Note that the record only points at a policy; the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt must say mode: enforce to actually block, not mode: testing.
• Check for DANE. First find your mail servers with dig MX yourdomain.com +short, then for each MX host run dig TLSA _25._tcp.that-mx-host +short. A TLSA record means DANE is in play. DANE only validates on a DNSSEC-signed zone, so confirm signing with dig DS yourdomain.com +short.
• Turn on reporting. Publish a TLS-RPT record (RFC 8460) at _smtp._tls.yourdomain.com so failed handshakes and downgrades are reported back to you instead of staying invisible. It does not block anything, but it is how you find out a downgrade is happening.

If both the MTA-STS and TLSA lookups come back empty, your inbound mail is protected against forgery and exposed to interception. The fix is to publish an MTA-STS policy in enforce mode, or a DANE TLSA record on a signed zone, or both. Doing either puts you in the small minority. The judgment behind rolling one out without breaking legitimate delivery is the same judgment behind knowing which of your other exposed controls actually matter, which is the point of reading a surface the way an attacker does rather than trusting the green checks.

What this does not prove

Honest limits, because a number without its caveats is marketing.

• Tranco ranks by aggregated popularity, not traffic. The Tranco list combines several provider rankings to be stable and hard to game, but it is not a traffic census. Read these figures as one honest slice of the popular web, not the whole internet.
• MTA-STS is measured at the DNS signal. We counted a domain as having MTA-STS if it publishes the _mta-sts record. We deliberately did not fetch the policy file, which would mean contacting the domain's web host, so we cannot separate mode: enforce from mode: testing. The share actually enforcing is therefore at or below 3.3%, which makes the gap wider, not narrower.
• DANE is measured by TLSA presence. We checked for a TLSA record on the MX hosts, up to five per domain. A published record signals intent and configuration; we did not verify the DNSSEC chain or that every sender validates it, so treat 3.6% as the ceiling of correctly working DANE.
• It is a snapshot. DNS changes daily. These figures describe 11 August 2026, not a trend, though they agree with independent surveys that show adoption low and climbing slowly.
• Enforcement in transit still depends on the sender. MTA-STS and DANE only help when the sending server honours them. A publisher does the right thing by advertising the policy; a sender that ignores it can still downgrade. The records are necessary, not by themselves sufficient.

Frequently asked questions

What is a STARTTLS downgrade attack?

It is when an attacker on the network path between two mail servers removes the server's offer to switch to TLS from the plaintext start of the SMTP session. Because opportunistic STARTTLS falls back to cleartext when no TLS is offered, the sender then delivers the mail unencrypted and the attacker can read or alter it. MTA-STS and DANE close the fallback by telling the sender TLS is required.

Is SMTP encrypted in transit by default?

Not reliably. Most servers offer STARTTLS, but classic SMTP TLS is opportunistic: if the offer is missing or the certificate fails to validate, the sender silently falls back to cleartext. Encryption happens when nothing interferes, but an active attacker can strip it. Only 6.5% of the mail domains we measured make TLS mandatory with MTA-STS or DANE.

Does DMARC encrypt email in transit?

No. DMARC, with SPF and DKIM, authenticates the sender so a receiver can spot a forged From address. It says nothing about whether the connection is encrypted. A domain can enforce DMARC at p=reject and still have its mail delivered in cleartext after a downgrade. In our sample 92% of DMARC-enforcing domains published no MTA-STS or DANE.

Does MTA-STS prevent TLS downgrade attacks?

Yes, that is its job. MTA-STS publishes a policy telling sending servers your domain requires TLS with a valid certificate, so a sender that has cached the policy refuses a stripped connection rather than falling back. Its one limit is trust-on-first-use: a sender that has never fetched your policy is not yet covered, which is where DANE, anchored in DNSSEC, is stronger.

What is the difference between MTA-STS and DANE?

Both force TLS on inbound SMTP but anchor trust differently. MTA-STS relies on the web certificate system plus trust-on-first-use and needs no DNSSEC. DANE publishes a TLSA record authenticated by DNSSEC, which removes the first-use gap but requires a signed zone. In our census they were adopted at nearly the same low rate, 3.3% and 3.6%, and only 0.3% of mail domains published both.

What percentage of domains have deployed MTA-STS?

In our August 2026 census of the Tranco top 25,000, of the 18,012 domains receiving mail, 3.3% published an MTA-STS record. DANE was at 3.6% and TLS-RPT at 3.9%. Counting either enforcement control, 6.5% require TLS in transit, against 79.3% publishing DMARC.

How do I check if my own domain resists an SMTP downgrade?

Run dig TXT _mta-sts.yourdomain.com +short and look for v=STSv1, and dig TLSA _25._tcp.your-mx-host +short for each MX host. If both are empty, your inbound mail relies on opportunistic STARTTLS and can be downgraded. Publishing an MTA-STS policy in enforce mode, or a DANE record on a signed zone, closes the gap.

Related reading

• Is p=none enough? Publishing DMARC is not the same as enforcing it. The authentication layer this post sits next to.
• How exposed are the world's busiest domains to email spoofing? The presence question for the anti-spoofing side.
• How many top domains restrict who can issue their certificates? The same passive-DNS method, applied to CAA records.