TLS email encryption: versions, modes, and configuration

TLS (Transport Layer Security) is a cryptographic protocol that creates an encrypted channel between two network nodes. In email it works in two directions: between mail servers when relaying messages (MTA-to-MTA), and between a user's mail client and the server (MUA-to-MTA). Without TLS, message content, including login credentials, travels as plaintext and can be intercepted at any intermediate hop.

SSL and TLS: a short history

SSL (Secure Sockets Layer) is TLS's predecessor, developed by Netscape. SSL 2.0 shipped in 1995, SSL 3.0 in 1996. In 1999, the IETF published TLS 1.0 (RFC 2246), which was essentially a reworked SSL 3.0 with several vulnerabilities removed.

All SSL versions and TLS 1.0/1.1 are officially deprecated (RFC 8996, 2021). In production today you'll find TLS 1.2 (RFC 5246) and TLS 1.3 (RFC 8446). Mail client UIs still show "SSL" in their settings, but that label just means TLS in practice.

What TLS actually protects

TLS gives data in transit three properties:

• Confidentiality. Data is encrypted with a symmetric key (AES-GCM or ChaCha20-Poly1305). A third party cannot read the content.
• Integrity. MAC or AEAD encryption guarantees the data was not modified in transit.
• Server authentication. An X.509 certificate confirms the client connected to the real server, not an impersonator.

One limit worth knowing: TLS encrypts the channel, not the message itself. Once delivered, the message sits on the recipient's server in plaintext. End-to-end content encryption requires S/MIME or PGP, which are separate mechanisms with no connection to TLS.

Two connection modes

• STARTTLS (explicit TLS). The client connects to a standard port (25 for SMTP, 143 for IMAP, 110 for POP3) without encryption. After the greeting exchange, it sends the STARTTLS command. If the server supports it, both sides perform a TLS handshake and switch to an encrypted channel.
• Implicit TLS. Encryption starts immediately on connection, before any data is exchanged. The dedicated ports are 465 (SMTP), 993 (IMAP), and 995 (POP3). RFC 8314 (2018) recommends implicit TLS for client-to-server connections.

Opportunistic vs enforced TLS

For server-to-server relay on port 25, TLS usually runs in opportunistic mode. The sending MTA checks whether the receiving server advertises STARTTLS. If it does, an encrypted connection is established. If not, the message goes as plaintext — a pragmatic tradeoff that favors delivery over strict security.

Enforced TLS refuses delivery when encryption cannot be established. It applies in corporate scenarios where both sides have agreed on security requirements in advance.

The downgrade attack problem

Opportunistic TLS is vulnerable to downgrade attacks. An attacker on an intermediate node can strip the STARTTLS advertisement from the server's response. The sending MTA concludes encryption is unavailable and delivers the message in plaintext. The user never knows.

Two mechanisms address this:

• MTA-STS (RFC 8461) — the domain publishes a policy via an HTTPS-hosted file declaring that its MX servers require TLS. Sending MTAs cache the policy and refuse to fall back to plaintext. It pairs with TLS-RPT (RFC 8460), which generates reports on failed TLS connections.
• DANE (RFC 7672) — uses DNSSEC-signed TLSA records to pin a certificate to a domain. More robust than MTA-STS, but it requires DNSSEC deployment, which limits adoption: as of 2025, roughly 5% of .com domains have DNSSEC enabled.

TLS 1.2 vs TLS 1.3

TLS 1.3 (2018) is the current version. The main differences from 1.2:

• The handshake completes in one round-trip instead of two. Resumed sessions can use 0-RTT, adding no latency at all.
• Weak algorithms were removed: RSA key exchange, CBC-mode ciphers, SHA-1, RC4, DES, 3DES. Only AEAD ciphers remain.
• Forward secrecy is mandatory. Every session gets a unique ephemeral key (ECDHE or DHE), so compromising one session's key does not expose past traffic.

For mail servers, TLS 1.3 means a faster handshake and no legacy cipher exposure. Most modern MTAs — Postfix 3.4+ and Exim 4.93+ — support it with OpenSSL 1.1.1 or newer.

Checking your TLS configuration

A few ways to verify TLS is set up correctly:

• Google Postmaster Tools — shows what share of inbound and outbound mail was delivered over TLS. Below 95% is worth investigating.
• CheckTLS.com — tests whether your MX server supports STARTTLS, which TLS versions and ciphers are available, and whether the certificate is valid.
• openssl s_client — command-line connection that shows the certificate chain, TLS version, and negotiated cipher directly.

TLS and deliverability

Gmail shows a red broken-lock icon next to messages delivered without TLS, which visibly erodes recipient trust. Beyond the warning icon, missing TLS is a negative signal for spam filters. A legitimate sender without TLS in 2026 is an anomaly that draws suspicion.

Google and Yahoo made TLS mandatory for bulk senders starting in 2024. Mail delivered without encryption risks being filtered to spam or rejected outright.