arXiv CS open access

They Will See Johnny's Message: A Measurement Study of Post-Quantum Cryptography Across Email Delivery Paths

Jaehwan Park et al. · arxiv_cs

arXiv CS · Papers

cryptography cybersecurity privacy security

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. Endpoin

Conceptio Open Archive

Analyze & explore related research in Conceptio

Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.

Explore in Search →Connect via MCP / API ↗

They Will See Johnny’s Message: A Measurement Study of Post-Quantum Cryptography Across Email Delivery Paths

arXiv:2610.36145v1 [cs.CR] 26 Oct 2026

Jaehwan Park

bags3366@khu.ac.kr KyungHee University Suwoon, South Korea

Kevin Nam∗

Doowon Kim∗

kvnam@khu.ac.kr KyungHee University Suwoon, South Korea

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.

CCS Concepts • Networks → Application layer protocols; Network measurement; • Security and privacy → Security protocols.

Keywords Email security, Internet measurement, Post-quantum cryptography

Introduction

Email remains a widely used communication channel [51] carrying sensitive personal and organizational information [13]. Transport Layer Security (TLS) was added to the original protocols and now provides the primary protection for email in transit [17, 34, 44]. Quantum computing threatens this protection. A cryptographically relevant quantum computer (CRQC) could break traditional TLS key establishment, including RSA and (EC)DHE, and recover the session keys protecting email [3, 49]. The National Institute of Standards ∗ Corresponding authors.

Sunghyun Park

jpark127@utk.edu University of Tennessee Knoxville, USA

doowon@utk.edu University of Tennessee Knoxville, USA and Technology (NIST) standardized ML-KEM to support quantumresistant key establishment [38]. Migration to post-quantum cryptography (PQC) is already urgent because harvest-now, decrypt-later (HNDL) attacks allow adversaries to record encrypted traffic today for future decryption [5, 9, 50]. Email is particularly exposed because correspondence can remain sensitive for years and cross the public Internet between organizations, where an on-path adversary can collect it. Archived messages could later reveal sensitive information, including political affiliations, when their authors can no longer protect the captured data. Protecting email against HNDL requires more than securing an individual TLS connection. Email uses independently negotiated connections for submission, server-to-server relay, and mailbox access through IMAP or POP3 (Figure 1). Webmail instead uses HTTPS for client-facing submission and access. PQC on one connection cannot protect a copy captured on another connection that uses traditional TLS key establishment. Message encryption can also protect content independently of transport, but only when implementations provide usable post-quantum encryption. However, message-level encryption remains rare. Only 5.46% of measured users have ever used S/MIME or PGP, and 0.06% of emails were encrypted [52]. Thus, transport-level PQC is the primary defense against HNDL for most users, and we treat message-level PQC as a complement. Prior email research examines classical transport security, delivery dependencies, and message encryption [13, 19, 20, 28, 36, 60]. Wickramasinghe et al. characterize PQC support in Web-facing TLS [61]. Loizou and Ghadafi compare HTTPS and the highestpriority SMTP MX hosts of 4,665 U.K. organizations [32]. Neither line jointly examines PQC availability across email services, negotiation by initiating peers, and usable message-level protection. This paper targets filling this gap by measuring to what extent the email ecosystem is prepared for HNDL attacks, and where are the gaps? Specifically, we answer the following questions: • RQ1 (Server-side TLS): How widely do email servers support PQC across submission, relay, access, and webmail, and how does support compare by provider? • RQ2 (Client-side TLS): Do mail clients and outbound MTAs offer and negotiate PQC when receiving servers support it? • RQ3 (Message-level encryption): Can OpenPGP and S/MIME implementations provide usable PQC message encryption independently of transport support?

Conference’17, July 2017, Washington, DC, USA

Park et al.

Message-level (OpenPGP and S/MIME)

Receiver

Transport-level

Dedicated email client

Webmail Client

SMTP(S)

MSA/MTA

HTTP(S)

Webmail server

SMTP(S)

filtering service

IMAP(S) POP3(S)

MTA/MDA Webmail server

HTTP(S)

Dedicated email client

Webmail Client

Figure 1: Email delivery and measurement scope. The message layer protects content across transport connections. The transport layer comprises submission (❶), webmail (❷), relay (❸), and retrieval (❹). and mark the TLS server and client sides. Solid arrows show measured connections. Dashed arrows show provider-internal connections that are not measured. To answer these questions, we combine server-side ( ) measurements with client-side ( ) tests across the email stages in Figure 1. For RQ1, we discover the MX, submission, access, and webmail servers associated with the Tranco Top 1M domains and test hybrid and pure ML-KEM capability through three snapshots over four weeks. For RQ2, we capture the TLS handshakes of three widely used mail clients (Apple Mail, Gmail, and Outlook) across platforms at stages 1 , 2 , and 4 . At stage 3 , we operate a controlled MX receiving mail from eight providers under two TLS configurations, one accepting all tested groups and one accepting only PQC groups. For RQ3, we evaluate 27 client and platform configurations, including 24 supporting OpenPGP and 17 supporting S/MIME, using a structured corpus of 19 OpenPGP keys and six S/MIME certificates. Our main findings are as follows: • (RQ1) Observed PQC deployment is dominated by Google rather than broadly distributed across providers. In the final snapshot, hybrid support reaches 33.1% for explicit-MX relay, 40.2% for submission, 40.2% to 46.8% for access, and 41.0% for webmail within their respective stable panels. Google accounts for approximately 87% of hybrid-capable relay domains and 96% to 97% of PQC-capable submission and access domains. Microsoft shows no PQC support at its measured endpoints, including those serving nist.gov, while Proton accepts none at its measured inbound MX endpoints. Support also differs across the infrastructure associated with a domain. Filtering gateways (e.g., Proofpoint and Mimecast) remain traditional-only even in front of PQC-capable mailbox providers, and 417 domains pair a PQC-capable primary MX with a non-PQC backup. Mailbox-provider capability therefore does not establish consistent support across the services and relay alternatives. • (RQ2) Receiving capability does not ensure PQC use. Only two of eight tested sending providers negotiate PQC with our receiver, while Google, Yahoo, and Mailgun accept it inbound but do not offer it in our outbound tests. Client behavior also varies by platform. Apple Mail on macOS and Outlook on Windows use TLS 1.2, while Outlook on macOS advertises PQC without negotiating it in the observed connections. When our receiver restricts TLS groups to PQC but still accepts unencrypted SMTP, four of the six incompatible senders deliver in plaintext. Software experiments identify

further barriers. Postfix advertises a hybrid group but initially supplies only a classical share, which the tested receiver selects. Both Exim and Postfix built without ML-KEM deliver in plaintext to the tested PQC-restricted receiver under opportunistic delivery policies. These results distinguish enabling PQC capability from ensuring its use during negotiation and delivery. • (RQ3) Message-level encryption offers only limited complement for lack of PQC-TLS. None of the 27 client configurations we examine generates a post-quantum key natively. Thus, users must create keys with external tools and import them, which raises the barrier to adoption. Whether an imported key is accepted is decided by the cryptographic backend rather than the client, so users who want to mitigate HNDL attacks must choose a client by its backend. Even a successful import does not guarantee a usable key. Only three keys, the v6 keys with a traditional primary key, complete message exchange in both GnuPG- and PGPony-based configurations. For S/MIME, although four certificate stores import ML-KEM certificates, only two encrypt to them. Contributions. To our knowledge, this is the first study to combine Internet-scale measurements of server-side post-quantum keyexchange support across relay, submission, access, and webmail services with controlled experiments on client-side negotiation and message-level encryption. Specifically, we present: • A systematic measurement methodology combining server capability across email service roles, negotiation by communicating peers, and message-level interoperability, together with a threesnapshot characterization of deployment. • A structured corpus of 19 OpenPGP keys and six S/MIME certificates for testing algorithm and format compatibility through matched comparisons and explicit negative controls. • An analysis of operational barriers spanning negotiation defaults, delivery policies, and application integration, including a reported Exim defect and a GnuPG packet-encoding flaw for which correcting the output restores decryption.

