Email providers lag in adopting post-quantum cryptography for message security
They Will See Johnny's Message: A Measurement Study of Post-Quantum Cryptography Across Email Delivery Paths
Cryptography and Security
Summary
Current email systems are vulnerable to attackers who can save messages now and decrypt them later with powerful computers. The authors examined how well post-quantum cryptography (PQC), a newer type of security designed to resist such attacks, is actually being used across popular email services. They found that less than half of the major email domains support PQC, and even fewer use it consistently during message transmission. Many systems fall back to unencrypted connections or face compatibility issues, limiting practical PQC usage in emails today.
What this means in practice
- •For email service operators: Identify and fix gaps in PQC support to upgrade secure email transmission across all delivery stages beyond just endpoint compatibility.
- •For security product developers: Integrate PQC functionality into email client and server software to handle key generation, negotiation, and compatibility more reliably for end users.
Authors
Jaehwan Park, Sunghyun Park, Kevin Nam, Doowon Kim
Abstract
Harvest-now, decrypt-later (HNDL) attacks make the transition to post-quantum cryptography (PQC) urgent for email. This paper presents a systematic measurement that jointly examines PQC deployment across email service stages, negotiation by communicating peers, and usable message encryption. Endpoint-level support alone does not establish PQC readiness across email workflows because submission, relay, and access use independently negotiated Transport Layer Security (TLS) connections. We therefore combine three snapshots of relay, submission, access, and webmail services associated with the Tranco Top~1M domains with controlled tests of mail clients, sending servers, and OpenPGP and S/MIME implementations. Our measurements reveal a transition concentrated among a few providers, with available capability not consistently translating into actual use. Fewer than half of the domains in each service panel support PQC, and Google alone accounts for approximately 87\% of hybrid-capable relay domains. Only two of eight tested sending providers negotiate PQC with our receiver, although five accept it inbound. When TLS groups are restricted to PQC, four of the six incompatible senders fall back to plaintext where unencrypted SMTP remains permitted. At the message layer, limited native key generation, key-format incompatibilities, and backend integration failures further constrain usable PQC encryption.