SMTP Downgrade Attacks: How They Work and How to Defend Against Them

⚡TL;DR

• SMTP transmits emails in plaintext by default. STARTTLS adds encryption but remains vulnerable to downgrade attacks (STARTTLS stripping)
• A network-positioned attacker can strip the STARTTLS option from the server response, forcing plaintext delivery without the sender detecting it
• MTA-STS (RFC 8461) and DANE/TLSA (RFC 7672) enforce mandatory TLS encryption and block these attacks
• Host your MTA-STS policy for free with CaptainDNS: two DNS records are all it takes to protect your domains in under 5 minutes

Every day, billions of emails travel between SMTP servers. Most use STARTTLS to encrypt the connection. But this encryption is opportunistic: if the remote server does not respond with encryption support, the message is sent in plaintext. An attacker positioned on the network can force this behavior with a single network packet.

SMTP downgrade attacks, also known as STARTTLS stripping, exploit this weakness. They allow interception of emails in plaintext, even when both servers support TLS encryption. The problem: neither the sender nor the receiver is notified of the attack.

This article covers the technical mechanism behind these attacks, their variants, real-world impact based on Google's data, and concrete solutions to protect your domains. If you manage email servers or domain security, this guide is for you.

How SMTP delivers your emails

SMTP (Simple Mail Transfer Protocol, RFC 5321) is the protocol used to route emails between servers. Designed in 1982, it includes no native encryption. Every message travels in plaintext between the sending server and the receiving server.

STARTTLS: opportunistic encryption

In 2002, RFC 3207 introduced STARTTLS. This mechanism allows two SMTP servers to negotiate a TLS connection after the initial plaintext connection is established.

The process works as follows:

1. The sending server opens a TCP connection on port 25
2. The receiving server responds with its capabilities, including 250 STARTTLS
3. The sending server issues the STARTTLS command
4. Both servers negotiate a TLS connection
5. The email is transmitted encrypted

S: 220 mx.captaindns.com ESMTP
C: EHLO mail.captaindns.com
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250-STARTTLS        ← server announces TLS support
S: 250 OK
C: STARTTLS            ← client requests encryption
S: 220 Ready to start TLS
[TLS negotiation]
C: EHLO mail.captaindns.com
[Encrypted email transmission]

Why "opportunistic" is the problem

The key word is opportunistic. If the STARTTLS command fails or is not offered, the sending server delivers the email in plaintext without notifying anyone. This is a design choice: RFC 3207 prioritizes message delivery over confidentiality.

This decision creates the vulnerability that downgrade attacks exploit.

Anatomy of an SMTP downgrade attack

An SMTP downgrade attack, or STARTTLS stripping, prevents TLS negotiation between two email servers. The attacker forces a fallback to a plaintext connection.

How does STARTTLS stripping work?

The attacker must position themselves on the network path between the two servers (man-in-the-middle). They intercept TCP packets and modify the receiving server's response:

1. The sending server sends EHLO to the receiving server
2. The receiving server responds with 250 STARTTLS in its capabilities
3. The attacker intercepts this response and removes the 250 STARTTLS line
4. The sending server receives a response with no mention of STARTTLS
5. The sending server concludes the receiver does not support encryption
6. The email is sent in plaintext
7. The attacker reads the message content

[Original response from the receiving server]
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250-STARTTLS        ← present
S: 250 OK

[Response modified by the attacker]
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250 OK              ← STARTTLS removed

The attack is invisible to both servers. The sending server believes the receiver does not support TLS. The receiving server does not know an email was sent to it in plaintext.

Who can launch this attack?

Any entity positioned on the network path:

• Internet service providers (ISPs): control traffic routing
• Intermediate network operators: internet exchange points (IXPs)
• Local network attackers: public Wi-Fi, compromised corporate networks
• State actors: mass surveillance documented in several countries

Email transport attack variants

STARTTLS stripping is the most well-known variant, but other attacks target email transport.

DNS spoofing of MX records

The attacker forges the DNS response for the destination domain's MX records. The sending server then delivers the email to a fake server controlled by the attacker.

; Legitimate DNS response
captaindns.com. MX 10 mx.captaindns.com.

; Forged DNS response by the attacker
captaindns.com. MX 10 mx.attacker.com.

DNSSEC protects against this attack by cryptographically signing DNS responses.

TLS certificate attacks

Even if STARTTLS is negotiated, SMTP does not validate the receiving server's certificate by default. An attacker can present a self-signed or invalid certificate, and the sending server will accept the connection without verification.

MTA-STS and DANE enforce certificate validation, blocking this variant.

BGP hijacking

An attacker announces false BGP routes to redirect network traffic to their own equipment. This attack targets the network infrastructure and can affect all traffic, not just email.

Real-world impact: who is affected?

Google's data

Google's Transparency Report on email encryption in transit provides concrete data:

• Over 90% of inbound emails to Gmail are encrypted with TLS
• Over 90% of outbound emails from Gmail use TLS
• Some regions and providers remain below 70%

These numbers show that SMTP encryption has improved, but gaps remain. Every unencrypted email represents an opportunity for a downgrade attack.

Most exposed sectors

Sector	Risk	Reason
Healthcare	High	Patient data, HIPAA/GDPR compliance
Finance	High	Sensitive financial information
Legal	High	Professional privilege, client confidentiality
Government	Medium	Citizen data, internal processes
SMBs	Medium	Often under-configured email infrastructure

Documented attacks

Research published by the EFF and APNIC has documented large-scale STARTTLS stripping by network operators in multiple countries. These attacks do not target a specific domain: they intercept all SMTP traffic passing through the compromised infrastructure.

How to protect against downgrade attacks

