Email Infrastructure Threat Taxonomy

Email Infrastructure Threat Taxonomy: the path a message takes through the nine layers of the email stack.

Taxonomies › Email infrastructure

This is the reference for the Elevation of Email Flow card game: every card’s threat, the mitigation principle a sound design follows, design measures, and mappings to STRIDE, CAPEC and CWE.

Email infrastructure is the machinery that delivers a message: the SMTP conversation, sender authentication, DNS, MIME parsing, the delivery pipeline, the content scanners, the stores and the clients. This taxonomy catalogues what can go wrong in it: 117 threats across nine layers of the email stack, plus eight structural hazards, each with the principle a sound design follows and concrete measures that put it into practice.

Every entry is one of the game’s cards, written out so that it can also be used without the game, and the taxonomy card in the game’s box links here with a QR code. Why the taxonomy exists, and what the existing frameworks miss, is in The Unmodeled Attack Surface.

The layers

Overview of the layers and the structural hazards, with each one's prefix, number of entries and scope. Each layer is linked in the list below.
Diagram of a mail flow from sending MTA to a person, with the nine layers of the taxonomy marked where they sit: SMTP on each hop, the delivery pipeline as the span of hops, authentication and content scanners as inspection points, MIME as the message itself, client protocols and the human-facing layer at the mailbox end, operations and storage as a plane of copies below, DNS underneath everything, and the structural hazards as a band across the top.
The nine layers as positions in a real mail flow, with the structural hazards cutting across all of them.

What an entry contains

  • A name, short enough to say in a design review.
  • A threat, stated as a property of a component or a design decision. Not “an attacker could”, but “the platform does”.
  • A mitigation principle: what a sound design does, stated so that different designs can satisfy it in different ways.
  • Design measures: two to four concrete ways of satisfying the principle. They are examples of what works, not the only acceptable answers. The format is deliberate. A threat on its own is an accusation, and a list of measures on its own is a checklist that fits one architecture and no other. The principle sits between them: it says what must be true, and the measures show what that looks like in practice. Against a real design, each entry produces a finding, or a one-line “no exposure” with the reason, which is worth writing down too.

Each entry carries a reference such as DP·J or T2: the layer prefix plus a playing-card rank, from Ace down to 2, or T1 to T8 for the structural hazards. The taxonomy is the reference for the card game Elevation of Email Flow: each entry is one of its cards, and the two share one set of references. The reference is a stable identifier, not a severity. In the game the ranks follow severity, because play is trick-based; here a reference only names an entry, and it stays the same as the taxonomy grows.

How to use it

  1. Draw the mail flow: every hop, scanner, store and client a message touches, with the trust boundaries marked.
  2. Take one layer and walk every entry in it against each element it applies to.
  3. For each entry, ask whether the design satisfies the principle. Write down a finding, or “no exposure” and the design decision that defeats it.
  4. Where there is a finding, start from the measures given and adapt them to your architecture. They are the shape of a fix, not a prescription.
  5. Finish with the structural hazards, played against the design as a whole. They usually explain several findings at once and point to an architectural change, not a patch per finding. Note to platform builders: start with the delivery pipeline. Every other layer assumes the message actually passed the controls, and that is the assumption to test first.

Each layer page shows its entries as a table graphic. The downloads carry the same content as text that can be searched, filtered and copied.

Where layers touch

Some layers touch, and it helps to know which side of the line an entry sits on:

  • Authentication and DNS: DNS covers who can control or falsify an answer. Authentication covers what a genuine answer can be made to mean.
  • SMTP and delivery pipeline: SMTP is a single hop’s conversation. The pipeline is the composition of hops.
  • MIME and delivery pipeline: MIME is how a message is interpreted. The pipeline is whether and when it is inspected.
  • Delivery pipeline and content scanners: the pipeline decides what to do with a scanner’s limits and verdicts. The scanner layer asks whether the inspection itself holds up.
  • Tenancy: Tenant Confusion (DP·7), Cross-Tenant Identity (AU·K) and Shared Reputation Poisoning (SM·8) each cover a different face of shared infrastructure (configuration, identity, reputation). Shared Infrastructure, Shared Fate (T2) is the structural hazard behind all three.
  • Operations and the other layers: delivery pipeline, client protocols and DNS each cover a corner of operations (admin routing changes in DP·2, mailbox state in CP·10, dangling records in DN·K). Operations and storage covers the stores and tooling around the message path: the copies, the credentials and the people with access.