2 Background and Related Work 2.1 Email Delivery Path Figure 1 shows the service roles involved in email delivery. We call each role a stage and an individual transport connection a hop. In

They Will See Johnny’s Message: A Measurement Study of Post-Quantum Cryptography Across Email Delivery Paths

submission ( 1 ), the mail user agent (MUA) of the sender transmits a message to a mail submission agent (MSA) [16]. In relay ( 3 ), the sending mail transfer agent (MTA) locates the receiving MTA through the MX records of the recipient domain and forwards the message over SMTP [22]. A domain can list multiple MX hosts, including backup hosts used when a preferred host is unavailable. A cloud filtering service can also receive mail before forwarding it to the mailbox provider [28, 43]. In retrieval ( 4 ), the recipient accesses the mailbox through IMAP or POP3 [8, 37]. Alternatively, webmail ( 2 ) uses HTTP(S) between a browser and a webmail server, which performs submission and retrieval on behalf of the user [14]. Table 5 in Appendix A lists the protocols and ports. These services can be operated by different providers and need not share a security policy [20, 31]. For TLS, the connection initiator is the client ( ), even when it is an outbound MTA. The accepting endpoint is the server ( ). This distinction motivates measuring server-side support and client-side negotiation separately.

2.2

Confidentiality at Two Layers

Transport level. TLS protects individual connections between adjacent parties. Explicit TLS upgrades a plaintext connection through STARTTLS, whereas implicit TLS begins when the connection is established [17, 34, 39]. Protection terminates at each participating server, which processes the message before forwarding or storing it. Because this is inherent to the email protocols rather than to TLS, we do not consider it in our HNDL threat model; message-level encryption, however, can protect the message content even at these servers. On opportunistic SMTP relay, a sending MTA may retry without TLS after negotiation fails [13, 42]. MTA-STS and DANE provide mechanisms for requiring authenticated TLS, but do not specify a required PQC key-exchange group [12, 33]. Message level. OpenPGP and S/MIME protect message content independently of the transport path [48, 62]. The sender encrypts the content with a fresh symmetric key and protects that key using the public key of the recipient. In OpenPGP, the primary key binds user identities and subkeys through signatures, while encryption typically uses a dedicated subkey. Key versions define packet and fingerprint formats: v4/v6 in OpenPGP [62] and v5 in LibrePGP [23]. S/MIME uses X.509 certificates to bind users’ identities to their public keys through an issuer’s signature [48]. Message-level PQC can therefore protect content even when a transport connection lacks post-quantum key establishment. This protection requires a working sequence of key generation or import, encryption, and decryption in the participating applications. Our evaluation concerns message content rather than the confidentiality of routing information and metadata.

2.3

Post-Quantum Key Exchange in TLS

In TLS 1.3, the client advertises supported key-exchange groups in supported_groups and provides shares in key_share [44]. The server selects a group with a share, or requests a share for another group in supported_groups through HelloRetryRequest, which adds a round trip. Advertising a group therefore differs from supplying its initial share, and neither alone establishes that the group is negotiated. We distinguish capability (a server accepts a PQC key exchange) from negotiation (a PQC group is selected

Conference’17, July 2017, Washington, DC, USA

Table 1: Scope of representative prior work. : coverage, G # : partial coverage, # : no coverage. Large-scale denotes a Top 1M domain population or larger, or an IPv4-wide scan.

Prior Work Wickramasinghe et al. [61] Durumeric et al. [13] Holz et al. [19] Blechschmidt and Stock [6] Poddebniak et al. [42] Loizou and Ghadafi [32]

Multi. MUA- Send.- Msg.About About Largeemail side MTA level email? PQC? scale hops TLS TLS enc. #

Our work

# # # #

# G

# # # G # # G #

# G # #

# # # # #

in an observed handshake). Following RFC 9794, we distinguish traditional, hybrid, and pure groups [11]. NIST standardized ML-KEM for post-quantum key establishment in 2024 [38]. Hybrid groups such as X25519MLKEM768 combine a traditional elliptic-curve exchange with ML-KEM [25]. Pure groups use ML-KEM alone and are specified separately in an Internet-Draft [7]. The evaluated PQC groups use TLS 1.3. A TLS 1.2 connection does not negotiate these groups [10]. Our focus is key establishment and content confidentiality rather than post-quantum authentication. HNDL threat and measurement scope. In a harvest-now, decryptlater (HNDL) attack, an adversary records encrypted traffic today for possible decryption using a future cryptographically relevant quantum computer [5, 9, 50]. Protecting long-lived sensitive data can require migration before such a computer becomes available [35]. Recording opportunities span client-facing and interprovider connections, with prior work documenting passive observation of email traffic and STARTTLS interference [13, 18, 19].

2.4

Related Work

Table 1 compares the scope of our study with prior work. Post-quantum TLS. Wickramasinghe et al. [61] measure PQC support in Web-facing TLS. Loizou and Ghadafi [32] examine HTTPS and the highest-priority SMTP MX hosts of 4,665 U.K. organizations. Neither study jointly covers PQC across email service roles, initiating clients, and message encryption. Classical email security. Prior work measures email TLS deployment and client behavior [13, 15, 19]. Other studies examine STARTTLS, auto-detection, confidentiality mechanisms, and dependencies involving intermediaries and webmail [6, 20, 28, 29, 42, 53]. These studies reveal fragmented email security but do not assess PQC deployment. Message-level encryption. Prior OpenPGP and S/MIME studies examine usability and implementation security [36, 60]. We evaluate PQC key generation, import, and successful message exchange, complementing our measurements of server availability and negotiated use to identify deployment gaps across email.

Study Overview

Overview and scope. Our study combines two kinds of evidence that answer different questions (Figure 1). For RQ1, we scan the submission, relay, access, and webmail endpoints associated with the Tranco Top 1M domains across three snapshots. This scan yields

Conference’17, July 2017, Washington, DC, USA

Park et al.

population-level capability rates over the endpoints we discover (§4), so endpoints that our discovery misses are not represented. For RQ2 and RQ3, we conduct controlled experiments with mail clients, outbound MTAs, MTA software, and OpenPGP and S/MIME implementations. These experiments yield case-level observations that explain whether and why capability translates into negotiated or usable protection (§5, §6). The observations apply to the tested applications, platforms, providers, and configurations, and they do not estimate how often PQC is used across email traffic. Two further limits apply to both kinds of evidence. First, a PQCcapable server does not imply that PQC is used on connections to it, and our external vantage point does not observe providerinternal hops. Second, we do not consider post-quantum certificates because HNDL threatens only confidentiality: recorded traffic can be decrypted retroactively, whereas signatures cannot be forged retroactively [50]. Ethical Considerations. We follow the principles of the Menlo Report [2]. Endpoints are deduplicated across domains and probed in randomized order, with at most five short-lived connections per endpoint per snapshot, each retried at most three times only after a timeout. Public TLS capability probes stop after the handshake without authentication or email transmission. We collect handshake metadata, certificates, and protocol banners. HTTP requests identify the study through a User-Agent string linking to a project page with an opt-out option. Controlled delivery experiments use only accounts and receiving servers under our control and do not capture unrelated traffic.

