SMTP Downgrade Attacks and MTA-STS

Most people assume their email is encrypted in transit. In reality, SMTP encryption is opportunistic — it works when everything goes right, but an attacker on the network can silently strip it away. This is called an SMTP downgrade attack.

How SMTP encryption works (and doesn't)

When one mail server connects to another, the conversation starts in plaintext. The receiving server advertises STARTTLS support in its EHLO response. If the sending server sees this, it upgrades the connection to TLS before transferring the email.

The problem: this STARTTLS advertisement happens before encryption is established. An attacker who can intercept network traffic can simply remove the STARTTLS line from the server's response. The sending server thinks the receiver doesn't support TLS and sends the email in plaintext.

The anatomy of a downgrade attack

1. Sender connects to receiver: EHLO sender.com
2. Receiver responds with capabilities including 250-STARTTLS
3. Attacker intercepts and removes the STARTTLS line
4. Sender sees no STARTTLS support, sends email in plaintext
5. Attacker reads the email, then forwards it to the receiver

This attack is completely invisible to both the sender and receiver. The email still gets delivered — just without encryption. There's no error, no warning, nothing in the logs (unless you have TLS reporting set up).

Who can perform this attack?

Anyone on the network path between two mail servers:

• ISPs and transit providers: They can see and modify traffic flowing through their networks
• Nation-state actors: Many governments have the capability to intercept traffic at Internet exchange points
• Compromised network equipment: Routers and switches along the path
• Man-in-the-middle via BGP hijacking: Routing traffic through an attacker's network

How MTA-STS prevents downgrade attacks

MTA-STS (Mail Transfer Agent Strict Transport Security) solves this by publishing a policy that says "this domain definitely supports TLS — don't fall back to plaintext." The policy is fetched over HTTPS, which can't be downgraded in the same way.

When a sending server is about to deliver email to an MTA-STS-enabled domain:

1. It checks DNS for _mta-sts.domain.com TXT record
2. If found, it fetches the policy from https://mta-sts.domain.com/.well-known/mta-sts.txt
3. The policy specifies which MX servers accept mail and whether TLS is required
4. If the policy says mode: enforce, the sender will NOT deliver over plaintext, even if STARTTLS is stripped

MTA-STS vs. DANE

DANE (DNS-based Authentication of Named Entities) is an alternative approach that pins TLS certificates in DNS using TLSA records. It requires DNSSEC to be deployed (since the TLSA records must be authenticated).

• MTA-STS: Easier to deploy (no DNSSEC required), policy cached via HTTPS, widely supported by major providers (Google, Microsoft)
• DANE: Stronger security (certificate pinning), but requires DNSSEC infrastructure, less widely supported

For most organizations, MTA-STS is the practical choice. It provides meaningful protection against downgrade attacks without requiring DNSSEC.

Getting started

Deploying MTA-STS is straightforward:

1. Set up TLS-RPT first (for visibility into TLS failures)
2. Deploy MTA-STS in mode: testing (reports failures but doesn't block delivery)
3. Monitor reports for 2-4 weeks
4. Switch to mode: enforce once you've confirmed no issues