This page is about measuring what mail servers and mail clients have actually deployed — SPF, DKIM, DMARC, ARC, DANE, MTA-STS, STARTTLS, S/MIME and OpenPGP — and about the delivery path a message really takes. It is a methods page: which instrument answers which question, what the denominator has to be, what the field has already built, and which of its methods are current in 2026.

It is not an explanation of the protocols. RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC), RFC 7672 (DANE for SMTP) and RFC 8461 (MTA-STS) define them, and a fresh student can read those faster than any wiki paraphrase. What the RFCs do not tell you is that “60.9% of domains have SPF” and “56.5% of domains have SPF” are both true, in the same year, of the same protocol — because they are different populations, and the gap between them is wider than many of the differences papers headline.

The evidence base is 31 papers from the publication corpus — CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf and IEEE S&P, 2010–2026, 5,859 extracted papers. Those seven venues are where this subfield publishes, but they are not all of it: EuroS&P, ACSAC, RAID, AsiaCCS, TMA and the CCR/ANRW line are absent, so every count below is a count over those seven. How the 31 were selected is in Use in Publications and the full query log is on email_authentication.

Four papers, and you have the shape of the field:

• [1Durumeric, Zakir; Adrian, David; Mirian, Ariana; Kasten, James; Bursztein, Elie; Lidzborski, Nicolas; Thomas, Kurt; Eranti, Vijay; Bailey, Michael D.; Halderman, J. Alex (2015): "Neither Snow Nor Rain Nor MITM...: An Empirical Analysis of Email Delivery Security", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] — Neither Snow Nor Rain Nor MITM, IMC 2015. The founding measurement: Alexa Top Million MX scan, an IPv4-wide SMTP scan, and a year of Gmail's own SMTP handshake logs, in one paper. Read it for the three-instrument design, and for the STARTTLS-stripping result that no purely passive study could have found.
• [2Hu, Hang; Wang, Gang (2018): "End-to-End Measurements of Email Spoofing Attacks", in: Proceedings of the USENIX Security Symposium. (Link)] — End-to-End Measurements of Email Spoofing Attacks, USENIX Security 2018. The paper that moved the question from “who publishes a record” to “what arrives in the inbox”. Registers accounts at 35 providers and sends forged mail to itself. Most account-based delivery papers since are variants of it, though [3Foster, Ian D.; Larson, Jon; Masich, Max; Snoeren, Alex C.; Savage, Stefan; Levchenko, Kirill (2015): "Security by Any Other Name: On the Effectiveness of Provider Based Email Security", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] ran the same instrument at 22 providers three years earlier.
• [4Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2024): "SPF Beyond the Standard: Management and Operational Challenges in Practice and Practical Recommendations", in: Proceedings of the USENIX Security Symposium. (Link)] — SPF Beyond the Standard, USENIX Security 2024. Seventeen months of weekly zone-file scans over 176 million domains, plus an inbound probe that asks whether receiving MTAs validate SPF at all, plus an operator survey. The best current example of the three-sided design that the Ashiq–Chung line has made the expectation in this area.
• [5Wang, Chuhan; Kuranaga, Yasuhiro; Wang, Yihang; Zhang, Mingming; Zheng, Linkai; Li, Xiang; Chen, Jianjun; Duan, Haixin; Lin, Yanzhong; Pan, Qingfeng (2024): "BreakSPF: How Shared Infrastructures Magnify SPF Vulnerabilities Across the Internet", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] — BreakSPF, NDSS 2024. The 2024–2026 turn: the interesting object is no longer the record but the shared infrastructure the record authorises. 23,916 Tranco-top-million domains are spoofable because their SPF includes a cloud, CDN or CI/CD range an attacker can rent.

If your object is end-to-end encryption rather than transport, start at [6Poddebniak, Damian; Dresen, Christian; Müller, Jens; Ising, Fabian; Schinzel, Sebastian; Friedberger, Simon; Somorovsky, Juraj; Schwenk, Jörg (2018): "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels", in: Proceedings of the USENIX Security Symposium. (Link)] (Efail) and [7Öndarö, Gurur; Kaspereit, Jonas; Umezulike, Samson; Saatjohann, Christoph; Ising, Fabian; Schinzel, Sebastian (2025): "S/MINE: Collecting and Analyzing S/MIME Certificates at Scale", in: Proceedings of the USENIX Security Symposium. (Link)] (S/MINE: 41.7 million X.509 certificates crawled from public LDAP address books, of which 38 million are S/MIME-capable).

The 31 papers use twelve identifiable instruments. The median paper runs three, the mean is 2.74, and the range is one to five; four papers run only one and one runs five. Pick before you write the scanner, because the instrument decides which question you are answering — and there are at least six different questions here, which is why the papers that matter run three instruments rather than one. The period split for all twelve is in Instruments, folded.

The delivery test has an outcome variable and it is not binary. Fourteen of the 31 papers run this instrument and the ones worth copying code at least four outcomes — rejected at the SMTP layer, accepted and spam-foldered, delivered to the inbox, delivered to the inbox with a visible warning — and [2Hu, Hang; Wang, Gang (2018): "End-to-End Measurements of Email Spoofing Attacks", in: Proceedings of the USENIX Security Symposium. (Link)] adds a fifth dimension by inspecting the interface itself: 9 of 35 providers showed any security indicator, and 25 of 35 displayed a misleading element (a sender photo, a name card, a message history) on a forged message. [8Wang, Chenkai; Wang, Gang (2022): "Revisiting Email Forwarding Security under the Authenticated Received Chain Protocol", in: Proceedings of the ACM Web Conference. (DOI)] separates the same four outcomes again for ARC. A study that codes “arrived or not” throws away the finding.

The remaining six, thinner but not marginal: software testbed (7 papers — run Postfix, Exim, libspf2 in a lab and see which is wrong), code analysis (3), notification experiment (3 — tell the operators and rescan, see notifying_websites), passive DNS (2), user study (2), honey domain (1).

Two instruments are new. Neither the operator survey nor the software testbed appears at all before 2020 in this population; between them they are run by eight of the sixteen 2023–2026 papers and none of the six from 2015–2019. If you are designing a study now and your only instrument is a DNS scan, you are designing one panel of a 2015 paper.

