STARTTLS stripping is a downgrade attack that turns opportunistic email encryption into no encryption at all, without either mail server realising anything went wrong. It works because opportunistic STARTTLS was designed to fail open — to deliver in plaintext rather than not deliver — and because the decision to encrypt depends on an unauthenticated line of text that an attacker sitting on the network path can simply edit.
Where the vulnerability lives
Recall how STARTTLS begins. The client connects on port 25 in plaintext, sends EHLO, and the server replies with a list of capabilities. If the server supports encryption, that list includes a line reading 250-STARTTLS. The client sees it and issues the STARTTLS command to begin the handshake. The problem is that this entire exchange happens in the clear, before any TLS exists to protect it. Nothing about that 250-STARTTLS line is authenticated, so nothing stops a machine in the middle from tampering with it.
How the strip is performed
An on-path attacker — someone controlling a router, a compromised network segment, or any device that can see and modify the traffic between the two mail servers — watches the plaintext capability response. When the server advertises 250-STARTTLS, the attacker rewrites it on the fly, replacing it with something inert like 250-XXXXXXXA of the same length so the SMTP parser accepts the response but no longer recognises a STARTTLS offer. The sending server reads the doctored list, concludes the receiver does not support encryption, and — because opportunistic STARTTLS falls back to plaintext rather than refusing to deliver — sends the message and all its metadata in the clear. A more aggressive attacker can instead intercept the client's STARTTLS command and return a 454 temporary failure, again pushing the sender to give up on TLS and continue unencrypted.
Why it is silent
This is what makes stripping so dangerous. Neither administrator sees an error. The sending server did exactly what its configuration told it to do — try TLS, fall back gracefully if it is not on offer — and the message was delivered successfully. There is no bounce, no warning, no log entry screaming that something is wrong. The only trace is that a connection which should have been encrypted was not, and the attacker now has the full plaintext of the message, its sender and recipients, and anything else the SMTP conversation revealed. Because the fallback is a feature, not a bug, the attack hides inside normal-looking behaviour.
The root cause: trust before encryption
Every downgrade attack shares the same shape — a security decision made over an unauthenticated channel before protection is established. Opportunistic STARTTLS on port 25 has no way to know, in advance, whether a given destination is supposed to support TLS. So when the capability disappears, the sender cannot distinguish a genuinely plaintext-only server from a stripped connection. The fix is to give senders that advance knowledge from a source the attacker cannot rewrite in flight.
MTA-STS: policy over HTTPS
SMTP MTA Strict Transport Security lets a receiving domain publish a policy declaring that senders must use STARTTLS with a valid, matching certificate, and must refuse to deliver if they cannot. The policy is fetched over HTTPS from a well-known URL on the domain and its presence is signalled by a DNS TXT record, so a sender learns the requirement out of band, through a channel protected by the web PKI, before it ever opens the SMTP connection. Now a stripped STARTTLS is not a graceful fallback — it is a policy violation, and a compliant sender in enforce mode will refuse to deliver in plaintext rather than hand the message to an attacker. Our sibling MTA-STS Studio checks that your policy is published, valid and set to enforce.
DANE: pinning through DNSSEC
DANE takes a different route to the same guarantee. It publishes a TLSA record in DNS that binds the receiving server's certificate or public key to its name, and it relies on DNSSEC to make those records tamper-proof. A DANE-aware sender looks up the TLSA record, sees that the destination is committed to TLS, and requires a handshake that matches the pinned certificate. Because DNSSEC signs the record, an attacker cannot strip the commitment the way they strip a plaintext capability line. MTA-STS leans on the web certificate authorities and HTTPS; DANE leans on DNSSEC. Many well-run mail systems deploy both, and they are complementary rather than competing.
It is worth being clear about the threat model, because stripping is not hypothetical. Large-scale measurement studies of internet mail have repeatedly found meaningful fractions of connections where STARTTLS was tampered with in transit, and the technique requires only a position on the network path — a compromised router, a hostile ISP, or an intercepting middlebox — not a break in TLS itself. That is precisely why fail-open opportunism was always a stopgap. The whole point of MTA-STS and DANE is to convert "encrypt if you can" into "encrypt or do not deliver", so the attacker's easiest move — quietly deleting a capability line — stops working.
What to check on your own domain
Stripping is invisible from the inside, so verification matters. Confirm that STARTTLS is offered on every MX host and that the certificate is valid, in date and matches the hostname. Then close the fallback gap with a published, enforcing MTA-STS policy, DANE TLSA records, or both, so a stripped connection is refused rather than silently downgraded. While you are auditing the domain, verify message authentication with DKIM Studio — transport encryption stops eavesdropping on the wire, but DKIM is what proves a message genuinely came from you and was not altered. This site's tester exercises the STARTTLS negotiation against your MX hosts so you can confirm encryption is actually offered before you rely on a policy to require it.