Four complementary mechanisms secure email transport.

MTA-STS (RFC 8461): mandatory TLS encryption

MTA-STS allows a domain to publish a policy that requires sending servers to use TLS encryption. The policy is hosted on an HTTPS server - a separate, authenticated channel that an attacker cannot compromise with STARTTLS stripping.

How it works:

1. The sending server discovers the TXT record _mta-sts.captaindns.com
2. It downloads the policy from https://mta-sts.captaindns.com/.well-known/mta-sts.txt
3. The policy specifies authorized MX servers and the mode (testing/enforce)
4. In enforce mode, the server refuses to send in plaintext

Advantage: does not require DNSSEC. Works with any registrar.

Limitation: the first request (before caching) remains vulnerable (TOFU, Trust On First Use).

DANE/TLSA (RFC 7672): certificate anchored in DNS

DANE publishes the TLS certificate fingerprint directly in a TLSA DNS record. The sending server verifies that the presented certificate matches the one declared in DNS.

Advantage: no TOFU. Verification is immediate from the first connection.

Limitation: requires DNSSEC across the entire DNS chain, which limits adoption.

TLS-RPT (RFC 8460): visibility on failures

TLS-RPT does not block attacks, but it makes them visible. Sending servers that support TLS-RPT send daily reports on TLS negotiation failures.

These reports help detect:

• Downgrade attempts
• Expired or invalid certificates
• Configuration issues on your MX servers

Set up TLS-RPT with our TLS-RPT generator to receive these reports.

DNSSEC: DNS protection

DNSSEC cryptographically signs DNS responses, preventing MX record spoofing. It is the foundation for DANE, but also strengthens MTA-STS security by protecting the _mta-sts record resolution.

🎯 Recommended action plan

1. Check your current configuration: use the MTA-STS checker to analyze your domain's status
2. Enable MTA-STS in testing mode: host your policy for free with CaptainDNS and monitor TLS-RPT reports for 1 to 2 weeks
3. Set up TLS-RPT: receive TLS failure reports to detect issues before they impact your emails
4. Switch to enforce mode: once reports confirm everything works, enable enforce mode to block unencrypted connections
5. Evaluate DANE: if your registrar and DNS host support DNSSEC, add TLSA records for TOFU-free protection

---

Protect your emails against downgrade attacks now: host your MTA-STS policy for free with CaptainDNS. Two DNS records, zero web servers to manage.

---

FAQ

What is an SMTP downgrade attack?

An SMTP downgrade attack (or STARTTLS stripping) prevents TLS encryption negotiation between two email servers. The attacker, positioned on the network, removes the STARTTLS option from the receiving server's response. The sending server then delivers the email in plaintext, allowing the attacker to read the message content.

How can I detect a downgrade attack on my emails?

Set up TLS-RPT (RFC 8460) for your domain. Compatible sending servers will send daily reports listing TLS negotiation failures. A sudden increase in failures may indicate a downgrade attempt. Also enable MTA-STS in testing mode to receive reports without blocking delivery.

Does MTA-STS protect against all downgrade attacks?

MTA-STS protects against STARTTLS stripping and TLS certificate attacks. It does not protect against DNS spoofing of MX records (use DNSSEC for that) or BGP hijacking. For comprehensive protection, combine MTA-STS with DNSSEC and, if possible, DANE/TLSA.

What is the difference between MTA-STS and DANE?

MTA-STS publishes a policy via HTTPS and works without DNSSEC. DANE anchors the TLS certificate in DNS via TLSA records and requires DNSSEC. MTA-STS suffers from the TOFU problem (the first request is not protected). DANE provides immediate verification. The two are complementary.

Is STARTTLS enough to secure my emails?

No. STARTTLS encrypts the connection opportunistically but does not protect against downgrade attacks or invalid certificates. A network attacker can strip the STARTTLS option or present a fake certificate. MTA-STS or DANE is required to enforce TLS encryption.

Are major providers like Gmail and Outlook vulnerable?

Gmail and Microsoft 365 support MTA-STS as sending servers: they check and honor MTA-STS policies of destination domains. If your domain publishes an MTA-STS policy in enforce mode, Gmail and Outlook will refuse to send in plaintext to your servers, even during a downgrade attempt.

Should I enable both MTA-STS and DANE at the same time?

It is not mandatory, but recommended if your infrastructure supports it. MTA-STS is easier to deploy (no DNSSEC needed) and covers most sending servers. DANE provides additional security (no TOFU) for servers that support it. Both mechanisms coexist without conflict.

📖 Glossary

• STARTTLS: SMTP extension (RFC 3207) that negotiates a TLS connection after establishing a plaintext connection on port 25.
• STARTTLS stripping: attack that removes the STARTTLS announcement from the server response to prevent encryption.
• MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). HTTPS-based policy that enforces TLS encryption for inbound email.
• DANE: DNS-Based Authentication of Named Entities (RFC 7672). Mechanism that anchors the TLS certificate in DNS via TLSA records.
• TLS-RPT: SMTP TLS Reporting (RFC 8460). Reporting mechanism for TLS negotiation failures between email servers.
• TOFU: Trust On First Use. Security model where the first connection is not verified, but subsequent connections are validated against the first.
• DNSSEC: DNS Security Extensions. Cryptographic signature system that authenticates DNS responses and prevents tampering.

📚 Related email transport security guides

• MTA-STS vs DANE: which protocol to choose for securing email transport? (coming soon)
• From testing to enforce: progressive MTA-STS deployment strategy (coming soon)

Sources

• RFC 5321 - Simple Mail Transfer Protocol
• RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security
• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities
• Google Transparency Report - Email encryption in transit