What this RFC defines
RFC 8446 defines 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.
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.
How it connects to other RFCs
RFC 8446 obsoletes RFC 5246 (TLS 1.2) and RFC 4346 (TLS 1.1). RFC 3207 (STARTTLS for SMTP) and RFC 8314 (TLS for email submission) specify how TLS is applied to email protocols; RFC 8446 defines the TLS protocol itself that these email RFCs rely on.
Current status
RFC 8446 is the current TLS standard, published August 2018. TLS 1.3 is supported by all major mail servers and clients. TLS 1.0 and 1.1 have been deprecated; TLS 1.2 is still in wide use but TLS 1.3 should be preferred for new deployments.
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: only two round trips (down from three in TLS 1.2), or one round trip with 0-RTT resumption. 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
Every major mail server supports TLS 1.3 in 2026. Adoption for SMTP STARTTLS was faster than expected because MTAs benefit from lower CPU overhead. Google reports over 90% of SMTP TLS handshakes to Gmail use TLS 1.3. On the client side (IMAP, POP3, submission), TLS 1.3 support is universal in modern clients. Older clients running Windows 7, macOS below 10.13, or Android below 10 may fall back to TLS 1.2. Servers should support both versions with TLS 1.0 and 1.1 disabled.
RFC 8446 (August 2018) defines TLS 1.3: the current version of the Transport Layer Security protocol. Major improvements over TLS 1.2: simplified handshake (1-RTT default, 0-RTT for resumed sessions), removal of legacy insecure cryptography (RC4, 3DES, MD5, SHA-1, RSA key exchange without forward secrecy), forward secrecy mandatory (all cipher suites use ECDHE or DHE). Used for SMTP (via STARTTLS or implicit TLS per RFC 8314), IMAP, POP3, and web/HTTP protocols. Obsoletes TLS 1.2 as the recommended version.
RFC 8446 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Current TLS version for encrypted transport (SMTP, HTTP, IMAP, POP3, and others) |
| Key improvement | 1-RTT handshake (vs 2-RTT in TLS 1.2) |
| Forward secrecy | Mandatory in all cipher suites |
| Cipher suites | 5 suites total (down from ~40 in TLS 1.2); simplified negotiation |
| Removed weak crypto | RC4, 3DES, MD5, SHA-1, static RSA key exchange, CBC ciphers with MAC-then-encrypt |
| Downgrade protection | Cryptographic signaling prevents version downgrade attacks |
| Published | August 2018 |
Concrete changes from TLS 1.2 to TLS 1.3
| Aspect | TLS 1.2 | TLS 1.3 | Impact |
|---|---|---|---|
| Handshake round trips | 2-RTT full, 1-RTT resumed | 1-RTT full, 0-RTT resumed | Faster connection setup |
| Cipher suite count | Approximately 40 negotiated | 5 total suites | Simpler configuration; harder to misconfigure |
| Key exchange | RSA, DHE, ECDHE (choice) | ECDHE, DHE only (forward secrecy required) | All connections forward-secret |
| Static RSA | Supported (no forward secrecy) | Removed | Cannot decrypt captured traffic with stolen key |
| Cipher modes | CBC, GCM, ChaCha20 | AEAD only (GCM, ChaCha20-Poly1305, CCM) | Removes CBC padding oracle attacks |
| Hash algorithms | MD5, SHA-1, SHA-256, and others | SHA-256, SHA-384 only | Removes broken hashes |
| 0-RTT data | Not supported | Optional (with replay attack risk) | Faster resumed connections but requires care |
| Downgrade protection | Not cryptographic | Cryptographic in ServerHello Random | Prevents attacker forcing TLS 1.2 |
The five TLS 1.3 cipher suites
| Cipher Suite | AEAD | Hash | Notes |
|---|---|---|---|
TLS_AES_256_GCM_SHA384 | AES-256-GCM | SHA-384 | Recommended for high-security |
TLS_CHACHA20_POLY1305_SHA256 | ChaCha20-Poly1305 | SHA-256 | Recommended for mobile (fast on ARM without AES-NI) |
TLS_AES_128_GCM_SHA256 | AES-128-GCM | SHA-256 | Default; good balance |
TLS_AES_128_CCM_8_SHA256 | AES-128-CCM-8 | SHA-256 | Constrained devices (IoT); shorter authentication tag |
TLS_AES_128_CCM_SHA256 | AES-128-CCM | SHA-256 | Constrained devices; full-length tag |
Common TLS 1.3 deployment mistakes for SMTP
smtpd_tls_protocols = >=TLSv1.2).Related standards and further reading
- SSL/TLS Email Setup Guide: practical TLS configuration
- Email Protocols and Ports Guide: TLS ports overview
- 550 Must Issue STARTTLS Error: common TLS-related failure
Frequently asked questions
Should I require TLS 1.3 for SMTP in 2026?
For client submission (port 465/587), yes if your user base runs modern clients (Outlook 365, Thunderbird recent versions, mobile apps). For server-to-server relay (port 25), no: many peer MTAs still use TLS 1.2 exclusively, and requiring 1.3 breaks delivery. Modern deployments: support both 1.2 and 1.3 on port 25, prefer 1.3 when negotiated. Disable 1.0 and 1.1 in both cases.
Is 0-RTT data safe to enable for SMTP?
No, generally not. RFC 8446 section 8 explicitly notes 0-RTT is subject to replay: an attacker capturing the initial encrypted data can replay it. For SMTP, replay of an authenticated MAIL FROM / RCPT TO / DATA sequence could re-send an email. Disable 0-RTT for authenticated SMTP submission. It is safer for idempotent public HTTP GET requests, which is where TLS 1.3 0-RTT is primarily useful.
What is the difference between TLS 1.3 and STARTTLS?
Different layers. TLS 1.3 is a version of the TLS protocol itself (defines cipher suites, handshake, key derivation). STARTTLS is an SMTP mechanism for upgrading a cleartext connection to TLS mid-session. STARTTLS negotiates whatever TLS version both sides support; that could be 1.2 or 1.3. So “SMTP over TLS 1.3 via STARTTLS” is the modern combination: STARTTLS as the upgrade mechanism, TLS 1.3 as the negotiated version.
Which cipher suites should I enable for SMTP TLS?
For TLS 1.3: enable AES-256-GCM (high security), AES-128-GCM (default), and ChaCha20-Poly1305 (mobile). For TLS 1.2 fallback: enable ECDHE-RSA-AES256-GCM-SHA384, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-CHACHA20-POLY1305. Disable RC4, 3DES, and any suite without forward secrecy. Modern MTA defaults are usually reasonable; verify with SSL Labs SMTP test.
Does TLS 1.3 prevent MITM attacks?
Yes, if certificate validation is enforced. TLS 1.3 provides confidentiality, integrity, and authentication of the server. Adding client authentication (mutual TLS) prevents server-side impersonation of clients. However, TLS 1.3 alone does not prevent downgrade to cleartext if the upgrade mechanism (STARTTLS) is stripped by an attacker; hardening layers (MTA-STS, DANE, RFC 8314 for submission) close this gap.
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.