Six of the 31 papers measure S/MIME and OpenPGP rather than transport or authentication: [6Poddebniak, Damian; Dresen, Christian; Müller, Jens; Ising, Fabian; Schinzel, Sebastian; Friedberger, Simon; Somorovsky, Juraj; Schwenk, Jörg (2018): "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels", in: Proceedings of the USENIX Security Symposium. (Link)], [9Müller, Jens; Brinkmann, Marcus; Poddebniak, Damian; Böck, Hanno; Schinzel, Sebastian; Somorovsky, Juraj; Schwenk, Jörg (2019): "“Johnny, you are fired!” – Spoofing OpenPGP and S/MIME Signatures in Emails", in: Proceedings of the USENIX Security Symposium. (Link)], [10Stransky, Christian; Wiese, Oliver; Roth, Volker; Acar, Yasemin; Fahl, Sascha (2022): "27 Years and 81 Million Opportunities Later: Investigating the Use of Email Encryption for an Entire University", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)], [11Ising, Fabian; Poddebniak, Damian; Kappert, Tobias; Saatjohann, Christoph; Schinzel, Sebastian (2023): "Content-Type: multipart/oracle - Tapping into Format Oracles in Email End-to-End Encryption", in: Proceedings of the USENIX Security Symposium. (Link)], [7Öndarö, Gurur; Kaspereit, Jonas; Umezulike, Samson; Saatjohann, Christoph; Ising, Fabian; Schinzel, Sebastian (2025): "S/MINE: Collecting and Analyzing S/MIME Certificates at Scale", in: Proceedings of the USENIX Security Symposium. (Link)], and part of [12Poddebniak, Damian; Ising, Fabian; Böck, Hanno; Schinzel, Sebastian (2021): "Why TLS is better without STARTTLS: A Security Analysis of STARTTLS in the Email Context", in: Proceedings of the USENIX Security Symposium. (Link)]. They are in this page's population because the object is still deployed mail machinery, but almost nothing else transfers:

• The instrument is the client matrix, not the DNS scan. Four of the six drive a matrix of 19 to 48 mail clients by hand ([6Poddebniak, Damian; Dresen, Christian; Müller, Jens; Ising, Fabian; Schinzel, Sebastian; Friedberger, Simon; Somorovsky, Juraj; Schwenk, Jörg (2018): "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels", in: Proceedings of the USENIX Security Symposium. (Link)] 48, [12Poddebniak, Damian; Ising, Fabian; Böck, Hanno; Schinzel, Sebastian (2021): "Why TLS is better without STARTTLS: A Security Analysis of STARTTLS in the Email Context", in: Proceedings of the USENIX Security Symposium. (Link)] 28, [9Müller, Jens; Brinkmann, Marcus; Poddebniak, Damian; Böck, Hanno; Schinzel, Sebastian; Somorovsky, Juraj; Schwenk, Jörg (2019): "“Johnny, you are fired!” – Spoofing OpenPGP and S/MIME Signatures in Emails", in: Proceedings of the USENIX Security Symposium. (Link)] 25, [11Ising, Fabian; Poddebniak, Damian; Kappert, Tobias; Saatjohann, Christoph; Schinzel, Sebastian (2023): "Content-Type: multipart/oracle - Tapping into Format Oracles in Email End-to-End Encryption", in: Proceedings of the USENIX Security Symposium. (Link)] 19); [7Öndarö, Gurur; Kaspereit, Jonas; Umezulike, Samson; Saatjohann, Christoph; Ising, Fabian; Schinzel, Sebastian (2025): "S/MINE: Collecting and Analyzing S/MIME Certificates at Scale", in: Proceedings of the USENIX Security Symposium. (Link)] adds a five-client check to a certificate scan, and [10Stransky, Christian; Wiese, Oliver; Roth, Volker; Acar, Yasemin; Fahl, Sascha (2022): "27 Years and 81 Million Opportunities Later: Investigating the Use of Email Encryption for an Entire University", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] runs no client tests at all.
• The denominator problem inverts. For SPF the hard question is which million domains; here it is that 49 clients is not a population and there is no list to sample from. These papers are vulnerability censuses over a purposive set, and none of them claims a prevalence.
• The two exceptions prove it. [10Stransky, Christian; Wiese, Oliver; Roth, Volker; Acar, Yasemin; Fahl, Sascha (2022): "27 Years and 81 Million Opportunities Later: Investigating the Use of Email Encryption for an Entire University", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] got a prevalence — 5.46% of users ever used S/MIME or PGP, 0.06% of emails encrypted — only by getting 27 years of one university's mail server. [7Öndarö, Gurur; Kaspereit, Jonas; Umezulike, Samson; Saatjohann, Christoph; Ising, Fabian; Schinzel, Sebastian (2025): "S/MINE: Collecting and Analyzing S/MIME Certificates at Scale", in: Proceedings of the USENIX Security Symposium. (Link)] got one by scanning public LDAP address books, which is a population nobody had thought to enumerate.

If your object is end-to-end encryption, read those six and treat the rest of this page as background.

This is the whole reason the page exists. Below are adoption figures for six mechanisms, from papers in the same corpus, each correct in its own paper and almost none comparable with any other. Two of the rows are the same scan on the same day and differ by 18.5 points.

Five traps are visible in that table, or visible by their absence from it:

1. “Domains” almost never means domains. Five of the twelve rows restrict to domains that have an MX record — and one of those five says it as “mail-enabled domains” instead, so you cannot even grep for the filter. That filter removes most registered names. For a receiving-side mechanism — STARTTLS, DANE, MTA-STS — it is clearly the right filter, because a domain with no MX receives no mail. For a sending-side mechanism — SPF, DMARC — it is a proxy and a lossy one: a domain that only sends mail has no reason to publish an MX, and the two BreakSPF rows above are the same scan on the same day, differing by 18.5 points purely on the filter — which is why that paper reports both rather than substituting one. Either way, a figure computed with the filter is not comparable to one computed without it. Say which you did, in the sentence that carries the number.
2. A top list is not a sample of the web, and the list changed. Alexa is the frame in 7 of the 31 papers; Tranco in 9; TLD zone files in 3. The last Alexa use in this population is 2023 and no paper from 2024 onwards uses it — Alexa's site shut down on 1 May 2022 and its APIs on 15 December 2022.¹⁾ A 2026 paper using an Alexa list is using a four-year-old snapshot of a dead ranking. Use Tranco with a pinned list ID [18Le Pochat, Victor; Van Goethem, Tom; Tajalizadehkhoob, Samaneh; Korczy´nski, Maciej; Joosen, Wouter (2019): "Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation", in: Proceedings of the 26th Annual Network and Distributed System Security Symposium. (DOI)], or a zone file, and see website_selection.
3. “Top 1M” and “top 10M” and “all of a zone” give different answers to the same question, in the same year. SPF is 60.2% of the top million and 56.5% of twelve million in one 2023 paper; 41.7% of a top-ten-million list in another 2023 paper. The gradient is real — popular domains deploy more — so a percentage without its rank window says nothing.
4. A published record is not a policy, and this is the trap a fresh student walks into first. Not one row of the table above splits by policy strength, because not one of those headline figures does. But p=none asks the receiver to do nothing, ?all authorises the whole internet, and a domain publishing either is counted as “deploying DMARC” or “deploying SPF” in every adoption rate on this page. The distribution is where the content is: [16Czybik, Stefan; Horlboge, Micha; Rieck, Konrad (2023): "Lazy Gatekeepers: A Large-Scale Study on SPF Configuration in the Wild", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] — filed above as “SPF configuration” — is largely about the qualifier distribution, and found 5.9% (427,767) of its domains publishing SPF with no restrictive all at all; the Dutch government census cited below separates DMARC at quarantine or reject (86%) from DMARC-at-all, and strict SPF (69%) from SPF-at-all, because the two differ by tens of points. Report the distribution, not the presence rate. A presence rate over a population where most records say p=none is a measurement of who has read a blog post.
5. DKIM has no denominator you can enumerate. SPF, DMARC and MTA-STS live at fixed DNS names; DKIM lives at <selector>._domainkey.<domain> and the selector is arbitrary. [13Wang, Chuhan; Shen, Kaiwen; Guo, Minglei; Zhao, Yuxuan; Zhang, Mingming; Chen, Jianjun; Liu, Baojun; Zheng, Xiaofeng; Duan, Haixin; Lin, Yanzhong; Pan, Qingfeng (2022): "A Large-scale and Longitudinal Measurement Study of DKIM Deployment", in: Proceedings of the USENIX Security Symposium. (Link)] scanned the Alexa top million with 40 selectors harvested from passive DNS and reports 28.1% as an explicit lower bound. Any DKIM deployment number is a lower bound; say what your selector list was and where it came from, or use passive DNS and say the archive's coverage is your denominator.