and seven other languages (e.g., Chinese, French). We classify a page as webmail if it scores at least 10, or at least 7 and contains a fingerprint of webmail software (e.g., Roundcube, OWA). TLS handshake probes. Our OpenSSL 3.5.5 scanner [40] probes each endpoint using the TLS mode listed in Table 5 with a 7-second timeout and up to three retries per probe. After confirming TCP reachability, we test four handshake probes in sequence: mixed, traditional-only, hybrid-only, and pure ML-KEM-only. The mixed offer contains all groups in Table 8 (Appendix §C), ordered traditional, hybrid, pure. The traditional-only probe accounts for possible incompatibility with the mixed offer. A successful mixed or traditional-only handshake establishes TLS support, while a hybridonly or ML-KEM-only handshake establishes PQC capability. Provider attribution. Following Liu et al. [31], we infer operators from TLS certificates (98% of cases), protocol banners or greetings, and hostnames, in that order. We group operators into cloud mail providers, hosting providers, and filtering services [43]. Endpoints with certificates naming the domain itself are classified as selfhosted under this heuristic. Support criteria and stable panels. For each stage, we retain domains with successful TLS in all three snapshots, forming a fixed panel for temporal comparisons [61]. A domain is PQC-capable at a stage if at least one discovered endpoint accepts an evaluated PQC group. The resulting rates measure available capability, not uniform support across every alternative endpoint. Each stage uses its own panel as the denominator, so percentages across stages do not describe the same domain population.

4 RQ1: Server-Side PQC Deployment 4.1 Measurement Method

4.2

Domain selection and relay discovery. We use the Tranco Top 1M snapshot of July 26, 2026 [41], following the domain-based approach of prior email measurements [13]. Using ZDNS v2.1.1 [21] with a 5-second timeout and up to three retries per query, we resolve MX records and the A and AAAA records supplying IPv4 and IPv6 addresses. We exclude Null MX domains [27]. Domains with MX records form the explicit-MX set; otherwise, we use their A/AAAA addresses as implicit delivery targets [22]. Domains without a delivery target are excluded. We probe all returned addresses of each delivery target, including MX hosts at every preference tier. An endpoint is identified by hostname, IP address, port, and TLS mode. Table 6 of Appendix §B summarizes the resolution outcomes. Submission and access discovery. We retrieve submission and access endpoints from Autoconfig, Autodiscover, DNS SRV records, and the Thunderbird ISPDB [4, 59]. We do not guess hostnames for these services because a matching hostname alone does not establish an association with the domain (see Table 7 of Appendix §B). Webmail discovery. Following Li et al. [29], we request each domain’s mail. and webmail. [57] subdomains and follow HTTP(S) redirects to the final page. If the redirects lead to a known provider login host (e.g., accounts.google.com), we attribute the domain to that provider’s webmail and evaluate TLS support at the provider’s host (e.g., mail.google.com) rather than at the login host. This rule accommodates script-rendered login pages with few indicators. For other pages, we compute a score based on 16 webmail terms and four login-form elements (20 points), matching terms in English

PQC Adoption per Stage

At every stage, more than half of the domains lack PQC support (Table 2), leaving them vulnerable to HNDL attacks. Their connections use traditional key exchange regardless of the client’s offer, so traffic recorded today becomes decryptable once a CRQC exists. Among these domains, 86–94% on the mail hops (78% on webmail) already negotiate TLS 1.3, and the rest use only TLS 1.2. This suggests that the lack of PQC is mostly not a matter of the TLS version, but that these servers have not enabled a hybrid group. The domains limited to TLS 1.2 cannot negotiate PQC at all and should adopt TLS 1.3 to defend against HNDL attacks. Since every domain supporting pure ML-KEM also supports hybrid exchange at the same stage, hybrid support alone determines the protected population. Yet one domain’s support is not enough. Even a domain that supports PQC at every stage remains exposed to HNDL when it sends mail to a domain that does not, so protection requires both the sending and receiving domains to adopt PQC. Support is consistent across a hostname’s addresses, and a domain’s MX hosts agree in 99.0% of cases; §4.4 examines the exceptions, where a backup MX without PQC opens a downgrade path.

4.3

PQC Adoption per Provider

Figure 2 (Appendix §D) groups the stable domains by provider. As in prior work [31], Google, Microsoft, and Proofpoint lead MX relay. Provider Concentration. Google accounts for approximately 87% of the 168,438 hybrid-capable relay domains and 96% to 97% of PQC-capable submission and access domains. It is also the only named provider in Figure 2 with observed pure ML-KEM support.

They Will See Johnny’s Message: A Measurement Study of Post-Quantum Cryptography Across Email Delivery Paths

Table 2: PQC support across services and snapshots. Each row uses domains with successful TLS in all three snapshots, with its denominator below the service name. Cells report percentages and counts. Hybrid and Pure indicate support observed with hybrid-only and pure ML-KEM offers. Aug 17 Hop Submission

(356,871 domains)

MX relay (explicit MX) (508,116 domains)

MX relay (implicit MX) (3,552 domains)

Access: IMAP

(359,098 domains)

Access: POP3

(316,683 domains)

Webmail

(65,904 domains)

Hybrid

Pure

39.8% 38.9% (142,138) (138,879)

Aug 31 Hybrid

0.0% (0)

Sep 14 Hybrid

39.9% 38.9% 40.2% (142,324) (138,879) (143,539)

32.9% 28.8% 33.1% (167,295) (146,535) (168,194) 3.4% (119)

Pure

3.4% (120)

28.8% 33.1% (146,535) (168,319) 0.0% (0)

3.4% (119)

Pure 38.9% (138,879) 28.8% (146,535) 0.0% (0)

39.8% 38.6% 39.8% 38.6% 40.2% (142,989) (138,779) (143,078) (138,779) (144,396) 46.4% 45.5% 46.4% 45.5% 46.8% (146,896) (144,053) (146,909) (144,053) (148,341)

38.6% (138,779) 45.5% (144,053)

34.3% (22,588)

17.8% (11,751)

36.2% (23,834)

17.8% (11,751)

41.0% (27,017)

4.4

Conference’17, July 2017, Washington, DC, USA

Primary and Backup MX Consistency

To understand whether inconsistent support among a domain’s MX hosts opens a downgrade path, we compare primary and backup MX support among the 168,319 hybrid-capable domains with explicit MX records. For 417 domains, despite the primary supporting hybrid key exchange, a backup does not (e.g., leboncoin.fr, Tranco rank 1,207). Blocking access to the primary could thus force a capable sender to a classical-only backup. This connection need not violate MTA-STS or DANE if the backup satisfies the applicable authentication policy, since neither mechanism requires a PQC key-exchange group [12, 33]. Conversely, for 1,222 domains, the primary lacks hybrid support while a backup supports it. These domains meet the criterion of having at least one capable endpoint, yet delivery through the preferred MX remains traditional. Assessing a domain’s PQC readiness on relay therefore requires checking every MX host it lists, and domains should enable PQC on every MX host. Representative domains appear in §F.1.

5 RQ2: PQC Negotiation by Clients and MTAs 5.1 Mail Client Negotiations in Practice Accordingly, the pure ML-KEM support that appears consistently in the webmail rows of Table 2 comes from Gmail. In contrast, Microsoft serves approximately 103,000 to 114,000 panel domains at each measured stage, including nist.gov, without observed hybrid or pure ML-KEM support. Because Microsoft also operates a large share of intermediate delivery infrastructure [28], its lack of support likely affects more mail than its domain count alone suggests. Proton, which markets itself as a privacy-focused provider, likewise shows no PQC support on any domains. Support outside Google is concentrated among a few smaller providers and filtering services, with fewer than 850 self-hosted relay domains supporting hybrid exchange. Filtering Gateway Limitations. Most measured filtering gateways, including Proofpoint, Mimecast, and Barracuda, show no PQC support at their MX endpoints, while Cloudflare Email Security supports hybrid exchange. A traditional-only gateway prevents PQC on the external relay connection even when the mailbox provider supports it. For example, zoom.us uses Proofpoint for filtering and Google Workspace for mailboxes, as inferred in §F.1. Mailboxprovider capability alone does not establish relay readiness. Hop Heterogeneity. PQC deployment is hop-specific even within a single provider. Namecheap and Yahoo support hybrid exchange on all of their measured MX-relay domains but on none of their submission or access domains, whereas Fastmail shows the reverse pattern, supporting it on submission and access but not on inbound relay. A user of these providers is thus protected on one side of the path and exposed on the other. Provider-Driven Changes. Over four weeks, too short to establish a trend, providers continue to adopt PQC and none withdraws support. On relay, submission, and access, hybrid support rises by at most 0.4 percentage points, driven by single providers (Migadu on relay, Strato on submission and access), while pure ML-KEM support is unchanged. Webmail grows faster, from 36.2% to 41.0% in two weeks, as independently operated hosting servers, mostly cPanel, enable hybrid exchange. Attribution details are in §F.1.

Measurement method. To understand the behavior of PQC-TLS on the client-side in 1 , 2 , and 4 of Figure 1, we tested Apple Mail, Gmail, and Outlook on the platforms in Table 3, using the latest versions available as of September 2026. These applications account for 95% of email opens tracked by Litmus [30]. All mail clients are configured with our own Gmail account, whose submission and access servers accept hybrid and pure ML-KEM groups in our RQ1 scans, so that a traditional handshake can be attributed to the client rather than the server. For each configuration, we restart the client, send and retrieve a message, and capture the TLS handshakes. We record the TLS version, advertised supported_groups, key_share, and selected group to distinguish offered capability from negotiation. Platform-Dependent Negotiation. Even with the same application and PQC-capable server, the client platform decides whether client-facing hops resist HNDL attacks. As shown in Table 3, Gmail on the web, Android, and iOS and Apple Mail on iOS and iPadOS offer and negotiate X25519MLKEM768, whereas Apple Mail on macOS and Outlook on Windows connect over TLS 1.2, which cannot offer or negotiate any PQC group. Apple Mail thus protects the same mailbox against HNDL on an iPhone but not on a Mac. Vendors should therefore align PQC support across all platforms of a client rather than inheriting it from each platform’s TLS stack. Intermediary-Induced Limitations. Interestingly, Outlook on macOS offers a PQC group but does not negotiate one in any observed connection. The Received headers explain why. The client connects not to the Gmail server directly but to a Microsoft relay, which supports no PQC (§4). A PQC-capable client and a PQCcapable server are thus not sufficient when an intermediary the user did not configure sits between them.

5.2

MX Relay Negotiations in Practice

Measurement method. To observe the client side of the MX-relay hop ( 3 in Figure 1), we operate a controlled MX server (Postfix 3.10, OpenSSL 3.5) and send messages to it from accounts at the eight providers in Table 4: five with inbound PQC support that permit

Conference’17, July 2017, Washington, DC, USA

Park et al.

Table 3: PQC offers and selection in client-facing connections. Off. marks a PQC group in the ClientHello, and Neg. marks selection in the ServerHello. means yes, # means no, and denotes TLS 1.2 only. Submission

Apple Mail

Client

Platform

Off.

Neg.

Access Off.

Gmail

All-groups server

Neg.

macOS v27

Sender

iPadOS v27

Migadu Namecheap

iOS v27

Google Proton

Web browser Chrome v154

Outlook

Table 4: Outbound delivery to our test MX. Inbound reports receiving PQC capability. All-groups accept traditional and PQC groups, whereas PQC-only restricts the TLS group list, not necessarily plaintext SMTP acceptance. means yes, # means no, and n/a indicates that no TLS retry was needed.

Mobile App (Android; v17) Mobile App (iOS; v27) Desktop (Windows) v2609 Desktop (macOS) v16.113.3

Mailgun Yahoo Outlook Zoho

5.3 account registration from the USA, and three without observed inbound support. We test two inbound-server configurations. In the all-groups configuration, our MX accepts every group in Table 8, revealing which key groups outbound MTAs offer by default. In the PQC-only configuration, our MX accepts only hybrid and pure MLKEM groups, which shows whether a sender can complete a PQC handshake and how it handles failure when no traditional group is available. For every delivery attempt, we record the groups and key shares in the ClientHello, the selected group, and retries. Our test domain publishes deliberately neither MTA-STS nor DANE, which reflects the vast majority of receiving domains: fewer than 1% of .com, .net, and .org domains with MX records publish TLSA records [26], and only 0.0124% of 1.76M scanned domains have activated MTA-STS [54]. Inbound–Outbound Asymmetry. Even providers that accept PQC on their server-side do not necessarily offer it when they send, leaving the relay hop exposed to HNDL attacks in the outbound direction. Under the all-groups configuration, only Migadu and Namecheap offer and negotiate X25519MLKEM768 (Table 4). Google, Yahoo, and Mailgun accept hybrid key exchange on their own MX hosts (§4) but offer no PQC group in their outbound ClientHello, and Mailgun’s sender still negotiates TLS 1.2. Because the ClientHello of these senders contains no PQC group, the cause is not a server choice. Therefore, even Google, the leading PQC provider on the server side, does not guarantee HNDL protection for outgoing mail. Plaintext Fallback under PQC Enforcement. Enforcing PQC on the receiving side to resist HNDL can backfire. Senders that cannot complete a PQC handshake may deliver the message in plaintext, exposing it to any passive eavesdropper today, not only to an adversary with a future CRQC. Under the PQC-only configuration, the six senders without PQC split into two behaviors (Table 4). Google and Proton retry the handshake and then defer the message, so delivery is delayed but never unencrypted in our experiment during our observation period (1 day). Mailgun, however, delivers without STARTTLS after two retries, and Yahoo, Outlook, and Zoho do so within one second without any further TLS attempt.

Inbound

# # #

TLS

Key exchange

1.3 1.3

X25519MLKEM768 X25519MLKEM768

1.3 1.3

X25519 X25519

1.2 1.3 1.3 1.3

X25519 X25519 P-256 X25519

PQC-only server TLS retry n/a n/a

Outcome PQC PQC Defer Defer

# # #

Plaintext Plaintext Plaintext Plaintext

SMTP Software

