We counted the Fortune 50’s SPF lookups. Not one is over the limit, and half sidestepped it entirely.

Table of contents

• What is the SPF 10-lookup limit, and why does it break mail?
• How many SPF lookups do the biggest senders actually use?
• What did half the Fortune 50 do instead?
• Is SPF flattening safe?
• What should you try before flattening?
• What we got wrong while measuring this
• What this measurement does not cover

What is the SPF 10-lookup limit, and why does it break mail?

SPF is capped at 10 DNS lookups per evaluation, and crossing that cap fails SPF for every message you send. The rule has sat in RFC 7208 §4.6.4 for 12 years, written by editor Scott Kitterman as a hard requirement, not guidance: “SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return ‘permerror’.” Published April 2014, it names 6 counting terms — include, a, mx, ptr, exists, redirect — and caps one mx at 10 address records on top of the overall 10. The ones that cost nothing are all, ip4 and ip6, which is the entire basis of flattening.

Two things make it under-diagnosed. Lookups inside the records you include count toward your total, so a provider 3 levels down can push you over without anyone touching your DNS. And there is a second, less famous ceiling: the same section says implementations SHOULD limit “void lookups” — queries returning no answer — to 2, with permerror again as the penalty, and recommends 2 as the default where the limit is configurable — so a record at 5 mechanisms can still permerror on 3 dead hostnames. A decommissioned provider whose hostname stopped resolving can therefore break a record that is nowhere near ten mechanisms.

How many SPF lookups do the biggest senders actually use?

Fewer than the folklore suggests. Of the 25 Fortune 50 domains we could count statically, not one exceeds the limit. Median 4 of the 10 permitted, mean 3.84, range 1 to 9 — 0% over the limit. Only 2 sit at 8 or above — tesla.com at 9 and kroger.com at 8, 8% of the countable sample — while 44% sit at 3 or fewer and 20% resolve on a single lookup. All 50 publish SPF: the same apex domains we measured for DKIM key strength, where 40% of keys were 1024-bit RSA. The full dataset is published, one row per domain.

The honest reading is narrow. It does not mean the limit is a non-problem — the Fortune 50 are the wrong place to look for it. These are companies with mail teams, change control, and in 25 of 50 cases a vendor paid to handle exactly this. The firms that hit the ceiling are 20-person companies running 15 SaaS tools that each want an include:, and this sample cannot see them. Read it as a ceiling on how bad it gets at the top, not a census.

The two domains at 8 and 9 are the interesting ones, because that is not a safe place to sit. A record at 9 lookups has spent 90% of a budget it does not control, and the next include: added by any provider in the chain — not by you — is the one that returns permerror. This is the same class of silent drift we wrote about in what happens when DNS is handed to marketers: the record is edited by people who do not own the consequences, and nothing tells them the ceiling exists. If you want to know where your own record sits, the SPF lookup checker walks your whole tree and counts it.

What did half the Fortune 50 do instead?

They removed themselves from the problem with a macro — 50% of the sample, and not from one vendor but five. 25 of the 50 publish an SPF record containing a macro — 18 of those 25 use the same one, include:%{ir}.%{v}.%{d}.spf.has.pphosted.com. That particular one is Proofpoint’s Hosted SPF, and the macro letters are defined in RFC 7208 §7: %{i} is the sending IP, the r transformer reverses it, %{v} expands to in-addr or ip6, and %{d} is the domain being checked.

The 5-vendor spread is the part that matters. One vendor selling a clever record is a product; 5 implementations across 50% of the list, 1 built in-house, is a category settling on an answer. Half of the 50 largest US senders have concluded that living inside a 10-lookup budget means not enumerating senders in DNS at all.

So the hostname does not exist until a message arrives: one from 192.0.2.5 claiming to be example.com resolves 5.2.0.192.in-addr.example.com.spf.has.pphosted.com. The cost is 1 lookup whether 10 senders sit behind it or 10,000, and the authorised set lives in the provider’s system, not your DNS — so it changes without a DNS change request.

