The Unmodeled Attack Surface - A Threat Taxonomy for Email Infrastructure

Brett Crawley
Brett Crawley 11 min read
X-ray view of a mail flow: an envelope passes the edge and the scanner on its way to the mailbox while a second envelope takes a path underneath that no control saw

TL;DR: Email infrastructure has never had a threat taxonomy of its own. I have published one: 117 threats across nine layers of the email stack, plus eight structural hazards, each with a mitigation principle and concrete design measures. It is the reference for my card game Elevation of Email Flow. Walk it against a mail flow you know and tell me what it misses. The full taxonomy, with a page per layer and downloads in four formats, is at Email Infrastructure Threat Taxonomy.

There is a category of infrastructure that security teams use every day, threat model with whatever tools they have to hand, and still miss a whole class of risk. It carries credentials, payment instructions, legal notices and password resets. It is the most impersonated channel in enterprise security. And the taxonomies we use to model it were built for something else.

I am talking about email. Not the phishing lure and not the malicious attachment, but the machinery itself. There is no adequate threat taxonomy for it. Nothing that covers how a Simple Mail Transfer Protocol (SMTP) conversation establishes and betrays trust. Nothing that covers how a MIME parser can be confused into rendering something the scanner never saw. Nothing that covers how SPF, DKIM and DMARC can be weaponised, not merely bypassed, or how the hops in a delivery pipeline can be pulled apart so that controls fire in the wrong order, on the wrong version of a message, or not at all.

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.

The problem is not that teams skip threat modeling. The problem is that the frameworks were not built for this domain. Apply STRIDE to email infrastructure and it will surface something. It will not surface these things.

I have published a taxonomy that does: 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. It has a home of its own on this site, with a page for every layer, and this post explains why it exists and what it covers. It is the reference for a card game I designed first, Elevation of Email Flow: every entry is one of the game’s cards, restated as prose.

Why the gap exists

Threat modeling methodology follows builders. STRIDE, PASTA and LINDDUN were shaped by the technologies that large, open communities were building on: web applications, cloud APIs, databases, identity systems. Those attracted developers. Developers attracted tooling, tooling attracted CVEs, and CVEs attracted threat models.

Email infrastructure attracted none of that. The vendor space is small and largely closed, and an MTA, a gateway or a scanner cannot be extended the way a web framework can: there is no equivalent of dropping a middleware into the delivery pipeline. Researchers do not gravitate towards what they cannot extend. So the protocols underneath every enterprise mail flow (SMTP, IMAP, POP, MIME, S/MIME, SPF, DKIM, DMARC, DNSSEC, ARC) have accumulated decades of complexity, trust assumptions and known but unmodeled failure modes, with no structured framework to surface them.

The result is not that email infrastructure is insecure by intention. It is unexamined by default. The people who build mail transfer agents (MTAs), gateways, content scanners, mailbox services and clients are very good at what they build. What they rarely have is a framework for asking: what can go wrong in this component, at this trust boundary, in this sequence?

When the framework does not exist, the question does not get asked systematically. And when the question does not get asked, the findings do not get made.

What the taxonomy is

It is a structured catalogue of what can go wrong in email infrastructure, organised by the layer of the stack where the threat lives. There are nine layers, and a tenth group of structural hazards that belong to email itself and that no single component can fix.

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.

Every entry has the same parts:

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

Who it is for and how to use it

If you build a mail platform, whether an MTA, a gateway, a content scanner, a mailbox service or a client, this was written for you first. You do not need a security background. Each entry tells you what to look for, what a sound design does about it, and concrete ways that has been done.

If you are a security engineer who has been handed email infrastructure to threat model and found that STRIDE gives you the obvious but misses the specific (the pipeline fracture, the inherited verdict, the verdict that decays after delivery), this names what you have been trying to name. The layers match the way you already think, and the entries are precise enough to write findings against.

If you are a CISO, there is one question here for you. Has anyone ever threat modeled your email infrastructure against the machinery itself, and not just against what it is supposed to catch?

Using it is simple:

  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.

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. What you are reading 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 references at the end 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.

What the taxonomy covers

The full taxonomy lives in the Email Infrastructure Threat Taxonomy section of this site, with a page for every layer. Each layer page has its entries, where it touches the other layers, and how it maps to STRIDE, CAPEC and CWE. These are the nine layers and the structural hazards:

The layers of the email stack: the nine layers and the structural hazards, with each one's prefix, number of entries and scope.

Final thoughts

This is a first published version, not a final one. The domain is complex, the vendor space is not standing still, and I have no doubt there are threats I have missed and entries that belong in a different layer.

So take it, walk a layer against a mail flow you know well, and tell me where it falls short. Corrections, missing threats and worked examples from practitioners are all welcome: reach out to me on LinkedIn.

Email has gone unexamined by default for long enough. Let’s start asking the question. More on the game the taxonomy came from in a later post. Stay tuned!

Resources

The taxonomy is also available to download in four formats, all with the licence embedded. The overview page lists them too.

DownloadFormatWhat it is for
PDFA4 landscape, a section per layer, with each entry’s mappingsReading and printing
ExcelOne layer per sheet, with the STRIDE, CAPEC and CWE mappingsFiltering, sorting, and tracking findings against each entry
SKOS (JSON-LD)W3C SKOS concept schemeLinked data and knowledge graphs
STIX 2.1STIX 2.1 bundleThreat intelligence and security tools

Licence

© 2026 Jonathan Brett Crawley. The taxonomy is licensed under CC BY-NC-ND 4.0 with additional permissions: you can share it freely for non-commercial purposes, threat model with it (including for paying clients), use it internally and for training in any organisation, and quote entries with credit in paid work. Shipping it in a product needs permission. The full terms are on the overview page.

References

You may also like: