Guide
Mail TLS basics.
How SMTP TLS works, what downgrade attacks look like, and how MTA-STS and TLS-RPT protect your inbound email.
SMTP was built without encryption
The Simple Mail Transfer Protocol (SMTP) was designed in 1982 — before encryption was a concern. Email travels between servers in plaintext by default. STARTTLS was added later as an opportunistic upgrade: if both servers support it, they negotiate TLS. If not, they fall back to plaintext.
The problem: opportunistic TLS isn't enough
Downgrade attacks
An attacker on the network path between two mail servers can strip the STARTTLS command from the SMTP handshake. The sending server thinks the receiver doesn't support TLS and falls back to plaintext. The attacker can then read (or modify) the email.
No certificate validation
Even when STARTTLS succeeds, most mail servers don't validate the receiver's certificate. An attacker can present a self-signed certificate and the sending server will accept it — enabling a man-in-the-middle attack despite TLS being "active."
No failure reporting
Without TLS-RPT, you have no way to know if TLS negotiation is failing for your inbound email. Failures are silent — mail still gets delivered, just unencrypted.
The solutions
Standard
What it does
Protects against
MTA-STS
Tells senders to require TLS when delivering to your domain. Policy hosted via HTTPS.
Downgrade attacks, plaintext delivery
TLS-RPT
Provides reporting on TLS negotiation failures. Daily JSON reports from senders.
Silent TLS failures, misconfiguration blindness
DANE
Pins TLS certificates in DNS using TLSA records (requires DNSSEC).
Certificate substitution, rogue CAs
STARTTLS
Opportunistic TLS upgrade during SMTP handshake.
Passive eavesdropping (but not active attacks)
What to deploy first
1. TLS-RPT (visibility first)
Add a
_smtp._tls
DNS record to start receiving TLS failure reports. This costs nothing and gives you baseline visibility before changing anything.
2. MTA-STS in testing mode
Deploy MTA-STS with
mode: testing. Senders will report failures but won't refuse delivery. Monitor TLS-RPT reports for issues.
3. MTA-STS in enforce mode
After confirming no legitimate delivery issues, switch to
mode: enforce. Senders will now refuse to deliver over plaintext.
4. DANE (optional, advanced)
If you already have DNSSEC, consider adding TLSA records for certificate pinning. This provides the strongest protection but requires DNSSEC infrastructure.
Related tools
Deploy with help
DNS Doctors can set up MTA-STS and TLS-RPT for your domain, host the policy file, and monitor enforcement.