Here is the part that matters for anyone reaching for a flattener: a macro record cannot be flattened. There is no fixed set of addresses to substitute, because the addresses are never enumerated anywhere. A tool that flattens one of these has silently dropped it, and the record you publish authorises strictly less mail than the record you started with. So the answer half of the largest senders in America reached for is the one answer flattening cannot reproduce.

Is SPF flattening safe?

Only if something re-checks it, and most flatteners hand you a record and walk away. Flattening resolves your include: tree to the literal ip4: and ip6: ranges it points at today. Because IP mechanisms cost no lookups, a record needing 12 suddenly needs 0. The arithmetic is real.

What you have done is trade a live reference for a copy. An include: is a promise to report the provider’s current addresses on every evaluation; a flattened record is a photograph of that answer on one day. When they renumber — without announcing it — your record keeps authorising released addresses and stops authorising the new ones. SPF fails for genuine mail, with no bounce naming the cause and no error in your DNS, because to every system the record is perfectly valid. It is simply wrong. That is the failure mode continuous monitoring exists for: something has to notice the day the copy and the original stop agreeing.

The counter-argument deserves stating fairly, because flattening vendors make it and they are right: a record re-resolved automatically is safe, and that is how commercial flatteners work. Our disagreement is narrower than it sounds. The safe artefact is not the record — it is the thing re-checking it. A tool that hands you the record without the re-check has given you the dangerous half and called it a fix.

What should you try before flattening?

Delete the includes you no longer use. On most over-limit records that alone gets you under 10. Every marketing tool, ticketing system and payroll provider you have trialled asked for 1 include:; almost none asked you to remove it on the way out, and each was approved by someone who has since changed jobs — the same drift that leaves a new platform inheriting nothing. A full authentication audit lists what your record authorises today.

1. Delete includes for services you no longer use. Free, reversible, and on most over-limit records sufficient on its own.
2. Ask your provider for a narrower include. Several large senders publish a transactional-only variant that resolves fewer nested records than the catch-all one.
3. Consolidate overlapping senders. If three tools all send through the same underlying ESP, they may share one include rather than three.
4. Check the void-lookup count too. RFC 7208 caps non-answering lookups at 2, so one decommissioned provider can break a record sitting at 5 mechanisms.
5. Only then consider flattening — and only with something re-checking it.

By step 5 you will know exactly which providers you are freezing a copy of — the difference between a deliberate trade and an accident. Knowing who sends as you is the prerequisite for all 5 steps, which is what a clear owner for deliverability exists to establish. Of our 25 countable domains, 11 sit at 3 lookups or fewer and never need any of this.

What we got wrong while measuring this

Our own lookup counter was under-reporting. It stopped following include: chains after 3 levels, a bound RFC 7208 does not impose — the spec limits total lookups, not depth. The Fortune 50 run surfaced it: jnj.com counts 4 with the cap, 5 without. One domain in 25, a difference of exactly 1 lookup, and the cap has moved from 3 levels to 10.

The direction of the error is the point. Under-counting reports a domain as comfortably under the limit while it may already be over it and failing SPF on every message — precisely the alert the number exists to raise. An over-count is noise; an under-count is a false all-clear. The regression test walks a 5-deep chain and asserts 5, and the fix shipped before this post. It is a fair argument for checking authentication in CI rather than by eye: the bug survived because nothing compared our count against an independent one.

What this measurement does not cover

Four limits, because they change how far the finding travels. We measured apex domains only. Bulk mail usually leaves from a subdomain with a different record, and that is where sender sprawl accumulates — the apex is a company’s best-tended record, not its representative one. The 25 macro-based records are uncounted, not counted as zero. Nobody can count them statically, including us, so the “none over the limit” result covers 50% of the sample, not 100%. We detect macros on the apex record; a macro nested inside an include: target was not exhaustively checked, so 25 is a floor. It is a point-in-time snapshot, resolved through 1 resolver (Cloudflare 1.1.1.1); SPF records change without notice, and the dated dataset below is the record of what we read. And the Fortune 50 is a deliberately unrepresentative sample for this particular question, as noted above — it tells you about the best-resourced end of the market.

Free tools

