Current standard
What this RFC defines
RFC 9846 is the current specification of TLS 1.3, the encryption protocol behind STARTTLS on port 25 and 587, implicit TLS on port 465, and IMAP and POP3 over TLS. Published in July 2026 on the IETF Standards Track, it replaces RFC 8446 (2018). In its own words it is “a minor update to TLS 1.3 that retains the same version number and is backward compatible”. It also obsoletes the TLS 1.2 specification (RFC 5246) and RFCs 5077, 6961, 7627 and 8422, and updates RFCs 5705 and 6066.
Why it matters for mail servers
Nothing changes on the wire: a mail server that negotiated TLS 1.3 under RFC 8446 negotiates the same TLS 1.3 under RFC 9846, with the same version number and the same cipher suites. What changes is the reference to cite in documentation and compliance work, a handful of tightened requirements for TLS libraries, and an explicit ban on negotiating TLS 1.0 and 1.1.
RFC 9846 (July 2026, Proposed Standard) specifies TLS 1.3 and obsoletes RFC 8446. Same protocol and version number, backward compatible. Forbids negotiating TLS 1.0 and 1.1, forbids reusing key shares between connections, limits KeyUpdate messages, adds a general_error alert and renames “master” secrets to “main”. Mandatory cipher suite: TLS_AES_128_GCM_SHA256. Also obsoletes the TLS 1.2 document (RFC 5246) and sets new requirements for TLS 1.2 implementations.
RFC 9846 at a glance
| Aspect | Detail |
|---|---|
| Status | Proposed Standard (IETF Standards Track) |
| Published | July 2026 |
| Obsoletes | RFC 8446 (TLS 1.3), RFC 5246 (TLS 1.2), RFCs 5077, 6961, 7627, 8422 |
| Updates | RFC 5705, RFC 6066 |
| Protocol version | TLS 1.3, unchanged |
| Backward compatible | Yes, with RFC 8446 implementations |
| Handshake | 1-RTT full handshake, optional 0-RTT on resumption |
| Draft name | draft-ietf-tls-rfc8446bis |
What changed from RFC 8446
| Change | What it means in practice |
|---|---|
| TLS 1.0 and 1.1 may not be negotiated | Aligns TLS 1.3 implementations with RFC 8996, which deprecated both versions in 2021 |
| Key shares may not be reused between connections | Each connection uses fresh key exchange values |
| Key update before usage limits becomes a MUST, and KeyUpdate messages are capped | Long-lived connections must rotate keys in time; a peer cannot flood KeyUpdate |
| Clients that do not support resumption must ignore NewSessionTicket | Removes an interoperability grey zone |
| Clarified close_notify and user_canceled; new general_error alert | More predictable connection shutdown and error reporting |
| Key exchange described generically, not only (EC)DHE | Leaves room for KEM-based and post-quantum key exchange |
| “master” secrets renamed “main”; extended_master_secret becomes extended_main_secret | Terminology only, no wire change |
| Corrected length bounds on several messages | Fixes errors in the RFC 8446 syntax |
What it changes for TLS 1.2
Because RFC 9846 obsoletes RFC 5246, it is now the document that also governs some TLS 1.2 behavior. Section 1.4 lists changes that optionally affect TLS 1.2 implementations, including those that do not support TLS 1.3 at all:
- the version downgrade protection mechanism;
- RSASSA-PSS signature schemes;
- the
supported_versionsextension to negotiate the version; - the
signature_algorithms_certextension; - the rename of
extended_master_secrettoextended_main_secret.
TLS 1.2 is not deprecated: it remains widely used on port 25, and a mail server should keep accepting it.
Mandatory cipher suites and algorithms
| Item | Requirement in RFC 9846 (section 9.1) |
|---|---|
TLS_AES_128_GCM_SHA256 | MUST implement |
TLS_AES_256_GCM_SHA384 | SHOULD implement |
TLS_CHACHA20_POLY1305_SHA256 | SHOULD implement |
TLS_AES_128_CCM_SHA256, TLS_AES_128_CCM_8_SHA256 | Defined, optional |
| Signatures | MUST support rsa_pkcs1_sha256 (certificates), rsa_pss_rsae_sha256 and ecdsa_secp256r1_sha256 |
| Key exchange | MUST support secp256r1 (P-256), SHOULD support X25519 |
What to do on a mail server
To confirm what a server negotiates, force TLS 1.3 with OpenSSL; the command fails rather than falling back if the server does not support it:
openssl s_client -connect smtp.example.com:587 -starttls smtp -tls1_3
openssl s_client -connect smtp.example.com:465 -tls1_3See the RFC 8446 guide for the port-by-port table and common TLS mistakes on SMTP.
Common misconceptions
Related standards and further reading
Frequently asked questions
What is the difference between RFC 8446 and RFC 9846?
Both specify TLS 1.3. RFC 9846 (July 2026) is a revised text of RFC 8446 (2018): same version number, backward compatible, with tightened requirements (no TLS 1.0 or 1.1 negotiation, no key share reuse, capped KeyUpdate), clarifications, errata fixes and updated terminology.
Do I need to change my mail server configuration?
Usually not. If TLS 1.0 and 1.1 are already disabled and TLS 1.2 and 1.3 are enabled, you are aligned. The other changes are handled by your TLS library when you update it.
Is RFC 8446 still valid?
RFC 8446 is obsolete since July 2026, but software built against it keeps working because the protocol did not change. New documentation, audits and compliance references should cite RFC 9846.
Does RFC 9846 add post-quantum encryption?
Not directly. It describes key exchange in more generic terms so that KEM-based mechanisms, the family that post-quantum key exchange uses, fit the specification. The post-quantum algorithms themselves are defined in separate documents.
Did this guide save you time?
SMTPedia is free and independent. A coffee helps keep every guide accurate.
Buy SMTPedia a coffeeAbout 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.