The single most consistent finding across eleven years of this literature, and the one a new study most often forgets to measure: the sender side and the receiver side are different populations, and the receiver side is far weaker.

That 6.8% is the number to remember. It is a 2024 measurement of whether receiving mail servers so much as look SPF up before accepting the message body — and within these 31 papers it is the only figure that measures inbound enforcement at internet scale rather than at 20–50 hand-picked providers. Deployment-rate papers count the left column of a two-column problem.

Every one of these papers has a second half, and it is always this: a large share of what is deployed is broken. If your study stops at the adoption rate you are reporting the good news only.

Two of these are exploitable rather than merely untidy. [16Czybik, Stefan; Horlboge, Micha; Rieck, Konrad (2023): "Lazy Gatekeepers: A Large-Scale Study on SPF Configuration in the Wild", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] rented about €30 of shared web hosting and could send mail passing SPF for 26,095 domains. [23Li, Ruixuan; Lu, Chaoyi; Liu, Baojun; Lin, Yanzhong; Pan, Qingfeng; Shao, Jun (2026): "CoordMail: Exploiting SMTP Timeout and Command Interaction to Coordinate Email Middleware for Convergence Amplification Attack", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] found that 77.89% of reflections off 10,079 exploitable bounce servers pass SPF or DKIM — the authentication is working exactly as specified and authenticating the attacker.

Six of the 31 papers got logs, headers or mailboxes from a real mail operator, and they are the only source on this page for base rates — what fraction of mail fails, why, and how concentrated the delivery path is. You almost certainly cannot reproduce these; read them so you know what your scan is a proxy for.

The two li rows are the same 32 million bounces and are directly comparable; the authentication row is not comparable to the 298 million total, and this page published it against the wrong denominator for several hours before catching it. That is the trap in its natural habitat: an operator paper reports some figures against the whole corpus of mail and others against the failures, in adjacent sentences.

The corpus spans 2015–2026 for this topic. It is unusually well-distributed for a corpus-derived page — 21 of the 31 papers are 2022 or later, so “what the literature did” and “what is current” are closer here than on most pages. Still, date them.

• Zone-file scanning rather than a top list. First appears in this population in 2023 and is in three papers by 2025 ([21Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2023): "You've Got Report: Measurement and Security Implications of DMARC Reporting", in: Proceedings of the USENIX Security Symposium. (Link)], [4Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2024): "SPF Beyond the Standard: Management and Operational Challenges in Practice and Practical Recommendations", in: Proceedings of the USENIX Security Symposium. (Link)], [17Ashiq, Md. Ishtiaq; Fiebig, Tobias; Chung, Taejoong (2025): "Unraveling the Complexities of MTA-STS Deployment and Management in Securing Email", in: Proceedings of the ACM Internet Measurement Conference. (DOI)]). It converts “the top N domains” into “every second-level domain in .com/.net/.org/.se” — 176 million in [4Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2024): "SPF Beyond the Standard: Management and Operational Challenges in Practice and Practical Recommendations", in: Proceedings of the USENIX Security Symposium. (Link)] — which removes the rank-window problem entirely. Access is through ICANN's Centralized Zone Data Service; Verisign now directs .com/.net requests there rather than running its own process.²⁾
• Measuring the receiver, not the sender. The inbound-validation probe of [4Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2024): "SPF Beyond the Standard: Management and Operational Challenges in Practice and Practical Recommendations", in: Proceedings of the USENIX Security Symposium. (Link)] and the sender-side MTA-STS test of [17Ashiq, Md. Ishtiaq; Fiebig, Tobias; Chung, Taejoong (2025): "Unraveling the Complexities of MTA-STS Deployment and Management in Securing Email", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] are the current frontier, and both are under-used.
• Shared infrastructure as the unit of analysis. [5Wang, Chuhan; Kuranaga, Yasuhiro; Wang, Yihang; Zhang, Mingming; Zheng, Linkai; Li, Xiang; Chen, Jianjun; Duan, Haixin; Lin, Yanzhong; Pan, Qingfeng (2024): "BreakSPF: How Shared Infrastructures Magnify SPF Vulnerabilities Across the Internet", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] (2024), [26Wang, Chuhan; Wang, Chenkai; Yang, Songyi; Liu, Sophia; Chen, Jianjun; Duan, Haixin; Wang, Gang (2025): "Email Spoofing with SMTP Smuggling: How the Shared Email Infrastructures Magnify this Vulnerability", in: Proceedings of the USENIX Security Symposium. (Link)] (SMTP smuggling, 2025) and [23Li, Ruixuan; Lu, Chaoyi; Liu, Baojun; Lin, Yanzhong; Pan, Qingfeng; Shao, Jun (2026): "CoordMail: Exploiting SMTP Timeout and Command Interaction to Coordinate Email Middleware for Convergence Amplification Attack", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] (2026) all ask what an attacker can do by renting a piece of infrastructure that thousands of domains have already authorised. This is the newest coherent line in the population and it is three papers old.
• Operator surveys alongside the scan. None before 2020; five by 2025, with 39, 74, 16, 95 and 117 respondents ([20Lee, Hyeonmin; Ashiq, Md. Ishtiaq; Müller, Moritz; Rijswijk-Deij, Roland van; Kwon, Taekyoung "Ted"; Chung, Taejoong (2022): "Under the Hood of DANE Mismanagement in SMTP", in: Proceedings of the USENIX Security Symposium. (Link)], [21Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2023): "You've Got Report: Measurement and Security Implications of DMARC Reporting", in: Proceedings of the USENIX Security Symposium. (Link)], [15Blechschmidt, Birk; Stock, Ben (2023): "Extended Hell(o): A Comprehensive Large-Scale Study on Email Confidentiality and Integrity Mechanisms in the Wild", in: Proceedings of the USENIX Security Symposium. (Link)], [4Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2024): "SPF Beyond the Standard: Management and Operational Challenges in Practice and Practical Recommendations", in: Proceedings of the USENIX Security Symposium. (Link)], [17Ashiq, Md. Ishtiaq; Fiebig, Tobias; Chung, Taejoong (2025): "Unraveling the Complexities of MTA-STS Deployment and Management in Securing Email", in: Proceedings of the ACM Internet Measurement Conference. (DOI)]). Recruitment is from MailOP, NANOG, DENOG, NLNOG and MESSEU in every case where it is stated — a specific, self-selecting, unusually competent population. Report it as such; it is not a sample of operators.
• Notification-and-rescan as a built-in second phase. [27Bennett, Nathaniel; Sowards, Rebekah; Deccio, Casey T. (2022): "SPFail: Discovering, Measuring, and Remediating Vulnerabilities in Email Sender Validation", in: Proceedings of the ACM Internet Measurement Conference. (DOI)], [16Czybik, Stefan; Horlboge, Micha; Rieck, Konrad (2023): "Lazy Gatekeepers: A Large-Scale Study on SPF Configuration in the Wild", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] and [15Blechschmidt, Birk; Stock, Ben (2023): "Extended Hell(o): A Comprehensive Large-Scale Study on Email Confidentiality and Integrity Mechanisms in the Wild", in: Proceedings of the USENIX Security Symposium. (Link)] all notify and remeasure. The effect sizes are small and worth knowing before you budget for one: [16Czybik, Stefan; Horlboge, Micha; Rieck, Konrad (2023): "Lazy Gatekeepers: A Large-Scale Study on SPF Configuration in the Wild", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] saw 6,931 SPF errors fixed two weeks after notification, a 3.28% fall in the total, and [27Bennett, Nathaniel; Sowards, Rebekah; Deccio, Casey T. (2022): "SPFail: Discovering, Measuring, and Remediating Vulnerabilities in Email Sender Validation", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] found just over 80% of the domains it could infer results for were still vulnerable four months on. Only [15Blechschmidt, Birk; Stock, Ben (2023): "Extended Hell(o): A Comprehensive Large-Scale Study on Email Confidentiality and Integrity Mechanisms in the Wild", in: Proceedings of the USENIX Security Symposium. (Link)] has a comparison arm: domains whose notification bounced remediated at 20.7% against 39.7% for domains that were reached (Fisher exact p = 7.8 × 10^-43). That arm is what makes the result more than a trend — but it is not a randomised control, and the authors say so themselves: “we cannot conclude a causal relation since the lack of deliverable emails may be a hidden variable which influences fix rates”. Undeliverable postmaster addresses are plausibly a proxy for an unattended domain. If you run a notification experiment, randomise.
• Client matrices. Still current — [28Tang, Ka Fun; Tu, Che Wei; Mak, Sui Ling Angela; Chau, Sze Yiu (2025): "A Multifaceted Study on the Use of TLS and Auto-detect in Email Ecosystems", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] (49 clients, 2025) and [22Wen, Shushang; Zhang, Yiming; Shen, Yuxiang; Li, Bingyu; Duan, Haixin; Lin, Jingqiang (2025): "Automatic Insecurity: Exploring Email Auto-configuration in the Wild", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] (29 clients, 2025) are recent — but they are a vulnerability census, not a prevalence measurement, and should not be written as one.

