RFC 8446: TLS 1.3 (obsoleted by RFC 9846 in 2026)

What this RFC defined

RFC 8446 defined TLS 1.3, the current version of the Transport Layer Security protocol. TLS 1.3 is faster than its predecessor (one fewer round-trip in the handshake), removes weak cipher suites that were exploitable in older versions, and improves forward secrecy guarantees. In July 2026 the IETF published RFC 9846, which obsoletes RFC 8446: it is a revised text of the same protocol, keeps the version number and stays backward compatible, and also sets new requirements for TLS 1.2 implementations.

Where you see it in practice

The encrypted connection between your email client and your mail server (the padlock in your email client’s connection settings) uses TLS, and modern deployments use TLS 1.3. SMTP over TLS on port 465, IMAP over TLS on port 993, and POP3 over TLS on port 995 all benefit from TLS 1.3’s improved performance. Servers that still only support TLS 1.0 or 1.1 are considered insecure under current security standards.

The TLS 1.3 protocol

RFC 8446 defined TLS 1.3 in August 2018 and represents the largest revision of TLS since version 1.0 in 1999. The handshake was completely redesigned: a full handshake takes one round trip (down from two in TLS 1.2), and a resumed session can send data with zero round trips (0-RTT). All weak cipher suites were removed: no RSA key exchange (mandatory forward secrecy via ECDHE or DHE), no CBC ciphers (mandatory AEAD), no SHA-1, no MD5. The signature algorithms were separated from the cipher suite, allowing cleaner future upgrades.

Handshake privacy

TLS 1.3 encrypts more of the handshake than TLS 1.2 did. Server certificates (which reveal the domain) are transmitted after the initial key exchange, protecting them from passive eavesdroppers. The Server Name Indication (SNI) is still cleartext in the basic protocol, but Encrypted Client Hello (ECH) extensions are being deployed to close that gap. For SMTP STARTTLS use, these improvements matter less (the domain is already visible in DNS), but for HTTPS they significantly reduce metadata leakage.

Deployment in email

Mail servers get TLS 1.3 from the TLS library they are built against: OpenSSL added it in version 1.1.1 (September 2018), so current Postfix, Exim and Dovecot builds negotiate it automatically. Windows is the main exception: Schannel only supports TLS 1.3 from Windows 11 and Windows Server 2022, so older Exchange hosts and classic Outlook on Windows 10 stay on TLS 1.2. The practical rule for 2026: disable TLS 1.0 and 1.1 (deprecated by RFC 8996), keep TLS 1.2 as the minimum, and let TLS 1.3 be negotiated whenever both sides support it.

How much email actually travels encrypted

Google publishes the share of Gmail traffic encrypted with TLS in transit in its Safer Email transparency report. When the report launched in June 2014, only about 69% of messages sent from Gmail to other providers and 48% of messages received from them were encrypted. By early 2025 the report showed around 98% outbound and 99% inbound. The remaining few percent are mostly small or old servers that still do not offer STARTTLS. These figures count any TLS version: they show that encryption on port 25 is now the norm, not which version is negotiated.

Ports, modes and the RFC behind each

How to check which TLS version a mail server negotiates

Force a TLS 1.3 handshake with OpenSSL. If the server does not support it, the command fails instead of falling back:

# Port 587 or 25 (STARTTLS)
openssl s_client -connect smtp.example.com:587 -starttls smtp -tls1_3

# Port 465 (implicit TLS)
openssl s_client -connect smtp.example.com:465 -tls1_3

On a successful run, look for Protocol : TLSv1.3 and the cipher in the output. For mail you have already received, the Received header added by the receiving server often records it; Gmail, for example, writes the negotiated version and cipher (such as version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384) next to each hop.

About the Author

Alaa · LinkedIn

Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.

About SMTPedia

SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.

We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.