Measurement method. The eight providers are large operators running proprietary or unknown MTAs. Their behavior does not represent the population of mail servers, including the self-hosted and smaller-provider domains in §4. To fill this gap, we examine Exim and Postfix, which account for 55% and 39% of mail servers in a 2025 survey [1]. We test Exim 4.100.1 [55] and Postfix 3.11.7 [58] on Ubuntu 26.04, each built against PQC-capable OpenSSL 3.5.5 and non-PQC OpenSSL 3.4.1. With the PQC-capable builds, we run each implementation as both sender and receiver under two configurations: the unmodified default and a PQC-only group restriction. With the non-PQC builds, we run each implementation as a sender toward a PQC-only receiver. Table 9 (§E) summarizes the results. Default Negotiation. A default installation with a PQC-capable TLS library does not guarantee a PQC handshake. Both implementations accept hybrid exchange as receivers, and Exim also negotiates it as a sender. However, Postfix advertises X25519MLKEM768 in supported_groups while supplying a key share only for X25519. A receiver that selects from the offered shares, as ours does, therefore completes the handshake with X25519. Sending MTAs should therefore supply a hybrid key share, not merely advertise the group to mitigate HNDL attacks. Group Restrictions and Failure Handling. A PQC-only restriction protects mail when both MTAs implement ML-KEM and apply the restriction correctly, and it causes a sender without ML-KEM to fall back to plaintext. First, we restrict each implementation to PQC-only groups and test whether it still sends and receives mail over PQC. Postfix behaves correctly in both directions. Exim 4.100.1 sends in plaintext as a sender and fails to receive as a receiver because of a TLS configuration bug, which we reported and the developers have fixed.1 With the fix, Exim also enforces the restriction in both directions. Second, we build each implementation against OpenSSL 3.4.1, which lacks ML-KEM, and test how it behaves as a sender toward a PQC-only receiver. Both fall back to plaintext: Exim immediately and Postfix after deferring and retrying. These behaviors match the immediate and retry-then-plaintext fallbacks 1 The report link is omitted to preserve anonymity.

They Will See Johnny’s Message: A Measurement Study of Post-Quantum Cryptography Across Email Delivery Paths

observed for providers in §5.2. Because Exim and Postfix together run on 94% of surveyed mail servers [1], plaintext fallback may affect far more mail than our provider sample shows.

6 RQ3: Message-Level PQC Support 6.1 Measurement Method Applications and test key corpus. We evaluate 27 client–platform configurations (Table 11), selected from prior client studies [36, 56] and extended with Thunderbird (Android), each in the latest version at the time of testing. Of these, 24 support OpenPGP and 17 support S/MIME; 14 support both. The unit of analysis is the configuration rather than the client, since a client may rely on a different cryptographic backend on each platform. For example, Thunderbird uses RNP on desktop platforms and PGPony on Android. Key corpus. Our corpus of 19 OpenPGP keys and six S/MIME certificates (Table 10) starts from A1, the minimal RFC 9980-conformant key (v6, Ed25519 primary, ML-KEM-768+X25519) [24]. Except for G1–G3, each key differs from at least one other corpus key in exactly one factor—key version (v4, v5), KEM (ML-KEM-1024+X448), or primary algorithm (ML-DSA, SLH-DSA, RSA-3072, legacy EdDSA)—so that a failure can be attributed to a single cause. A1–A7 are the test vectors in Appendix A of RFC 9980. It also includes three GnuPG-generated LibrePGP keys (G1–G3; v2.2.2 [47]) and two combinations that RFC 9980 prohibits (N3, N4) as negative controls. The certificates O1–O6 cover ML-KEM-512/768/1024 in standard and legacy PKCS#12 packaging; details in Appendix §F.2. Workflow tests. For each configuration, we test whether the client generates a PQC key natively and, since users must otherwise import one, whether it imports each key, encrypts to it, and decrypts a message encrypted to it. We count native generation as successful only if the client offers PQC key generation, an import as successful only if the keyring or certificate store lists the ML-KEM key as encryption-capable rather than reporting it as imported, and an exchange as successful only if encryption and decryption complete (Table 11). For the disallowed keys N3 and N4, rejection is correct, and acceptance indicates non-conformance to RFC 9980.

6.2

Native Key Generation

None of the 27 implementations supports native PQC key generation, as their key-generation interfaces offer only RSA and ECC algorithms. The Bat! is the closest case, delegating key generation to the GnuPG interface without implementing it. Proton Mail, which has announced quantum-safe encryption, exposed neither a postquantum option nor an algorithm selection in our account during the measurement period. Consequently, users must generate PQC keys with external tools and import them manually. This dependency reintroduces the key-management burden that two decades of usability research identify as the primary barrier to encrypted email [45, 46]. Native PQC key generation is therefore a prerequisite for usable message-level protection.

6.3

Key Import

We examine whether an externally generated PQC key can be imported. We find that the cryptographic backend, the key version, and the primary key’s signature algorithm, rather than the client itself, largely determine the import results (Table 11 of Appendix §F.2).

Conference’17, July 2017, Washington, DC, USA