• A single DNS snapshot over Alexa, reported as a deployment rate. This is the 2015–2018 design and it is what a naive 2026 study reproduces. It survives only as one panel of a larger study.
• The Adobe 2013 breach address list as a popularity proxy for mail providers. Used by [3Foster, Ian D.; Larson, Jon; Masich, Max; Snoeren, Alex C.; Savage, Stefan; Levchenko, Kirill (2015): "Security by Any Other Name: On the Effectiveness of Provider Based Email Security", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] and [2Hu, Hang; Wang, Gang (2018): "End-to-End Measurements of Email Spoofing Attacks", in: Proceedings of the USENIX Security Symposium. (Link)] to rank providers by user count, and genuinely clever in 2015. It is now a thirteen-year-old snapshot of one company's users; five of the 31 papers still lean on it.
• “X% of domains publish a record” as the headline. It was the finding in 2015. It is background in 2026.

• BIMI is measured by nobody in these seven venues. A full-text probe over all 5,859 papers finds BIMI named in exactly 5, all of them in this population's 31, and all five are related-work sentences (“BIMI is built on DMARC and has not …”). Read by hand on 2026-09-09: zero measure it. [21Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2023): "You've Got Report: Measurement and Security Implications of DMARC Reporting", in: Proceedings of the USENIX Security Symposium. (Link)] points outside the corpus, to [29Yajima, Masanori; Chiba, Daiki; Yoneya, Yoshiro; Mori, Tatsuya (2023): "A First Look at Brand Indicators for Message Identification (BIMI)", in: Proceedings of the 24th International Conference on Passive and Active Measurement, pp. 479-495. Springer Nature Switzerland. (DOI)], for a 19%-of-Tranco DMARC figure — the one BIMI measurement anyone in this population cites, and it is at PAM, not here. SMTP REQUIRETLS (RFC 8689) is named in zero papers, corpus-wide, and a search of PAM, TMA, ANRW and arXiv on 2026-09-09 found no measurement of it anywhere. So: BIMI has been measured once, in 2022, outside these venues; REQUIRETLS never.
• TLS-RPT is named in 3 of the 31, and only one of them measures it. [21Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2023): "You've Got Report: Measurement and Security Implications of DMARC Reporting", in: Proceedings of the USENIX Security Symposium. (Link)] does three things with it: exploits it (a crafted TLS-RPT record is half of its 1,460× reflection attack), asks its surveyed operators whether they send reports, and measures provider support directly — its Table 4 finds 2 of 8 email hosting providers support TLS-RPT reporting, and “no open-source software” at all. What nobody has done is scan a domain population for _smtp._tls records, the way four papers here scan for SPF. Provider-granularity and population-granularity are different claims and this is a clean example of the difference.
• The corpus stops at the venues it stops at. Long-running national measurement programmes — SIDN Labs' .nl statistics, the Dutch government's internet.nl-based compliance survey — publish deployment series these seven venues do not, and are cited below rather than in the tables above, because they are not part of the population this page counts.

The corpus cannot know any of this: the newest paper in it went to press before most of it happened. Every item here was fetched on 2026-09-09, not recalled.