Three hops in a mail path. The edge MTA verifies the signature on version 1 of a message, the gateway rewrites it and scans version 2, the client re-parses and renders version 3. Four consequences are listed with the taxonomy entries they map to.
Three controls, three versions of one message. Each did its job; the attack lives in the differences.

Scope and origin

The taxonomy does not cover social engineering, phishing lures or the human decisions that make email such a successful attack vector. Those threats are real, well documented and served by existing frameworks. It covers the infrastructure: the components, protocols and sequencing contracts that deliver the message. That layer had no dedicated taxonomy.

It started as a game. I designed Elevation of Email Flow, a threat modeling card game, because I saw a gap in the games we already have: they cover web applications, cloud, privacy and more, but none of them covers email infrastructure. The deck came first, and this taxonomy is its reference: each card’s threat became an entry, each card’s suit became a layer, and the mitigation principle and measures were written to answer the questions the card asks. This taxonomy is the game’s content, restated so that it can be used without the game.

I want to be clear about one thing: it is not that these issues did not exist. They were already known, publicly disclosed in real systems. SMTP smuggling, EFAIL, the composition attacks on sender authentication and the large-scale spoofing studies are well-known examples; the sources below point to the original disclosures. What was missing was the translation. Each issue had to be restated as a threat that a designer can test their own system against, and the whole lot collated into a single resource. That is the contribution here: the translation and the collection, not the discovery.

STRIDE, CAPEC and CWE

Every entry is mapped to STRIDE and to CAPEC 3.9. STRIDE fits 75 of the 125 entries cleanly and 50 only loosely. CAPEC has a pattern that describes 31 directly, only a generic parent for 65, and nothing for 29. What the mapping shows is in Mapping the Email Threat Taxonomy to STRIDE, CAPEC and CWE. Every entry is also mapped to CWE 4.20, the catalogue of software weaknesses: a CWE weakness names the flaw directly for 68 entries, only a broader weakness applies to 51, and CWE has nothing for 6. Each layer page gives its own figures and its mapping table, entry by entry; the Excel, SKOS and STIX downloads carry every mapping as text.

Downloads

DownloadFormatWhat it is for
PDFA4 landscape, a section per layer, with each entry’s STRIDE, CAPEC and CWE mappingReading and printing. Also the text version of the tables on these pages.
ExcelWorkbook, one layer per sheetFiltering, sorting, copying entries into a threat model, tracking findings.
SKOS (JSON-LD)W3C SKOS concept schemeLinked data: the hierarchy, references, mitigations, and links to STRIDE, CAPEC and CWE.
STIX 2.1STIX 2.1 bundleSecurity tooling: an attack pattern and a course of action per entry, grouped by layer, with CAPEC and CWE references.

All four carry the licence. The STIX bundle’s extra fields are described by this JSON Schema.

Licence

© 2026 Jonathan Brett Crawley. This taxonomy is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International licence (CC BY-NC-ND 4.0), with the additional permissions below. You can share the whole taxonomy freely for non-commercial purposes, unchanged and with credit.

UsePermission needed?
Sharing the whole taxonomy non-commercially (OWASP, universities, conferences, individuals)No
Threat modeling with it, including for paying clientsNo
Internal use and training inside any organisationNo
Quoting entries, with credit, in paid courses, reports and talksNo
Shipping the taxonomy in a product: a tool’s built-in library, a printed deck, a reprint for saleYes, ask me

Additional permissions. In addition to the rights the licence gives, and whether or not the use is commercial, the copyright holder grants you permission to:

  • Use the taxonomy to threat model systems you build, operate or assess, including for paying clients;
  • Use it internally, and for training, inside any organisation;
  • Quote individual entries, with credit, in paid courses, reports, findings and talks. Any other commercial use, including shipping the taxonomy or a substantial part of it in a product (a tool’s built-in library, a printed deck, a reprint for sale), needs written permission. Ask me on LinkedIn.

Credit: “Email Infrastructure Threat Taxonomy” by Jonathan Brett Crawley, ostering.com, licensed under CC BY-NC-ND 4.0.

These additional permissions are given alongside the licence. They add to what the licence allows and do not take anything away from it.

Version

VersionDateChange
1.026 October 2026First published as reference pages, with PDF, Excel, SKOS and STIX downloads. References are stable identifiers.

Corrections, missing threats and worked examples are welcome: reach out to me on LinkedIn. Changes are logged here.

Sources

The issues behind these entries were already publicly disclosed in real systems; the contribution of the taxonomy is the translation into threats a designer can test against, and the collection. These are the original disclosures.