On this page · 9 sections
Summary. On 17 August 2026 Cloudflare announced that Email Security negotiates the X25519MLKEM768 post-quantum hybrid key agreement on the SMTP connections it makes to receive and deliver mail. The changelog says support is "enabled automatically for all customers" and lists all 3 Email Security packages: Advantage, Enterprise, and Enterprise + PhishGuard. Cloudflare's own setup documentation, last updated 17 April 2026, says something narrower. Email Security has 2 deployment modes, and only pre-delivery MX/Inline makes Cloudflare "a hop in the SMTP processing chain". Post-delivery deployment through the Microsoft Graph API or through BCC and journaling never puts Cloudflare on an SMTP leg, so there is no connection for the new key agreement to protect. The provider Cloudflare names in the announcement, Google Workspace, is documented as "BCC and MX" in the same setup table. Two reference pages compound the gap: PQC in Cloudflare products, last updated 17 July 2026, has no Email Security entry, and the PQC support page, last updated 24 June 2026, lists 4 servers, all of them HTTP reverse proxies, and no mail transfer agent at all.
What Cloudflare shipped on 17 August 2026
The Email Security changelog entry and the matching changelog post carry the same text. Inbound MX connections and outbound delivery connections now negotiate X25519MLKEM768 when the peer supports it. Support is backwards compatible; senders and receivers that do not advertise post-quantum key agreement continue with classical key exchange.
The stated purpose is to defend SMTP traffic against harvest-now, decrypt-later attacks, where an adversary records encrypted traffic today and decrypts it once a cryptographically relevant quantum computer exists. Cloudflare's post-quantum cryptography overview sets its target at 2029 for full post-quantum security across the product suite, and notes one constraint that matters here: "Cloudflare post-quantum key agreements are only supported in protocols based on TLS 1.3."
The changelog title says "for MX deployments". The body says "for all customers". Those are not the same population.
The deployment mode decides whether you get anything
Cloudflare's Email Security setup page opens by asking you to choose one of two deployment paths, and publishes a table of what each provider supports.
| Provider | Documented deployment types | Does Cloudflare sit on an SMTP hop? |
|---|---|---|
| Microsoft 365 | API and MX | Only in MX/Inline |
| Google Workspace | BCC and MX | Only in MX/Inline |
| Others, on-prem or cloud | MX only | Yes |
| Microsoft Exchange, post-delivery | BCC | No |
| Microsoft 365, Graph API integration | API | No |
The MX/Inline deployment page is explicit about the mechanism: after you point MX records at Cloudflare, "Email security becomes a hop in the SMTP processing chain and physically interacts with incoming email messages."
Post-delivery deployment works the other way. Cloudflare scans messages after they reach the inbox, through Microsoft's Graph API or through BCC and journaling rules. The Email Security overview lists API, BCC/Journaling and MX/Inline as peers, but only one of the three involves Cloudflare receiving and delivering mail over SMTP. The setup page even sells post-delivery on that basis: it "is time-efficient, because it does not involve MX changes" and "does not disrupt mail flow".
So a Google Workspace tenant that took the BCC path, which is the faster path and the one Cloudflare recommends when you cannot touch DNS, is on an Email Security package the changelog names, is a customer the changelog covers, and gets no post-quantum SMTP protection from this change. Nothing in the changelog says so.
The reference pages cannot answer the question the changelog raises
The announcement's practical question is simple: will my mail peers actually negotiate X25519MLKEM768? Cloudflare publishes two pages for exactly this, and neither covers mail.
PQC in Cloudflare products describes itself as tracking "which Cloudflare products support post-quantum key agreement and post-quantum signatures". It groups products by secure communication channel: visitor to Cloudflare, Cloudflare internal network, Cloudflare to origin, Cloudflare Tunnel, and Cloudflare One. As of its 17 July 2026 modified date, the words email, SMTP and MX do not appear on it. Email Security has no row, no channel and no status marker, five weeks after the feature shipped.
PQC support, last updated 24 June 2026, lists third-party software support in three sections: Browsers, Libraries and Servers. Its Servers section names Caddy 2.10.0+, NGINX compiled with OpenSSL 3.5+, rpxy 0.9.4+ and Traefik 3.4.2+ or 2.11.26+. All four are HTTP reverse proxies. There is no Postfix, no Exim, no Microsoft Exchange, and no Google Workspace entry, even though Google Workspace is the single example the changelog gives.
| Reference page | Last modified | Answers "does my mail peer support PQ?" |
|---|---|---|
| PQC in Cloudflare products | 2026-07-17 | No Email Security entry |
| PQC support, Servers section | 2026-06-24 | 4 HTTP proxies, 0 mail servers |
| Email Security overview | 2026-04-17 | No mention of TLS versions |
| Email Security setup | 2026-04-17 | Deployment modes only |
| Partner domain TLS | 2026-04-17 | TLS required or not, no algorithms |
This is the same failure mode we documented in Cloudflare's leaked credentials Authorization header change, where the behaviour changed by default and the reference page describing the behaviour did not move.
You cannot require it, and you cannot see it
The one TLS control Email Security exposes for MX deployments is Partner domain TLS. It lets you name a domain and require TLS from it, and Cloudflare states that "if TLS is required, mail without TLS from the specified domain will be dropped". You add domains under Settings, Partner domain TLS, Add a domain, or enforce TLS across all mail during domain onboarding.
That control is binary. It has no field for a minimum TLS version, no key agreement selection, and no way to require post-quantum hybrid key agreement from a partner. The new behaviour is opportunistic by design: it applies "when the peer supports it", and otherwise falls back to classical key exchange silently.
Cloudflare also publishes no per-message or per-connection record of which key agreement was negotiated on the SMTP leg. For a web request you can check post-quantum negotiation from the client side; for inbound mail arriving at Cloudflare's MX from a third-party sender, the customer has no published field to inspect. The honest position for a 2026 crypto-agility register is that this change improves an unknown share of your inbound mail and you cannot yet measure which share.
The dependency chain also runs one level deeper than the announcement suggests. Because post-quantum key agreement requires TLS 1.3, any sender still negotiating opportunistic STARTTLS on TLS 1.2 gets classical key exchange regardless of what Cloudflare supports. Mail is one of the last large protocol families where TLS 1.2 and cleartext fallback remain common between organisations.
What to do this week
Check your deployment mode before you record anything in a compliance artefact. If your MX records do not point at Cloudflare, this change does not apply to your mail, whatever your package says.
If you run MX/Inline, note the change in your crypto-agility register with the date, 17 August 2026, the algorithm, X25519MLKEM768, and the scope, inbound MX and outbound delivery connections only. Do not record it as end-to-end coverage. Cloudflare's own products page states that "a Cloudflare-side entry only delivers end-to-end post-quantum protection when the party on the other side of the connection also supports the same post-quantum algorithms".
If you took the BCC or API path for speed, treat post-quantum SMTP as an open item, not a delivered control, and decide whether the MX cutover is now worth its cost. The MX/Inline page advises dropping DNS TTL to five minutes three to five days before the record change, so a migration is a week of planning rather than an afternoon.
Teams already tracking this class of risk will recognise the pattern from post-quantum cipher work and crypto agility. The Cloudflare One client side of the same estate has its own per-platform surprises, covered in our note on Cloudflare One Client 2026.7.1343.0.
India-specific considerations
Indian organisations reporting under the Digital Personal Data Protection Act 2023 are increasingly asked to describe the state of encryption in transit for personal data, and email is where that description tends to be weakest. A Cloudflare Email Security package name is not evidence of post-quantum protection for mail; the deployment mode is. Record the MX record change date and the DNS zone alongside the 17 August 2026 announcement, because an auditor reading the changelog alone would reasonably conclude that all Email Security customers are covered, and for BCC and API tenants that conclusion is wrong. Where mail crosses borders to a group parent or a processor, the TLS 1.3 requirement matters more than the algorithm: a partner still on TLS 1.2 removes post-quantum protection from that route entirely, no matter what Cloudflare negotiates elsewhere.
FAQ
How eCorpIT can help
Mapping which mail routes actually carry post-quantum key agreement is inventory work, not cryptography work, and it is where most crypto-agility registers go wrong. We trace deployment modes, MX ownership and TLS versions across an estate, then write the register entries an auditor can check. As an ISO 27001:2022 certified, CMMI Level 5 organisation, we design controls aligned with DPDP requirements rather than asserting compliance on your behalf. Our post-quantum crypto readiness assessment covers mail alongside web and origin connections, and you can book a readiness review to scope it.
References
Last updated 24 August 2026.