• DMARC is no longer RFC 7489. It was republished on the standards track in May 2026 as RFC 9989 (protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). RFC 9989 states “Obsoletes: 7489, 9091” and “Category: Standards Track” on its title page.³⁾ 18 of the 31 papers here cite RFC 7489 and none could have cited 9989; the other 13 either name DMARC without the RFC or, in 7 cases, never mention DMARC at all. If you are writing now, cite 9989.
• The pct= tag is gone. RFC 9989 §A.6, “Removal of the 'pct' Tag”: “Operational experience showed that the 'pct' tag was usually not accurately applied … This version of the DMARC mechanism, therefore, introduces the 't' tag as shorthand for 'testing'”. The DMARC tag registry now marks pct historic. A 2026 parser that treats pct=0 as a valid partial-rollout signal is parsing a dead tag; a 2026 measurement that reports pct distributions is measuring a legacy artefact, which is a legitimate thing to do provided you say so.
• ARC (RFC 8617) is still Experimental, and an IETF DMARC working-group document is moving it to Historic.⁴⁾ [8Wang, Chenkai; Wang, Gang (2022): "Revisiting Email Forwarding Security under the Authenticated Received Chain Protocol", in: Proceedings of the ACM Web Conference. (DOI)] is the only ARC measurement in this population.
• A DKIM revision is in progress. draft-ietf-dkim-dkim2-spec is an Active Internet-Draft in the rechartered IETF dkim working group, last revised 2026-08-28. The driver is DKIM replay — the weakness [30Chen, Jianjun; Paxson, Vern; Jiang, Jian (2020): "Composition Kills: A Case Study of Email Sender Authentication", in: Proceedings of the USENIX Security Symposium. (Link)] demonstrated in 2020 with the l= tag and message re-signing.
• BIMI is still not an RFC. draft-brand-indicators-for-message-identification is an Active Internet-Draft with no working-group ownership, last updated 2026-05-01. Anything describing BIMI as a standard is wrong.
• The three largest consumer mailbox providers now mandate authentication, on different terms. Google has required SPF, DKIM and DMARC of senders above 5,000 messages a day since 1 February 2024, and its page now adds that “Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic. Messages that fail to meet the email sender requirements will experience disruptions, including temporary and permanent rejections.” Yahoo mirrors the same requirements and the same February 2024 date but never states a numeric volume threshold anywhere on its senders page. Microsoft's Outlook.com requirement took effect 5 May 2025 above 5,000 messages a day, and as of today Microsoft still describes outright rejection as pending a future date rather than in force.⁵⁾ This matters to your sampling: since 2024 the incentive to publish a DMARC record depends on how much mail a domain sends to Gmail, which is not a variable any of the 31 papers controls for. A post-2024 adoption series that does not separate bulk senders from everyone else is confounded by it.

Checked 2026-09-09. Version and date come from the project's own release feed, not from memory.

Rejected as citable sources of deployment statistics, after checking each: dmarcian, Valimail (acquired by DigiCert in September 2025), EasyDMARC, Red Sift OnDMARC, PowerDMARC, DuoCircle and dmarcreport.com. All are commercially alive; none publishes a deployment figure with a stated population and method. Valimail's “2026 State of DMARC Report” puts its methodology behind a lead-capture form. A vendor blog post with a percentage and no denominator is not a citation, and this literature is unusually well supplied with them.

Usable instead, with stated methods:

• SIDN Labs, stats.sidnlabs.nl/en/mail.html — a full census of .nl via OpenINTEL, updated roughly monthly. At the 2026-09-01 data point, 84.24% of .nl domains with MX publish DMARC, and 37.24% publish a TLSA record for mail. Sanity-check the DANE figure before citing it: it moved from 26.57% to 37.24% in a single month, which is either a real registrar-driven jump or a methodology change, and the page does not say which.
• Forum Standaardisatie, Meting Informatieveiligheidstandaarden overheid begin 2026 (12 May 2026) — a bulk internet.nl test over Dutch government domain registers (n = 12,116 / 3,038 depending on the standard): DKIM 66%, DMARC at quarantine or reject 86%, strict SPF 69%, STARTTLS 92%, DANE 56%.
• Both are national censuses of unusually well-governed populations. They are the ceiling, not the world.

This topic has a harder ethics profile than most web measurement, because half its instruments touch third-party production infrastructure and one of them delivers a forged message to a real mailbox. What the 31 papers report about themselves:

• 12 of 31 mention no ethics review at all. Of the other 19: 6 discuss the question and state that no review was sought or required, 5 report an approval, 4 say review was not required, 2 sought one and do not say what came back, and 2 report an exemption. That is 38.7% silent against 64.2% corpus-wide (of the 4,965 papers carrying an ethics object) — so this population is better than the corpus, not worse, and 5 report an approval against 20.1% corpus-wide. n = 31, so read neither gap as a difference. Better than a low bar is still not good enough for an instrument that delivers forged mail to a live provider.
• 19 of 31 notified affected parties, 6 partially, 2 not, 3 do not say, and 1 is recorded not-applicable. Disclosure is the norm in this population — usefully so, since these are protocol and implementation flaws with named vendors.
• 20 of 31 report a public artifact and 18 give a code URL, including several long-lived project sites (dane-study.github.io, spf-measurement.github.io, mta-sts.netsecurelab.org, github.com/chenjj/espoofer). By the standards of this corpus that is good practice.

Four decisions you will have to make and defend:

1. Spoofed mail is delivered to a real inbox. Every account-based delivery paper sends messages that fail authentication into a live provider. Send only to accounts you control, register them yourself, and say how many messages you sent and over what period. [2Hu, Hang; Wang, Gang (2018): "End-to-End Measurements of Email Spoofing Attacks", in: Proceedings of the USENIX Security Symposium. (Link)] additionally ran a deceptive user study with 488 MTurk participants; if you do that, the bar is ethics, not a footnote.
2. Probing inbound validation means completing an SMTP conversation with a stranger's server. [4Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2024): "SPF Beyond the Standard: Management and Operational Challenges in Practice and Practical Recommendations", in: Proceedings of the USENIX Security Symposium. (Link)] stops before DATA precisely so that no message is ever accepted, and says so. That design choice is the ethical argument; make it explicit.
3. Notification is a research intervention on twenty thousand unwitting operators. [17Ashiq, Md. Ishtiaq; Fiebig, Tobias; Chung, Taejoong (2025): "Unraveling the Complexities of MTA-STS Deployment and Management in Securing Email", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] mailed the postmaster address of all 20,144 misconfigured domains and had over 5,000 messages bounce. See notifying_websites for what the response rates actually look like and how to phrase it.
4. Amplification and reflection research is live-fire. [23Li, Ruixuan; Lu, Chaoyi; Liu, Baojun; Lin, Yanzhong; Pan, Qingfeng; Shao, Jun (2026): "CoordMail: Exploiting SMTP Timeout and Command Interaction to Coordinate Email Middleware for Convergence Amplification Attack", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] coordinates real bounce servers to a 3,801× bandwidth concentration. If your target is a DoS primitive, the disclosure and rate-limiting plan is part of the method section, not an afterthought.

A reviewer who works in this area will look for these.

