Our daily email infrastructure report classifies the sending stack of the Tranco top-1M domains by parsing their SPF records — 623,370 of them as of the 2026-07-05 snapshot. The method works because SPF is, in effect, a public declaration of vendors: include:servers.mcsv.net means Mailchimp, include:amazonses.com means Amazon SES, and so on across the 310+ patterns in our classifier. There is one practice that defeats this method completely, and it is common enough that every honest survey should lead with it: SPF flattening.
What flattening does to a record
Flattening resolves a record's includes ahead of time and publishes the resulting IP networks directly. The motivation is the 10-lookup evaluation limit — covered in detail in our PermError analysis — because ip4: mechanisms cost zero lookups. Before and after:
# Before: attributable — the vendor is named in DNS
v=spf1 include:servers.mcsv.net include:amazonses.com ~all
# After flattening: authenticates identically, attributes to nobody
v=spf1 ip4:205.201.128.0/20 ip4:198.2.128.0/18
ip4:199.255.192.0/22 ip4:54.240.0.0/18 ~allTo a receiving mail server, the two records are equivalent. To a DNS survey, the second one is opaque: the IP blocks belong to the vendors, but mapping arbitrary CIDR ranges back to ESPs reliably, at top-1M scale, across constantly shifting vendor allocations, is not something any published methodology does well — and we do not pretend to. A flattened Mailchimp customer simply stops being counted as a Mailchimp customer.
Every ESP share you have read is a floor
This is not a quirk of our pipeline; it is a structural property of measuring vendors through DNS. Any study — academic, commercial, or ours — that counts include: patterns undercounts every ESP by exactly its flattened customers. Three consequences follow:
- Shares are lower bounds. When our data says Amazon SES appears in 6.21% of SPF records, the true customer footprint is at least that — the flattened remainder is invisible, not absent.
- The bias is not uniform. Flattening is a response to lookup pressure, and lookup pressure correlates with stack complexity. Large, mature senders with many vendors are the most likely to flatten — so DNS surveys systematically undercount precisely the enterprise end of every ESP's customer base.
- Trends survive better than levels. Unless the rate of flattening itself changes sharply, a series that doubles in the visible data very likely doubled in reality. Direction and shape are robust; absolute precision is not.
Amazon SES is the instructive example: 1.51% of SPF domains in 2016, 2.86% in 2022, 6.21% as of the 2026-07-05 snapshot — more than doubling since 2022 in the visible data alone. Whatever fraction of SES customers flatten sits on top of that curve, not inside it.
How we bound the blind spot
We cannot see through flattening, but we can measure around its edges, and we publish those bounds rather than hiding them:
- Include coverage: 81.5%. Our 310+ patterns attribute 81.5% of SPF include traffic to a known vendor. The unmatched remainder is a mix of regional providers, corporate infrastructure, and one-off hostnames — a known, quantified residual.
- ip4-only records as a proxy. A record consisting entirely of
ip4:/ip6:mechanisms with no includes is either genuine self-hosting or a flattened vendor stack — indistinguishable from DNS alone. Tracking the prevalence of this shape over time gives an upper envelope on how large the flattening population could be. - Apex classification, stated plainly. We classify the SPF record at the registered domain. Senders that isolate vendors on subdomain records are attributed conservatively — one more reason to read our shares as floors.
The next time an ESP market-share chart crosses your feed, ask one question: can this methodology see a flattened record? If the data came from DNS, the answer is no, and every number on the chart is a floor. That is not a reason to discard the data — it is the error bar the publisher should have drawn.
Why we publish the caveat with the data
A measurement you can audit beats a measurement you must trust. The full methodology — pattern dictionary, coverage, apex rules, and the other failure modes like CNAME-fronted MX and dictionary growth — is documented in our methodology deep dive, and the raw daily output is available at api/latest.json for anyone who wants to recompute our numbers or stress-test the classification. Flattening is the one limitation we cannot engineer away, because the information is genuinely gone from the DNS. The best available response is the one this article is: name the blind spot, bound it, and never present a floor as a ceiling.