TLS and Email: Why SMTP Encryption Is Non-Negotiable

You may have seen a red padlock in Gmail with the message “The sender hasn’t encrypted this message”. This means the email traveled in plain text between servers, without TLS encryption. In 2026, that’s a serious red flag.

Why Encrypt Emails in Transit

Without TLS, email content travels in plain text between the sending and receiving servers. Anyone intercepting network traffic (man-in-the-middle attack, compromised ISP, public Wi-Fi) can:

Read the entire message content
Modify the message in transit
Extract attachments, credentials, links

TLS encryption creates an encrypted tunnel between the two SMTP servers. Even if intercepted, the traffic is unreadable.

How STARTTLS Works

SMTP doesn’t encrypt anything by default. Encryption is negotiated via the STARTTLS extension:

The sending server connects to the recipient server on port 25
The recipient server announces 250-STARTTLS in its banner
The sending server sends the STARTTLS command
Both servers negotiate a TLS tunnel (certificate exchange, cipher selection)
The email is transmitted through the encrypted tunnel

S: 220 mx.example.com ESMTP
C: EHLO sender.example.com
S: 250-mx.example.com
S: 250-STARTTLS
S: 250 OK
C: STARTTLS
S: 220 Ready to start TLS
[... TLS negotiation ...]
C: EHLO sender.example.com
[... encrypted email delivery ...]

Opportunistic vs Enforced TLS

Opportunistic TLS (Default)

Most servers use opportunistic TLS: if the recipient server supports STARTTLS, encrypt. Otherwise, send in plain text. Better than nothing, but vulnerable to downgrade attacks: an attacker can strip the STARTTLS announcement from the banner, forcing plain text delivery.

Enforced TLS

The sending server refuses to deliver the email if TLS isn’t available. More secure, but risks non-delivery if the recipient doesn’t support TLS.

MTA-STS: Enforcing TLS Properly

MTA-STS (Mail Transfer Agent Strict Transport Security) solves the opportunistic TLS problem. It’s the SMTP equivalent of HSTS for the web.

How It Works

The recipient domain publishes a DNS TXT record:

_mta-sts.example.com TXT "v=STSv1; id=20260524"

And hosts a policy file over HTTPS:

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

The sending server checks this policy and refuses plain text delivery if the mode is enforce

MTA-STS Modes

Mode	Behavior
`none`	No policy (disabled)
`testing`	TLS required, but failures are only reported (no blocking)
`enforce`	TLS required, emails are rejected if TLS fails

Start with testing, analyze reports, then switch to enforce.

Check your configuration with the free MTA-STS Checker.

DANE: TLS Verified by DNSSEC

DANE (DNS-Based Authentication of Named Entities) uses TLSA DNS records secured by DNSSEC to publish the TLS certificate fingerprint of the mail server.

Unlike MTA-STS, DANE doesn’t require hosting an HTTPS file. It’s more robust (protected by DNSSEC) but requires both the domain and DNS resolver to support DNSSEC, which limits adoption.

TLS-RPT: Encryption Reports

TLS-RPT (TLS Reporting) lets you receive reports about TLS negotiation failures, just like DMARC provides reports on email authentication.

DNS configuration:

_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

TLS reports indicate:

Failed TLS connection attempts
Certificate issues (expired, invalid name)
MTA-STS or DANE policy failures
Detected downgrade attacks

If you use Sender Audit, TLS reports are automatically parsed and visualized in your dashboard.

Check your TLS-RPT setup with the free TLS-RPT Checker.

Which Cipher Is Being Used?

Not all TLS ciphers are equal. Modern versions use TLS 1.2 or 1.3 with robust ciphers:

Version	Status
SSL 2.0 / 3.0	Obsolete, vulnerable
TLS 1.0	Deprecated since 2020
TLS 1.1	Deprecated since 2020
TLS 1.2	Acceptable
TLS 1.3	Recommended (faster, more secure)

A free audit tells you the TLS version and cipher used to deliver your test email.

What to Do If Your ESP Doesn’t Use TLS

Check: run an audit to see if TLS is being used
Contact your ESP: ask about their TLS roadmap
Switch ESPs if needed: in 2026, not supporting TLS is a dealbreaker

Major providers (Google, Microsoft, Yahoo, Apple) already penalize emails received without TLS, showing visual warnings to recipients.