• The frame, versioned. Which list, which day, which version. A Tranco list ID, a zone-file date, a passive-DNS window. “The Alexa top 1M” is not a frame in 2026.
• Whether you filtered to domains with an MX record, and how many that removed. State the numerator and both candidate denominators.
• The resolver and where it sat. Recursive or authoritative, your own or the provider's, and from what network. An SPF record's meaning is the transitive closure of other people's DNS answers — which is exactly why [4Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2024): "SPF Beyond the Standard: Management and Operational Challenges in Practice and Practical Recommendations", in: Proceedings of the USENIX Security Symposium. (Link)] finds 6.5% of SPF-publishing domains blow the 10-lookup limit — so two runs behind different resolvers can disagree about the same record.
• For DKIM: the selector list and its provenance. And the words “lower bound”.
• For SPF: whether you recursively expanded include and redirect, whether you counted the 10-lookup limit, and what you did with PermError. [16Czybik, Stefan; Horlboge, Micha; Rieck, Konrad (2023): "Lazy Gatekeepers: A Large-Scale Study on SPF Configuration in the Wild", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] found 34.7% of SPF-publishing domains authorise more than 100,000 IPv4 addresses and [5Wang, Chuhan; Kuranaga, Yasuhiro; Wang, Yihang; Zhang, Mingming; Zheng, Linkai; Li, Xiang; Chen, Jianjun; Duan, Haixin; Lin, Yanzhong; Pan, Qingfeng (2024): "BreakSPF: How Shared Infrastructures Magnify SPF Vulnerabilities Across the Internet", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] found 51.7% cover more than 65,536 — both figures exist only because the record was expanded, not just parsed.
• The policy distribution, not just the presence rate. p=none against quarantine against reject; -all against ~all against ?all. If you report one number for “DMARC deployment”, say which policies it counts.
• For a delivery test: the full outcome ladder. Rejected at SMTP / spam-foldered / inbox / inbox with a warning, and separately what the interface showed. Not a binary.
• Sender-side or receiver-side. Say which one your number is about, in the sentence with the number.
• Snapshot or series, and the cadence. DANE and MTA-STS misconfiguration is largely a rollover problem — [20Lee, Hyeonmin; Ashiq, Md. Ishtiaq; Müller, Moritz; Rijswijk-Deij, Roland van; Kwon, Taekyoung "Ted"; Chung, Taejoong (2022): "Under the Hood of DANE Mismanagement in SMTP", in: Proceedings of the USENIX Security Symposium. (Link)] needed hourly snapshots to see that, of the 2,569 DANE SMTP servers whose certificates were ever valid, more than 87% in each management category botch at least one key rollover — and a single snapshot cannot see it at all.
• What you did to the servers you probed, and your opt-out. See ethics.
• The software versions in your own testbed. Postfix, Exim, libspf2, OpenDKIM: name them and pin them, because the interesting results in this literature are usually one implementation disagreeing with another.

The 31 papers are the INFRA verdict of scripts/msg_fold.mjs, the published hand map behind email_tracking (2026-09-02). That map screened a 354-paper candidate pool built from message-channel vocabulary and split it by what the paper measures: tracking inside a message, the address as an identifier, marketing mail, spam, SMS abuse, the mailbox as an instrument — and this page's slice, the machinery that carries the message. Each of the 31 carries its one-line reason in the map. The population is not re-derived here: this page's report script imports the map and throws if the INFRA slice is no longer 31 papers, so changing the map breaks the report rather than silently moving the denominator.

31 of 5,859 is not a rate. It is a hand-mapped topical slice, and the only honest denominator for it is the candidate pool it came out of.

Generated from the report script's own citekey map, oldest first. The one-line description is the reason recorded in msg_fold.mjs when the paper was admitted.

2025–2026 are provisional — CCS 2026 and IMC 2026 have not been held and two other 2026 venue-years are under-represented by construction (see corpus), so read the 2026 cell as a floor. 28 of 31 are 2018 or later; 21 are 2022 or later.

By venue: USENIX Security 16, IMC 7, NDSS 4, and one each from CCS, IEEE S&P, TheWebConf and PETS. This is a USENIX-and-IMC topic: 23 of the 31 are in those two venues.

The authorship is more concentrated still, and this is the caveat that matters most for reading the tables above as if they described a field. Across 111 distinct authors on the 31 papers:

• Five people are first author of more than one, between them covering 13 of the 31: Chuhan Wang (3), Md. Ishtiaq Ashiq (3), Ruixuan Li (3), Damian Poddebniak (2), Hyeonmin Lee (2).
• Twelve people appear on four or more of the 31. Haixin Duan is on 7, Qingfeng Pan on 6, and Sebastian Schinzel, Taejoong Chung, Jianjun Chen, Baojun Liu and Yanzhong Lin on 5 each.

So the instrument counts above are partly a fact about the field and partly a fact about the half-dozen groups that constitute it. The client-matrix papers are largely one group; the DANE and MTA-STS papers are largely another; the shared-infrastructure line is largely a third. That is normal for a subfield this size, and it is also why “the field has moved to operator surveys” should be read as “three groups have”.

Mechanism, hand-mapped from each paper's own results section. Multi-valued; denominator 31 papers.

Sampling frames, folded from population[].sourceList and paper-counted: hand-built list 13, Tranco 9, Alexa 7, the Adobe 2013 breach address list 5, operator logs 5, passive DNS or OpenINTEL 3, university lists 3, TLD zone files 3, Enron corpus 2, another top list (Majestic / Umbrella / DomCop) 2, IPv4 address space 1. 43 distinct strings did not fold and are printed in full on email_authentication rather than dropped.

• 29 of 31 report descriptive statistics only. Two run a hypothesis test ([2Hu, Hang; Wang, Gang (2018): "End-to-End Measurements of Email Spoofing Attacks", in: Proceedings of the USENIX Security Symposium. (Link)], [15Blechschmidt, Birk; Stock, Ben (2023): "Extended Hell(o): A Comprehensive Large-Scale Study on Email Confidentiality and Integrity Mechanisms in the Wild", in: Proceedings of the USENIX Security Symposium. (Link)]). Exactly one paper runs anything else, and it runs three things: [31Szurdi, Janos; Christin, Nicolas (2017): "Email Typosquatting", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] fits a regression (R² = 0.74), reports a correlation, and cross-validates (leave-one-out, R² drops to 0.63). One paper in eleven years accounts for every regression, every correlation and every resampling result in this population. For a literature whose central claims are comparisons — notified against control, this provider against that one, this year against last — that is thin. If your result is a difference, test it; see hypothesis_testing.
• 19 of 31 coded something by hand and the extraction records an inter-rater agreement metric for none of them. Zero of nineteen — but read that as an extraction result: the 19 papers were not re-read by hand to confirm the absence is theirs and not the extractor's, and it is the least-verified number on this page. Even discounted, the direction is not in doubt: vulnerability labelling in a client matrix is a coding task, and “we manually analysed the identified behaviours” is not a method. See interrater_agreement.
• 12 of 31 mention no ethics review at all and a further 4 record it as not required, against instruments that send forged mail and probe strangers' servers.
• Eight of the 31 recruited people; the five operator surveys carry n of 39, 74, 16, 95 and 117. The extraction records a recruitment channel for only three of the five — but that undercounts by one: [21Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2023): "You've Got Report: Measurement and Security Implications of DMARC Reporting", in: Proceedings of the USENIX Security Symposium. (Link)] names MailOP, NANOG and MESSEU in its own text and the extractor recorded not-stated. Four of five, and the fifth is [15Blechschmidt, Birk; Stock, Ben (2023): "Extended Hell(o): A Comprehensive Large-Scale Study on Email Confidentiality and Integrity Mechanisms in the Wild", in: Proceedings of the USENIX Security Symposium. (Link)], whose 16 respondents are operators who replied to a notification email rather than a recruited sample at all.

