NCSC updates TLS guidance for mail servers and quantum threats
News
The UK National Cyber Security Centre (NCSC) published post-quantum TLS recommendations on October 15, 2026, alongside version 1.2 of its TLS guidance. The update recommends hybrid and pure post-quantum key establishment for TLS 1.3, with specific instructions for mail servers. Administrators should prepare upgrades while preserving SMTP interoperability.
For mail administrators and managed service providers (MSPs), the immediate concern is operational: an incompatible TLS configuration can lead to unencrypted delivery or delivery failure. I treat this release as a reason to review what mail connections actually negotiate, then stage changes against real traffic. Enabling TLS 1.3 alone does not make a connection post-quantum.
What changed in the October 15 release
The revised TLS guidance, published and reviewed October 15 as version 1.2, follows RFC 10024 for post-quantum/traditional hybrid key agreement in TLS 1.3. Its recommended hybrid profile uses X25519MLKEM768 or SecP256r1MLKEM768. Its pure post-quantum profile uses MLKEM768. The announcement explicitly says the final pure PQC RFC is still awaiting publication, although stable implementations are available.
TLS 1.3 is the version supporting PQC, but both endpoints need compatible implementations and configured key establishment algorithms. A TLS 1.3 session negotiating only a traditional group remains classical. TLS 1.2 still provides strong protection against classical attacks under the recommended profiles; administrators need a migration plan because it will not gain PQC support.
2031 is an existing prioritization goal
The NCSC announcement reiterates 2031 for high-priority migration activities. It does not announce a universal SMTP or domain-owner deadline, or a Gmail, Yahoo, or Microsoft bulk-sender enforcement date.
Keep SMTP interoperability while adopting TLS 1.3
The updated mail server guidance distinguishes server-to-server transport from end-user connections. For SMTP STARTTLS on port 25, it recommends the TLS 1.3 and TLS 1.2 profiles, plus the TLS 1.2 compatibility profile. The goal is to avoid negotiation failures that result in unencrypted delivery.
I keep port 25 STARTTLS available and preserve the recommended compatibility options while testing PQC support. Making every MX TLS 1.3-only overnight risks disrupting delivery with peers that still need TLS 1.2. An inbound MX and an outbound relay also have different roles, so their configuration and test results need separate review.
|
|
|
|---|---|---|
MTA to MTA | 25 | STARTTLS |
IMAP access | 993 | Implicit TLS |
POP access | 995 | Implicit TLS |
SMTP submission | 465 | Implicit TLS |
Separate internet mail transport from end-user access and submission.
For end-user IMAP, POP, and SMTP submission, the guidance prefers implicit TLS, where encryption starts immediately after connection establishment. Its example is IMAPS on port 993 rather than IMAP on port 143 with STARTTLS. That recommendation does not remove STARTTLS from inter-MTA SMTP on port 25.
My acceptance check includes successful encrypted delivery in both directions. A server that advertises TLS support still needs evidence that its real correspondents negotiate it successfully. Review handshake errors alongside queue delays and any retries that deliver without encryption.
Key establishment and certificate authentication are separate
The post-quantum recommendations target key establishment and confidentiality. They do not make the entire TLS authentication chain quantum resistant. The NCSC announcement says post-quantum authentication recommendations will follow in a future update; the current profiles still use traditional certificate authentication.
I keep those two workstreams separate in upgrade plans. Changing a supported key exchange group does not replace certificate signatures or a certificate authority chain. Likewise, an ordinary certificate renewal does not enable post-quantum key establishment. Both sides must support and negotiate the intended group.
Hybrid key establishment
Combines traditional elliptic curve cryptography with ML-KEM. X25519MLKEM768 is a concrete recommended choice when the implementation and peer support it. Hybrid options have wider deployment in common libraries, according to the NCSC.
Pure post-quantum key establishment
Uses ML-KEM without a traditional key establishment component. MLKEM768 is the recommended profile choice. NCSC accepts it for use, while the final pure PQC TLS RFC remains pending.
Stage MTA-STS and TLS-RPT before enforcement
The update also recommends existing mail transport protections: MTA-STS and SMTP TLS Reporting (TLS-RPT). MTA-STS lets a receiving domain publish requirements for supporting senders to use TLS. TLS-RPT provides aggregate reports about delivery and policy failures. Neither standard supplies post-quantum encryption or selects a post-quantum group.
Start MTA-STS in testing mode before enforce mode, as the NCSC recommends. For a domain whose only MX is mail.example.com, this illustrative policy records the intended host without requesting enforcement. It is a policy file, not a DNS TXT record.
Illustrative MTA-STS testing policytext
version: STSv1 mode: testing mx: mail.example.com max_age: 86400
Before enforcement, verify every listed MX hostname and its certificate. An enforcing MTA checks that the certificate matches the relevant MX hostname and chains to a CA the sender trusts. Missing certificate names or an untrusted chain turn a seemingly routine policy change into a delivery problem.
Testing mode exposes problems without requiring senders to block delivery for policy failures. I review TLS-RPT alongside server logs before switching to enforce. Reports are useful for diagnosis, but they do not prove every message used a post-quantum group; that requires connection-level evidence from the TLS implementation.
What mail administrators and MSPs should check now
The useful next step is a scoped inventory, followed by representative delivery tests. For an MSP, I record these checks per client and per endpoint role. A shared gateway upgrade can affect several domains, while an individual client application can still depend on an older configuration.
- Inventory endpoints. Record inbound MX, outbound relays, submission, and mailbox access, including the TLS library version, active profile, and configuration owner.
- Verify negotiation. Check supported classical and hybrid groups, then inspect actual negotiated versions and groups. Installed capability alone does not establish protection.
- Test both directions. Send representative inbound and outbound messages, including through secondary MX hosts and gateways. Record handshake failures, retries, and plaintext fallback.
- Stage changes. Pilot library upgrades and certificate or policy changes. Keep a rollback configuration and confirm encrypted delivery before expanding the rollout.
- Monitor delivery. Review TLS-RPT failures and mail queues together. Assign owners to certificate problems and incompatible peers rather than treating every failure as a PQC issue.
An external inbound check cannot establish how an outbound relay sends mail. For that, generate outbound traffic and inspect the receiving side or the relay telemetry. I also include infrequent correspondents in the observation period, because a short successful pilot does not cover every peer.
Ask the mail host which library and software release support the intended key establishment groups, how those groups are configured, and where negotiation results are visible. A generic statement that TLS 1.3 is enabled leaves the central PQC question unanswered.
For hosted mail, request a sample negotiated connection and a documented upgrade path. Agree on what happens if a peer cannot negotiate the preferred group, and identify who investigates that event. Those details give the change request a concrete acceptance test. They also make clear which controls the domain owner manages and which require action by the hosting provider.
Where Suped fits in the rollout
Suped is our email authentication platform. Our Hosted MTA-STS workflow manages the policy and collects TLS-RPT reports, so administrators can stage testing and enforcement while investigating reported failures. It does not upgrade the mail server TLS library or turn a classical connection into a post-quantum connection.
Use our MTA-STS checker to review DNS discovery, the HTTPS policy file, MX coverage, certificates, and SMTP TLS support before changing enforcement. Pair those checks with live delivery tests and server-side negotiation logs.
Hosted MTA-STS/TLS-RPT configuration dialog showing policy mode, MX hosts, CNAME records, TLS reporting, and verification
The practical workflow is to verify the current policy, stage changes, investigate TLS-RPT failures, and move to enforcement after delivery checks pass. Keep transport policy evidence separate from the evidence showing which key establishment group each tested connection negotiated.
Give each mail service an upgrade owner
Assign an owner and a tested upgrade path to each mail service now. Prioritize systems carrying information that needs long-term confidentiality, and document dependencies on TLS 1.2 or traditional TLS 1.3 groups. Use that inventory to schedule library and hosting changes against the existing NCSC migration priorities.
For each rollout, require evidence of encrypted delivery and the intended negotiated algorithms. Keep certificate validation and queue monitoring in the release checks, so stronger transport settings reach production without an unnoticed loss of mail.
Frequently asked questions
No. Both endpoints need compatible implementations and must negotiate a post-quantum or hybrid key establishment group. TLS 1.3 alone does not prove that happened.
No. The mail guidance retains recommended TLS 1.2 and compatibility profiles for inter-MTA delivery. Plan migration while testing real peers and monitoring unencrypted fallback.
No. MTA-STS requests TLS and certificate validation from supporting senders. The negotiated TLS algorithms determine post-quantum key establishment; TLS-RPT helps diagnose transport failures.
No. It is an existing NCSC goal for high-priority migration activities. The October 15 announcement introduces no universal SMTP deadline or mailbox-provider sender enforcement date.
