Infrastructure

TLSTransport Layer Security

Definition

TLS (Transport Layer Security) is the encryption protocol that protects data, including email, as it travels between two servers. It is the successor to SSL, and in email it stops the contents of a message being read or altered by anyone listening on the network. TLS 1.3 is defined in RFC 8446; for SMTP it is usually switched on by the STARTTLS command.

  • Encrypts a connection so email cannot be read or tampered with in transit
  • The successor to SSL; TLS 1.2 and TLS 1.3 are the versions in use today
  • In SMTP it is most often negotiated through the STARTTLS upgrade
  • TLS 1.0 and 1.1 are deprecated by RFC 8996; require 1.2 or 1.3
At a glance
Type Encryption protocol
Replaces SSL
Current versions TLS 1.2 · TLS 1.3
TLS 1.3 spec RFC 8446 (2018)
Deprecated TLS 1.0 / 1.1 (RFC 8996)
In SMTP via STARTTLS or implicit TLS

What TLS does

TLS provides three guarantees for a connection: confidentiality (the data is encrypted so eavesdroppers cannot read it), integrity (tampering is detected), and authentication (a certificate proves the server is who it claims to be). It is the same protocol that secures HTTPS websites, applied here to the link between mail servers.

It is worth being precise about scope: TLS protects email in transit, hop by hop between servers, not at rest in a mailbox, and it is not the same as end-to-end message encryption like PGP or S/MIME. Without TLS, the body, headers, and credentials of an SMTP session cross the internet in plain text for anyone on the path to capture.

TLS versions and the 2026 baseline

TLS grew out of SSL, the protocol Netscape created in the 1990s. The lineage runs SSL 2.0 and 3.0, then TLS 1.0, 1.1, 1.2, and 1.3. The two relevant versions today are:

  • TLS 1.2 (2008): still widely used and considered secure when configured with strong cipher suites.
  • TLS 1.3 (2018, RFC 8446): the current best practice. It has a faster one round-trip handshake, removes obsolete and weak ciphers, and makes forward secrecy mandatory.

The older versions are no longer safe. RFC 8996 (2021) formally deprecates TLS 1.0 and 1.1, and SSL is long dead. A modern mail server should offer TLS 1.2 at a minimum and prefer TLS 1.3.

How TLS is used in email

There are two ways to put a mail connection inside TLS. Explicit TLS starts the session in plain text and upgrades it with the STARTTLS command; this is how almost all server-to-server (MTA to MTA) relay on port 25 is encrypted, and it is opportunistic by default. Implicit TLS encrypts the whole connection from the first byte and is used for mail submission on port 465, as recommended by RFC 8314.

For deliverability, encryption is now an expectation rather than a bonus. Major mailbox providers negotiate TLS on virtually all of their mail, and a server that cannot speak modern TLS looks dated and untrustworthy. Domains that need to guarantee TLS on inbound mail publish an MTA-STS policy or a DANE record so opportunistic STARTTLS cannot be silently stripped.

How a TLS connection is established

The client opens a connection and proposes its TLS versions and cipher suites
The server picks a version and cipher and presents its certificate
Certificate valid: continue Invalid: enforced senders abort
Both sides agree on session keys through the handshake
All further traffic is encrypted and integrity-protected
The email is delivered confidentially over the secured channel

TLS 1.2 vs TLS 1.3

TLS 1.2 TLS 1.3
Released 2008 2018
Handshake 2 round trips 1 round trip
Forward secrecy Optional Mandatory
Weak ciphers Possible if misconfigured Removed from the spec
Status Secure, widely used Current best practice

By the numbers

TLS 1.3
The current best-practice version (RFC 8446), with a one round-trip handshake and mandatory forward secrecy.
TLS 1.2
The recommended minimum for mail servers; anything older is deprecated by RFC 8996.
2021
The year RFC 8996 formally deprecated TLS 1.0 and 1.1.

Common mistakes

Allowing TLS 1.0 or 1.1
Both are deprecated by RFC 8996 and expose the connection to known attacks. Disable them and SSL entirely, leaving only TLS 1.2 and 1.3 enabled.
Treating TLS as end-to-end encryption
TLS secures email only hop by hop in transit, and each server decrypts the message to relay it. It is not the same as PGP or S/MIME, which keep the message encrypted from author to reader.
Letting certificates expire
An expired or mismatched certificate breaks TLS for any receiver that validates it, including senders enforcing MTA-STS or DANE, which can refuse your mail until the certificate is fixed.

Frequently asked questions

What is the difference between TLS and SSL?
TLS is the modern successor to SSL. SSL (versions 2.0 and 3.0) is obsolete and insecure, and the name carried over informally even though the protocol is now TLS. When a mail server or provider says “SSL/TLS” today, it almost always means TLS, ideally version 1.2 or 1.3.
What TLS version should my mail server use?
Offer TLS 1.3 as the preferred version and TLS 1.2 as the minimum, and disable TLS 1.0, 1.1, and all SSL. RFC 8996 deprecates the older TLS versions, and major providers expect modern TLS on the connections they accept and originate.
Is TLS the same as STARTTLS?
No. TLS is the encryption protocol; STARTTLS is the SMTP command that upgrades a plain-text connection to TLS. STARTTLS negotiates TLS but is not encryption itself. The alternative to STARTTLS is implicit TLS, which encrypts the connection from the first byte.
Does TLS encrypt my email end to end?
No. TLS protects each hop of the journey between servers in transit, and every relay along the way decrypts the message to pass it on. For true end-to-end encryption, where only the sender and recipient can read the content, you need a message-level scheme such as PGP or S/MIME on top of TLS.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← Back to glossary