Backend Dependence. Ten of the 24 OpenPGP configurations reject (#) all 19 keys. Their backends explain this. OpenPGP.js and Bouncy Castle (C#) have no released version that implements MLKEM subkeys, and RNP implements them only behind a build option that is off by default and not enabled in the builds Thunderbird ships. 2 Canary Mail bundles Bouncy Castle (Java) 1.66, which predates ML-KEM, and the macOS Keychain is closed source, so its status cannot be confirmed from documentation. The remaining 14 configurations use GnuPG- or PGPony-based backends and import (G # or ) at least one key with an ML-KEM subkey. Within each group, the results are identical. All 11 GnuPG-based configurations import the same 12 keys, and all three PGPony-based configurations import the same 15 keys. Users who want to mitigate HNDL attacks must therefore consider a client by its backend. Primary-Key Gating. ML-KEM subkey support alone does not ensure import, because the primary key’s signature algorithm can block an encryption subkey. All 11 GnuPG-based configurations reject A3–A7, whose ML-DSA or SLH-DSA primary keys GnuPG cannot verify, while accepting their matched keys A1 (for A3, A5, A6) and N2 (for A4, A7), which differ only in having an Ed25519 primary key. Since a subkey is bound to its primary key by a signature, a backend that cannot verify that signature discards the ML-KEM subkey with it. Unlike TLS, which negotiates key exchange independently of authentication, OpenPGP binds the encryption subkey to the primary key’s signature. The three PGPony-based configurations import A3 and A4 but fail (G #) to exchange messages (§6.4). The PGPony-based configurations import N3, which RFC 9980 prohibits, and then fail to encrypt to it (Appendix §F.2). Certificate-Store Dependence. For S/MIME, the certificate store, not the mail client, decides whether a certificate can be imported. Four stores accept all six certificates because each has added MLKEM key handling: Windows CNG (since the November 2025 update), OpenSSL 4.0.3 (ML-KEM since 3.5, CMS support since 3.6), NSS (3.129 bundled with Thunderbird, 3.131 with Evolution), and .NET 9.0.1. Only the first two also complete an exchange ( ); NSS, .NET PKCS, and Horde’s OpenSSL import the certificates but cannot use them (G #) (see §6.4). The other stores reject or silently ignore the certificates because they have no ML-KEM support: gpgsm for S/MIME (GnuPG added ML-KEM to gpg, its OpenPGP program, but not to gpgsm, its S/MIME program), the iOS and macOS Keychains (Apple ships ML-KEM in CryptoKit but has not connected it to certificates), the built-in stores of three clients (closed source), and NSS 3.28.6 in Postbox (a 2017 release, before ML-KEM existed).

6.4

Encryption and Decryption

Successful import does not guarantee successful encryption and decryption. For OpenPGP, most GnuPG-based configurations complete message exchange with nine of the 12 imported keys, and with all 12 after correcting the encoding flaw described below. However, PGPony-based configurations complete it with only three of the 15 keys they import. These three, the v6 keys with a traditional primary key (A1, N2, R-v6), are the only keys that work in both GnuPG- and PGPony-based configurations, and thus the only 2 OpenPGP.js 6.3.1 keeps ML-KEM in draft pull requests; RNP 0.18.1 ships with

ENABLE_PQC off and aborts on algorithm 35 subkeys; bc-csharp 2.70 has an open RFC 9980 feature request.

Conference’17, July 2017, Washington, DC, USA

choice for users whose correspondents may use either backend. For S/MIME, only two of the four certificate stores that import ML-KEM certificates also encrypt to them. GnuPG-Based Clients. Eight of the eleven GnuPG-based configurations exchange messages with every imported key except the three v4 keys (A2, R-v4, L-v4). For these three keys, GnuPG 2.5.24 writes twelve extra zero octets after the v4 fingerprint in the PKESK packet, so no recipient, including the sender, can decrypt the message. Removing these octets restores decryption (‡ in Table 11; §F.2.2). The remaining three configurations fail in their own integration code (details in §F.2.2). Horde fails on every imported key because it treats a GnuPG warning about an obsolete option as an error. Postbox fails on every v5 and v6 key because its Enigmail layer derives key IDs with the v4 rule. Mailpile fails on G1–G3, whose v4 primary and v5 subkey fingerprints differ in length, because it loses their key records after import. PGPony-Based Clients. The three PGPony-based configurations exchange messages only with A1, N2, and R-v6. The other keys they import fail because PGPony applies different logic at import and at encryption. Import performs no version check, whereas encryption accepts only v6 keys, so every imported v4 or v5 key fails, including the prohibited N3. Import also falls back to PGPony’s own implementation, which supports ML-DSA, whereas encryption uses only bc-java, which does not, so A3 and A4 fail as well (§F.2.2). S/MIME. Only Outlook Classic and Mutt complete an S/MIME exchange, each with all six certificates, because only their stores both parse ML-KEM certificates (RFC 9935) and encrypt to them with KEMRecipientInfo (RFC 9629). The other five configurations import the certificates and build envelopes with code that accepts only RSA and EC recipients or lacks KEMRecipientInfo (§F.2.2).

7 Discussion 7.1 Deployment Recommendations We suggest four recommendations based on our findings. Plaintext Fallback under PQC Enforcement. A PQC-only receiver caused four of six non-PQC senders, and both MTAs built without ML-KEM, to deliver in plaintext (§5.2, §5.3). Enforcing PQC thus trades a future CRQC threat for present exposure to any passive observer. Receivers should restrict key-exchange groups only after rejecting unencrypted SMTP; senders should defer or bounce on handshake failure, as Google and Proton do, rather than retry without TLS. Because MTA-STS and DANE cannot require a key-exchange group, expressing such a policy needs an extension. Capability–Negotiation Gap. Three providers accept hybrid groups inbound but offer none outbound, and default Postfix advertises X25519MLKEM768 without its key share (§5.2, §5.3). Capability scan [32] therefore overestimates protection. Providers should enable PQC on outbound MTAs and verify that the ClientHello carries the key share; readiness reports should distinguish groups a server accepts from groups observed in handshakes it initiates. Per-Hop Coverage. A traditional-only filtering gateway, a nonPQC backup MX (417 domains), or an unconfigured relay (Outlook on macOS) each removes PQC from a path whose endpoints support it (§4.3, §4.4, §5.1). Providers should enable PQC per service and direction, operators should verify every MX host they list, and

Park et al.

gateway operators should treat their own support as a precondition for every domain behind them. Message-Level Usability. No tested client generates a PQC key natively. And the backend is crucial for determining behaviors. Clients should consider generating PQC keys natively for usability, validate imports against RFC 9980, and apply the same backend logic at import and at encryption. Until then, users should choose v6 keys with a traditional primary and an ML-KEM subkey, the only keys that worked across both tested backends.

7.2

Limitations and Responsible Disclosure

Infrastructure, not traffic. Our server measurements describe infrastructure, not traffic. The Tranco sample covers ranked domains rather than email accounts, and support rates are conditional on the endpoints we discovered and on stage-specific panels with successful TLS in all snapshots. They neither share a common population across services nor establish protection along complete message paths. Service discovery and provider attribution rely on externally visible information, provider-internal connections remain unobserved, and a single vantage point over four weeks limits geographic and temporal generalization. Case studies, not prevalence. Our experiments are case studies, not prevalence estimates. The client, MTA, and message-level results apply to the tested applications, versions, backends, and configurations. The eight-provider sample does not estimate how often PQC is negotiated or how often senders fall back to plaintext across email traffic. Delivery outcomes are bounded by our receiver policies and observation period, and shared backends make failures across applications correlated rather than independent. Technical barriers, not causes. We identify technical barriers, not organizational causes. The experiments show what fails under the tested conditions, but not why providers and vendors have made their adoption decisions. Answering this requires operator interviews or vendor surveys, which we leave for future work. Responsible disclosure. We reported the Exim TLS configuration bug, which the developers have fixed. We notified the PGPony, Horde, Postbox, and Mailpile maintainers of the integration failures. We plan to report the GnuPG PKESK encoding flaw to developers.

Conclusion

We measured PQC readiness across email services through Internetscale server probes and controlled tests of clients, sending MTAs, and message encryption. Fewer than half of the domains at every stage support PQC, and Google accounts for approximately 87% of hybrid-capable relay domains. Receiving support does not ensure outbound use, as only two of eight tested sending providers negotiate PQC despite five accepting it inbound. Under PQC-only TLS restrictions, four of the six incompatible senders deliver in plaintext where unencrypted SMTP remains permitted. At the message layer, no tested client generates a PQC key natively, and key-format and integration failures prevent many imported keys from completing a message exchange. These findings show that migration requires more than deploying PQC algorithms. Providers and developers must turn capability into negotiated connections and working encryption, and must ensure that handshake failures do not fall back

They Will See Johnny’s Message: A Measurement Study of Post-Quantum Cryptography Across Email Delivery Paths

to plaintext. Post-quantum capability is not post-quantum communication.

References [1] Alfred Arouna, Rick Fontein, Bernd Meijerink, Ioana Livadariu, and Mattijs Jonker. 2025. On the Role of Forward-Confirmed reverse DNS in E-mail Authentication. In 2025 9th Network Traffic Measurement and Analysis Conference (TMA). IEEE, 1–11. [2] Michael Bailey, David Dittrich, Erin Kenneally, and Doug Maughan. 2012. The menlo report. IEEE Security & Privacy 10, 2 (2012), 71–75. [3] Aritra Banerjee, Tirumaleswar Reddy K., Dimitrios Schoinianakis, Timothy Hollebeek, and Mike Ounsworth. 2026. Post-Quantum Cryptography for Engineers. RFC 9958. doi:10.17487/RFC9958 [4] Ben Bucksch. 2026. Mail Autoconfig: draft-ietf-mailmaint-autoconfig-06. autoconfig-06. https://datatracker.ietf .org/doc/draft-ietf-mailmaint-autoconfig/ 06/ [5] Karthikeyan Bhargavan, Charlie Jacomme, Franziskus Kiefer, and Rolfe Schmidt. 2024. Formal verification of the { PQXDH } { Post-Quantum } key agreement protocol for end-to-end secure messaging. In 33rd USENIX Security Symposium (USENIX Security 24). 469–486. [6] Birk Blechschmidt and Ben Stock. 2023. Extended Hell(o): A Comprehensive Large-Scale Study on Email Confidentiality and Integrity Mechanisms in the Wild. In 32nd USENIX Security Symposium (USENIX Security 23). USENIX Association, Anaheim, CA, 4895–4912. https://www.usenix.org/conference/usenixsecurity23/ presentation/blechschmidt [7] D. Connolly. 2025. ML-KEM Post-Quantum Key Agreement for TLS 1.3. InternetDraft, draft-ietf-tls-mlkem, IETF. Work in progress. https://datatracker.ietf .org/ doc/draft-ietf-tls-mlkem/ [8] M. Crispin. 2003. Internet Message Access Protocol - Version 4rev1. RFC 3501. doi:10.17487/RFC3501 [9] Cybersecurity and Infrastructure Security Agency and National Security Agency and National Institute of Standards and Technology. 2023. Quantum-Readiness: Migration to Post-Quantum Cryptography. Joint factsheet. https://www.cisa.gov/ resources - tools / resources / quantum - readiness - migration - post - quantum cryptography [10] T. Dierks and E. Rescorla. 2008. The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246. doi:10.17487/RFC5246 [11] F. Driscoll, M. Parsons, and B. Hale. 2025. Terminology for Post-Quantum Traditional Hybrid Schemes. RFC 9794. doi:10.17487/RFC9794 [12] V. Dukhovni and W. Hardaker. 2015. SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS). RFC 7672. doi:10.17487/RFC7672 [13] Zakir Durumeric, David Adrian, Ariana Mirian, James Kasten, Elie Bursztein, Nicolas Lidzborski, Kurt Thomas, Vijay Eranti, Michael Bailey, and J Alex Halderman. 2015. Neither snow nor rain nor MITM... an empirical analysis of email delivery security. In Proceedings of the 2015 Internet Measurement Conference. 27–39. [14] R. Fielding, M. Nottingham, and J. Reschke. 2022. HTTP Semantics. RFC 9110. doi:10.17487/RFC9110 [15] Ian D Foster, Jon Larson, Max Masich, Alex C Snoeren, Stefan Savage, and Kirill Levchenko. 2015. Security by any other name: On the effectiveness of provider based email security. In Proceedings of the 22nd ACM SIGSAC conference on computer and communications security. 450–464. [16] R. Gellens and J. Klensin. 2011. Message Submission for Mail. RFC 6409. doi:10.17487/RFC6409 [17] P. Hoffman. 2002. SMTP Service Extension for Secure SMTP over Transport Layer Security. RFC 3207. doi:10.17487/RFC3207 [18] Jacob Hoffman-Andrews. 2014. ISPs Removing Their Customers’ Email Encryption. Electronic Frontier Foundation, Deeplinks Blog. https://www.eff .org/deeplinks/ 2014/11/starttls-downgrade-attacks [19] Ralph Holz, Johanna Amann, Olivier Mehani, Matthias Wachs, and Mohamed Ali Kaafar. 2015. TLS in the wild: An Internet-wide analysis of TLS-based protocols for electronic communication. arXiv preprint arXiv:1511.00341 (2015). [20] Florian Holzbauer, Johanna Ullrich, Martina Lindorfer, and Tobias Fiebig. 2022. Not that Simple: Email Delivery in the 21st Century. In 2022 USENIX Annual Technical Conference (USENIX ATC 22). USENIX Association, Carlsbad, CA, 295– 308. https://www.usenix.org/conference/atc22/presentation/holzbauer [21] Liz Izhikevich, Gautam Akiwate, Briana Berger, Spencer Drakontaidis, Anna Ascheman, Paul Pearce, David Adrian, and Zakir Durumeric. 2022. ZDNS: a fast DNS toolkit for internet measurement. In Proceedings of the 22nd ACM Internet Measurement Conference. 33–43. [22] J. Klensin. 2008. Simple Mail Transfer Protocol. RFC 5321. doi:10.17487/RFC5321 [23] Werner Koch and Ronald Henry Tse. 2026. LibrePGP Message Format. InternetDraft draft-koch-librepgp-06. Internet Engineering Task Force. Work in Progress. https://datatracker.ietf .org/doc/draft-koch-librepgp/06/

Conference’17, July 2017, Washington, DC, USA

[24] Stavros Kousidis, Johannes Roth, Falko Strenzke, and Aron Wussler. 2026. PostQuantum Cryptography in OpenPGP. RFC 9980. Internet Engineering Task Force. Proposed Standard. doi:10.17487/RFC9980 [25] K. Kwiatkowski, P. Kampanakis, B. E. Westerbaan, and D. Stebila. 2026. PostQuantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3. RFC 10024. doi:10.17487/RFC10024 [26] Hyeonmin Lee, Aniketh Gireesh, Roland van Rijswijk-Deij, Taejoong Chung, et al. 2020. A longitudinal and comprehensive study of the { dane } ecosystem in email. In 29th { USENIX } Security Symposium ( { USENIX } Security 20). [27] J. Levine and M. Delany. 2015. A “Null MX” No Service Resource Record for Domains That Accept No Mail. RFC 7505. doi:10.17487/RFC7505 [28] Ruixuan Li, Chaoyi Lu, Baojun Liu, Yanzhong Lin, Haixin Duan, Qingfeng Pan, and Jun Shao. 2025. Understanding and characterizing intermediate paths of email delivery: The hidden dependencies. In Proceedings of the 2025 ACM Internet Measurement Conference. 578–591. [29] Ruixuan Li, Zhenyong Zhang, Jun Shao, Rongxing Lu, Xiaoqi Jia, and Guiyi Wei. 2023. The potential harm of email delivery: Investigating the HTTPS configurations of webmail services. IEEE Transactions on Dependable and Secure Computing 21, 1 (2023), 125–138. [30] Litmus. 2026. Email Client Market Share: Trends & Statistics 2026. https:// www.litmus.com/email-client-market-share/. July 2026 report; data current as of August 1, 2026. Accessed: September 27, 2026. [31] Enze Liu, Gautam Akiwate, Mattijs Jonker, Ariana Mirian, Stefan Savage, and Geoffrey M Voelker. 2021. Who’s got your mail? characterizing mail service provider usage. In Proceedings of the 21st ACM Internet Measurement Conference. 122–136. [32] Konstantinos Loizou and Essam Ghadafi. 2026. Measuring Post-Quantum TLS Deployment Across UK Internet Sectors. arXiv preprint arXiv:2608.02147 (2026). arXiv:2608.02147 [cs.CR] doi:10.48550/arXiv.2608.02147 [33] D. Margolis, M. Risher, B. Ramakrishnan, A. Brotman, and J. Jones. 2018. SMTP MTA Strict Transport Security (MTA-STS). RFC 8461. doi:10.17487/RFC8461 [34] K. Moore and C. Newman. 2018. Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. RFC 8314. doi:10.17487/ RFC8314 [35] Michele Mosca. 2018. Cybersecurity in an Era with Quantum Computers: Will We Be Ready? IEEE Security & Privacy 16, 5 (2018), 38–41. doi:10.1109/ MSP.2018.3761723 [36] Jens Müller, Marcus Brinkmann, Damian Poddebniak, Hanno Böck, Sebastian Schinzel, Juraj Somorovsky, and Jörg Schwenk. 2019. { “Johnny } , you are { fired!” } –Spoofing { OpenPGP } and { S/MIME } Signatures in Emails. In 28th USENIX Security Symposium (USENIX Security 19). 1011–1028. [37] J. Myers and M. Rose. 1996. Post Office Protocol - Version 3. RFC 1939. doi:10.17487/RFC1939 [38] National Institute of Standards and Technology. 2024. Module-Lattice-Based Key-Encapsulation Mechanism Standard. doi:10.6028/NIST.FIPS.203 [39] C. Newman. 1999. Using TLS with IMAP, POP3 and ACAP. RFC 2595. doi:10.17487/RFC2595 [40] OpenSSL Library. [n. d.]. OpenSSL 3.5 Series Release Notes. https://openssllibrary.org/news/openssl-3.5-notes/. Accessed: September 16, 2026. [41] Victor Le Pochat, Tom Van Goethem, Samaneh Tajalizadehkhoob, Wouter Joosen, et al. 2018. Tranco: A research-oriented top sites ranking hardened against manipulation. arXiv preprint arXiv:1806.01156 (2018). [42] Damian Poddebniak, Fabian Ising, Hanno Böck, and Sebastian Schinzel. 2021. Why TLS is Better Without STARTTLS: A Security Analysis of STARTTLS in the Email Context. In 30th USENIX Security Symposium (USENIX Security 21). USENIX Association, 4365–4382. https://www.usenix.org/conference/usenixsecurity21/ presentation/poddebniak [43] Sumanth Rao, Enze Liu, Grant Ho, Geoffrey M Voelker, and Stefan Savage. 2024. Unfiltered: Measuring cloud-based email filtering bypasses. In Proceedings of the ACM Web Conference 2024. 1702–1711. [44] E. Rescorla. 2018. The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446. doi:10.17487/RFC8446 [45] Scott Ruoti, Jeff Andersen, Daniel Zappala, and Kent Seamons. 2015. Why Johnny still, still can’t encrypt: Evaluating the usability of a modern PGP client. arXiv preprint arXiv:1510.08555 (2015). [46] Scott Ruoti and Kent Seamons. 2019. Johnny’s journey toward usable secure email. IEEE Security & Privacy 17, 6 (2019), 72–76. [47] Saturneric. 2026. GpgFrontend: A Cross-Platform OpenPGP Tool with GnuPG and rPGP Backends. Accessed on October 26, 2026. https://github.com/saturneric/ GpgFrontend [48] J. Schaad, B. Ramsdell, and S. Turner. 2019. Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification. RFC 8551. doi:10.17487/ RFC8551 [49] Peter W. Shor. 1997. Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer. SIAM J. Comput. 26, 5 (1997), 1484–1509. doi:10.1137/S0097539795293172 [50] Dimitrios Sikeridis, Panos Kampanakis, and Michael Devetsikiotis. 2020. Postquantum authentication in TLS 1.3: A performance study. Cryptology ePrint

Conference’17, July 2017, Washington, DC, USA

Park et al.

Archive (2020). [51] Statista Research Department. 2025. Number of sent and received e-mails per day worldwide from 2018 to 2028 (in billions). Statista. https://www.statista.com/ statistics/456500/daily-number-of-e-mails-worldwide/ [52] Christian Stransky, Oliver Wiese, Volker Roth, Yasemin Acar, and Sascha Fahl. 2022. 27 years and 81 million opportunities later: Investigating the use of email encryption for an entire university. In 2022 IEEE Symposium on Security and Privacy (SP). IEEE, 860–875. [53] Ka Fun Tang, Che Wei Tu, Sui Ling Angela Mak, and Sze Yiu Chau. 2025. A Multifaceted Study on the Use of TLS and Auto-detect in Email Ecosystems.. In NDSS. [54] Dennis Tatang, Robin Flume, and Thorsten Holz. 2021. A first large-scale analysis on usage of mta-sts. In International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Springer, 361–370. [55] toolsmith. 2026. [exim-dev] exim-4.100.1 in exim/exim released. Exim-dev mailing list. Accessed: October 4, 2026. https://www.mail-archive.com/eximdev@lists.exim.org/msg01744.html [56] Leon Trampert, Daniel Weber, Christian Rossow, and Michael Schwarz. 2025. Styled to Steal: The Overlooked Attack Surface in Email Clients. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security. 2069–2083. [57] Université Toulouse 1 Capitole. 2026. UT1 Web Categorization Blacklists: Webmail Category. https://github.com/olbat/ut1-blacklists. Accessed: September 26, 2026. [58] Wietse Venema. 2026. Postfix stable release 3.11.7 and legacy releases 3.10.14, 3.9.15, 3.8.21, 3.7.23, 3.6.21, 3.5.28. Accessed: October 4, 2026. https:// www.postfix.org/announcements/postfix-3.11.7.html [59] Shushang Wen, Yiming Zhang, Yuxiang Shen, Bingyu Li, Haixin Duan, and Jingqiang Lin. 2025. Automatic Insecurity: Exploring Email Auto-configuration in the Wild.. In NDSS. [60] Alma Whitten and J. D. Tygar. 1999. Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0. In Proceedings of the 8th USENIX Security Symposium. [61] Nimesha Wickramasinghe, Frank Li, Sanjay Jha, and Arash Shaghaghi. 2026. Mind the gap: Policy vs reality in post-quantum TLS deployment. In Proceedings of the 2026 ACM Internet Measurement Conference. 256–275. [62] P. Wouters, D. Huigens, J. Winter, and Y. Niibe. 2024. OpenPGP. RFC 9580. doi:10.17487/RFC9580

Table 6: DNS resolution outcomes for the Tranco Top 1M domains. Percentages use all one million domains, and indented rows subdivide the preceding category. Type

666,226 (66.6%) 666,181 (66.6%) 45 (0.0%) 304,515 (30.5%) 250,545 (25.1%) 53,970 (5.4%) 4,327 (0.4%) 10,674 (1.1%) 14,258 (1.4%)

Total

1,000,000 (100.0%)

Table 7: Endpoint discovery for the client-facing hops (Submissions and Access). Source

Email Protocols and TLS Modes

Count (%)

Explicit MX ↩→ Valid MX ↩→ Malformed MX No MX ↩→ Implicit MX ↩→ No A/AAAA record Null MX NXDOMAIN DNS error

Submission

Access IMAP

POP3

Autoconfig Autodiscover DNS SRV ISPDB

30,366 (7.9%) 57,537 (14.9%) 7,354 (1.9%) 289,878 (75.3%)

27,866 (7.2%) 56,770 (14.7%) 11,464 (3.0%) 289,127 (75.1%)

22,410 (6.8%) 8,016 (2.4%) 7,516 (2.3%) 293,157 (88.5%)

Domains

385,135 (100%)

385,227 (100%)

331,099 (100%)

Key Exchange Groups in OpenSSL v3.5.

Table 5 lists the protocols, ports, and TLS modes of the email services described in §2.1.

Table 8: Key exchange groups by category in OpenSSL v3.5.

Table 5: Protocols, ports, and TLS modes of email services.

They Will See Johnny's Message: A Measurement Study of Post-Quantum Cryptography Across Email Delivery Paths

Analyze & explore related research in Conceptio

Related documents