These are near-misses the recall probe surfaced. Each carries a different verdict in msg_fold.mjs, and where the boundary is genuinely arguable the table says so.

A widened full-text probe over all 5,859 papers — admitting any paper with four or more mentions summed across SPF, DKIM, DMARC, DANE/TLSA, MTA-STS, BIMI and ARC, or four or more across STARTTLS and S/MIME, or fifteen SMTP mentions with at least two mechanism mentions — admits 77 papers and adds nothing to the population: the extra hits are DANE-for-HTTPS, DNSSEC registrar studies, ALPACA, DROWN and a DNS toolkit paper. The full list, read by hand, is on the provenance page.

Every count above is a count of papers, never of extraction tuples, with its denominator named in the same sentence or table cell. Free-text fields were folded before aggregating and the unmapped residue is published rather than dropped. The report script that produces every figure on this page is scripts/report_email_authentication.mjs; it hand-keys the mechanism map, the instrument map and all 55 published figures, and it fails if any of those maps stops covering all 31 papers.

Two limitations specific to this page:

• Quote verification hits the two-column problem. All 55 figures above were checked against paper.cols.txt; 60 quote fragments were needed to do it. Five figures carry a second fragment, and three of those five are genuine splices — a sentence interrupted by a table row, a figure caption or a column break, and unlocatable as one string in any of the three available renderings. The other two second fragments are independent corroborating quotations, not split sentences. At least one figure stated in the prose rather than in a table (the DANE rollover figure) sits on a spliced sentence too, so three is a floor for this page, not a total. Across the 31 papers' 206 extracted evidence quotes, 130 locate contiguously and 76 do not; a hand-read sample of the 76 found real sentences broken by page furniture, plus one case where the extractor's quote merges two adjacent sentences. Details and the sample on the provenance page.
• The mechanism and instrument maps are hand maps, not extraction fields. The schema has no field for “which deployed mail mechanism is this paper's object”, so both tables were made by reading each of the 31 results sections. They are reproducible in the sense that they are written down in the script and asserted complete against the population; they are not independent of the judgement that made them, and email_authentication names the four calls inside them that could reasonably have gone the other way.

The full query log, the folds, the residue, the quote spot-checks, the external sources that were rejected and the reviewer findings are on email_authentication. Corpus-level caveats — how the 5,859 were selected, why 2025–2026 are provisional — are on corpus.

• email_tracking — the other half of the message-channel literature: tracking pixels, the address as an identifier, marketing mail and spam. It scopes this page out and links here.
• phishing — mail as an attack vector, and the feeds that label it.
• tls_certificates — the web PKI, CT logs and the scanning instruments this page borrows.
• internet_scanning — ZMap, ZGrab and the ethics and rate limits of internet-wide probing. Queued on roadmap, not yet written; the link is red on purpose.
• website_selection — Tranco, zone files, and why a top list is not a sample.
• longitudinal — snapshot cadence, which is what DANE and MTA-STS rollover measurement lives or dies by.
• notifying_websites — notification-and-rescan, and what response rates actually look like.
• ethics — active probing, disclosure, and the review question 12 of these 31 papers did not answer.
• email_authentication — the query log behind this page.

[1]

Durumeric, Zakir; Adrian, David; Mirian, Ariana; Kasten, James; Bursztein, Elie; Lidzborski, Nicolas; Thomas, Kurt; Eranti, Vijay; Bailey, Michael D.; Halderman, J. Alex (2015): "Neither Snow Nor Rain Nor MITM...: An Empirical Analysis of Email Delivery Security", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[2]

Hu, Hang; Wang, Gang (2018): "End-to-End Measurements of Email Spoofing Attacks", in: Proceedings of the USENIX Security Symposium. (Link)

[3]

Foster, Ian D.; Larson, Jon; Masich, Max; Snoeren, Alex C.; Savage, Stefan; Levchenko, Kirill (2015): "Security by Any Other Name: On the Effectiveness of Provider Based Email Security", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[4]

Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2024): "SPF Beyond the Standard: Management and Operational Challenges in Practice and Practical Recommendations", in: Proceedings of the USENIX Security Symposium. (Link)

[5]

Wang, Chuhan; Kuranaga, Yasuhiro; Wang, Yihang; Zhang, Mingming; Zheng, Linkai; Li, Xiang; Chen, Jianjun; Duan, Haixin; Lin, Yanzhong; Pan, Qingfeng (2024): "BreakSPF: How Shared Infrastructures Magnify SPF Vulnerabilities Across the Internet", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[6]

Poddebniak, Damian; Dresen, Christian; Müller, Jens; Ising, Fabian; Schinzel, Sebastian; Friedberger, Simon; Somorovsky, Juraj; Schwenk, Jörg (2018): "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels", in: Proceedings of the USENIX Security Symposium. (Link)

[7]

Öndarö, Gurur; Kaspereit, Jonas; Umezulike, Samson; Saatjohann, Christoph; Ising, Fabian; Schinzel, Sebastian (2025): "S/MINE: Collecting and Analyzing S/MIME Certificates at Scale", in: Proceedings of the USENIX Security Symposium. (Link)

[8]

Wang, Chenkai; Wang, Gang (2022): "Revisiting Email Forwarding Security under the Authenticated Received Chain Protocol", in: Proceedings of the ACM Web Conference. (DOI)

[9]

Müller, Jens; Brinkmann, Marcus; Poddebniak, Damian; Böck, Hanno; Schinzel, Sebastian; Somorovsky, Juraj; Schwenk, Jörg (2019): "“Johnny, you are fired!” – Spoofing OpenPGP and S/MIME Signatures in Emails", in: Proceedings of the USENIX Security Symposium. (Link)

[10]

Stransky, Christian; Wiese, Oliver; Roth, Volker; Acar, Yasemin; Fahl, Sascha (2022): "27 Years and 81 Million Opportunities Later: Investigating the Use of Email Encryption for an Entire University", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[11]

Ising, Fabian; Poddebniak, Damian; Kappert, Tobias; Saatjohann, Christoph; Schinzel, Sebastian (2023): "Content-Type: multipart/oracle - Tapping into Format Oracles in Email End-to-End Encryption", in: Proceedings of the USENIX Security Symposium. (Link)

[12]

Poddebniak, Damian; Ising, Fabian; Böck, Hanno; Schinzel, Sebastian (2021): "Why TLS is better without STARTTLS: A Security Analysis of STARTTLS in the Email Context", in: Proceedings of the USENIX Security Symposium. (Link)

[13]

Wang, Chuhan; Shen, Kaiwen; Guo, Minglei; Zhao, Yuxuan; Zhang, Mingming; Chen, Jianjun; Liu, Baojun; Zheng, Xiaofeng; Duan, Haixin; Lin, Yanzhong; Pan, Qingfeng (2022): "A Large-scale and Longitudinal Measurement Study of DKIM Deployment", in: Proceedings of the USENIX Security Symposium. (Link)