• SPF lookup limit checker — walk your whole tree and count it against the 10 the way a receiver does, mechanism by mechanism.
• Deliverability audit — SPF, DKIM, DMARC and alignment in one pass.
• Watchtower monitoring — re-reads your records on a schedule and emails you when one breaks.
• Inbox Reality Check — paste a delivered message and see what the receiver saw.
• Blocklist checker — find your real sending IPs and check them live.
• Contact List Reality Check — profile a list in your browser; nothing is uploaded.
• DMARC Policy Simulator — preview none, quarantine and reject before publishing.
• Warm-up planner — whether a domain can absorb more volume yet.
• Cryptographic posture (CBOM) — DKIM key strength, DNSSEC, DANE, MTA-STS.
• Agent Comprehension Score — what an AI agent extracts from your email.

Key takeaways

• None of the 25 Fortune 50 domains we could count statically exceed the 10-lookup limit, median 4 of 10, mean 3.84, range 1–9, across 25 countable domains.
• 25 of 50 — exactly half — use a macro-based include, across 5 vendors (Proofpoint 18, Valimail 3, Cisco 2, Agari 1, 1 self-hosted), each costing exactly 1 lookup of the 10 no matter how many senders sit behind it.
• A macro record cannot be flattened by anyone. The addresses are never enumerated, so a flattener that accepts one has silently narrowed who may send as you.
• Flattening trades a live lookup for a copy that goes stale silently — no bounce, no error, no alert — so the safe artefact is the thing re-checking it, not the record.
• Deleting unused includes fixes most over-limit records without freezing a copy of anything.

FAQ

What is the SPF 10-lookup limit?

RFC 7208 section 4.6.4 requires SPF implementations to limit the include, a, mx, ptr and exists mechanisms and the redirect modifier to 10 DNS lookups during a single evaluation, and to return permerror if that limit is exceeded. The all, ip4 and ip6 mechanisms cause no DNS query and do not count. Lookups inside the records you include count toward your total, so a provider can push you over the limit without touching your record.

What happens when an SPF record exceeds 10 lookups?

Evaluation stops and returns permerror. Under DMARC that is not an SPF pass, so SPF stops contributing authentication for every message you send, from every server, until the record is fixed. There is no bounce that names the cause and no error visible to the sender, which is why records sit broken for months. If DKIM is signing and aligning, DMARC still passes and the failure is invisible.

Is SPF flattening safe?

Only if something re-checks it. Flattening replaces include: mechanisms with the literal IP ranges they resolve to today, which costs no lookups. But it is a copy, not a reference: when a provider renumbers its sending infrastructure, a flattened record keeps authorising the old addresses and silently stops authorising the new ones. SPF then fails for real mail with no bounce naming the cause. Flattening converts a lookup problem into a maintenance problem, which is a good trade only when the maintenance is automatic.

What is a macro-based SPF record?

A record that uses RFC 7208 macros so the hostname being looked up is constructed at delivery time from the message itself. Proofpoint's Hosted SPF publishes include:%{ir}.%{v}.%{d}.spf.has.pphosted.com, where %{i} is the sending IP, r reverses it, %{v} expands to in-addr or ip6, and %{d} is the domain. It costs exactly one lookup no matter how many senders are behind it, because the answer is computed per message rather than enumerated in DNS.

Can a macro-based SPF record be flattened?

No. There is no fixed set of addresses to substitute, because the hostname only exists once a specific message arrives from a specific IP. Any tool that flattens such a record has silently dropped it, which narrows who is allowed to send as the domain. A flattener that does not tell you this is giving you a record that authorises less mail than the one you started with.

Sources

• Kitterman, S. RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. IETF Standards Track, April 2014. §4.6.4 DNS lookup limits (10 mechanisms, 2 void lookups); §7 macros.
• Proofpoint. Proofpoint Hosted SPF Technical Overview. Vendor documentation for the most common of the five macro mechanisms observed, on 18 of the 50 domains.
• HireAmino. Fortune 50 SPF lookup measurement — per-domain records, classification, method and the measurement date. Measured with the same engine behind hireamino.com/spf.
• HireAmino. Fortune 50 email cryptography — the same 50 apex domains, measured for DKIM key strength, DNSSEC, DANE and MTA-STS.