[14]

Lee, Hyeonmin; Girish, Aniketh; Rijswijk-Deij, Roland van; Kwon, Taekyoung "Ted"; Chung, Taejoong (2020): "A Longitudinal and Comprehensive Study of the DANE Ecosystem in Email", in: Proceedings of the USENIX Security Symposium. (Link)

[15]

Blechschmidt, Birk; Stock, Ben (2023): "Extended Hell(o): A Comprehensive Large-Scale Study on Email Confidentiality and Integrity Mechanisms in the Wild", in: Proceedings of the USENIX Security Symposium. (Link)

[16]

Czybik, Stefan; Horlboge, Micha; Rieck, Konrad (2023): "Lazy Gatekeepers: A Large-Scale Study on SPF Configuration in the Wild", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[17]

Ashiq, Md. Ishtiaq; Fiebig, Tobias; Chung, Taejoong (2025): "Unraveling the Complexities of MTA-STS Deployment and Management in Securing Email", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[18]

Le Pochat, Victor; Van Goethem, Tom; Tajalizadehkhoob, Samaneh; Korczy´nski, Maciej; Joosen, Wouter (2019): "Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation", in: Proceedings of the 26th Annual Network and Distributed System Security Symposium. (DOI)

[19]

Shen, Kaiwen; Wang, Chuhan; Guo, Minglei; Zheng, Xiaofeng; Lu, Chaoyi; Liu, Baojun; Zhao, Yuxuan; Hao, Shuang; Duan, Haixin; Pan, Qingfeng; Yang, Min (2021): "Weak Links in Authentication Chains: A Large-scale Analysis of Email Sender Spoofing Attacks", in: Proceedings of the USENIX Security Symposium. (Link)

[20]

Lee, Hyeonmin; Ashiq, Md. Ishtiaq; Müller, Moritz; Rijswijk-Deij, Roland van; Kwon, Taekyoung "Ted"; Chung, Taejoong (2022): "Under the Hood of DANE Mismanagement in SMTP", in: Proceedings of the USENIX Security Symposium. (Link)

[21]

Ashiq, Md. Ishtiaq; Li, Weitong; Fiebig, Tobias; Chung, Taejoong (2023): "You've Got Report: Measurement and Security Implications of DMARC Reporting", in: Proceedings of the USENIX Security Symposium. (Link)

[22]

Wen, Shushang; Zhang, Yiming; Shen, Yuxiang; Li, Bingyu; Duan, Haixin; Lin, Jingqiang (2025): "Automatic Insecurity: Exploring Email Auto-configuration in the Wild", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[23]

Li, Ruixuan; Lu, Chaoyi; Liu, Baojun; Lin, Yanzhong; Pan, Qingfeng; Shao, Jun (2026): "CoordMail: Exploiting SMTP Timeout and Command Interaction to Coordinate Email Middleware for Convergence Amplification Attack", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[24]

Li, Ruixuan; Xiao, Shaodong; Liu, Baojun; Lin, Yanzhong; Duan, Haixin; Pan, Qingfeng; Chen, Jianjun; Zhang, Jia; Liu, Ximeng; Lu, Xiuqi; Shao, Jun (2024): "Bounce in the Wild: A Deep Dive into Email Delivery Failures from a Large Email Service Provider", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[25]

Li, Ruixuan; Lu, Chaoyi; Liu, Baojun; Lin, Yanzhong; Duan, Haixin; Pan, Qingfeng; Shao, Jun (2025): "Understanding and Characterizing Intermediate Paths of Email Delivery: The Hidden Dependencies", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[26]

Wang, Chuhan; Wang, Chenkai; Yang, Songyi; Liu, Sophia; Chen, Jianjun; Duan, Haixin; Wang, Gang (2025): "Email Spoofing with SMTP Smuggling: How the Shared Email Infrastructures Magnify this Vulnerability", in: Proceedings of the USENIX Security Symposium. (Link)

[27]

Bennett, Nathaniel; Sowards, Rebekah; Deccio, Casey T. (2022): "SPFail: Discovering, Measuring, and Remediating Vulnerabilities in Email Sender Validation", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[28]

Tang, Ka Fun; Tu, Che Wei; Mak, Sui Ling Angela; Chau, Sze Yiu (2025): "A Multifaceted Study on the Use of TLS and Auto-detect in Email Ecosystems", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[29]

Yajima, Masanori; Chiba, Daiki; Yoneya, Yoshiro; Mori, Tatsuya (2023): "A First Look at Brand Indicators for Message Identification (BIMI)", in: Proceedings of the 24th International Conference on Passive and Active Measurement, pp. 479-495. Springer Nature Switzerland. (DOI)

[30]

Chen, Jianjun; Paxson, Vern; Jiang, Jian (2020): "Composition Kills: A Case Study of Email Sender Authentication", in: Proceedings of the USENIX Security Symposium. (Link)

[31]

Szurdi, Janos; Christin, Nicolas (2017): "Email Typosquatting", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[32]

Fiebig, Tobias; Gürses, Seda; Gañán, Carlos H.; Kotkamp, Erna; Kuipers, Fernando; Lindorfer, Martina; Prisse, Menghua; Sari, Taritha (2023): "Heads in the Clouds? Measuring Universities’ Migration to Public Clouds: Implications for Privacy & Academic Freedom", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[33]

Ma, Jinrui; Chen, Lutong; Xue, Kaiping; Luo, Bo; Huang, Xuanbo; Ai, Mingrui; Zhang, Huanjie; Wei, David S.L.; Zhuang, Yan (2024): "FakeBehalf: Imperceptible Email Spoofing Attacks against the Delegation Mechanism in Email Systems", in: Proceedings of the USENIX Security Symposium. (Link)

[34]

Rao, Sumanth; Liu, Enze; Ho, Grant; Voelker, Geoffrey M.; Savage, Stefan (2024): "Unfiltered: Measuring Cloud-based Email Filtering Bypasses", in: Proceedings of the ACM Web Conference. (DOI)

[35]

Li, Ruixuan; Lu, Chaoyi; Liu, Baojun; Zhang, Yunyi; Hong, Geng; Duan, Haixin; Lin, Yanzhong; Pan, Qingfeng; Yang, Min; Shao, Jun (2025): "HADES Attack: Understanding and Evaluating Manipulation Risks of Email Blocklists", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[36]

Wu, Mengying; Hong, Geng; Chen, Jiatao; Liu, Baojun; Liu, Mingxuan; Yang, Min (2026): "One Email, Many Faces: A Deep Dive into Identity Confusion in Email Aliases", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[37]

Zhang, Jiahe; Chen, Jianjun; Wang, Qi; Zhang, Hangyu; Wang, Chuhan; Zhuge, Jianwei; Duan, Haixin (2024): "Inbox Invasion: Exploiting MIME Ambiguities to Evade Email Attachment Detectors", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[38]

Jeitner, Philipp; Shulman, Haya (2021): "Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS", in: Proceedings of the USENIX Security Symposium. (Link)