GitHub, eBay and Oracle Are One Tool Away From Breaking SPF (2026 Study)

SPF has a limit almost nobody watches. RFC 7208 §4.6.4 allows an SPF evaluation to make at most 10 DNS lookups, counted recursively through every include: you inherit. Go past it and a conforming receiver returns permerror — SPF stops authenticating your mail entirely.

The dangerous part is what it looks like when that happens: nothing. The record is still there. It still parses. Every "do you have SPF?" checker still says yes. You have simply stopped being authenticated, and the only symptom is mail landing in spam for reasons nobody can explain.

We resolved the SPF policies of the top 5,000 domains on the web to find out how common this is. Of the 3,708 that publish SPF, 3% are already broken — and 139 sit at exactly 10, one added service away from breaking. That group includes GitHub, eBay, Intuit, Oracle and MIT. It included Reddit when we measured; they have since fixed it, and how they did it is worth a section of its own below.

This is our own measurement, run on 17 August 2026. The method is below in full, and unlike our earlier studies the harvesting script ships with it.

The headline numbers

Of 5,000 domains, 3,708 (74.2%) publish an SPF record. Among those:

So one in eight domains that publish SPF is two DNS lookups from switching it off by accident, and one in thirty-three has already done it.

The distribution

Note the shape. Counts fall away steadily from 0 to 9 — and then bounce back up at exactly 10. There is no natural reason for a spike at 10. It is the ceiling acting as a magnet: teams add senders until something warns them, trim back to the maximum allowed, and stop there with zero margin. 139 domains are parked on that line.

The cliff edge is crowded, and well-known

Domains sitting at exactly 10 lookups — SPF working today, broken by the next tool anyone adds:

github.com · intuit.com · ebay.com · oracle.com · mit.edu · nic.ru · adsrvr.org

These are not neglected domains. They are large organisations with staff who know what SPF is. The limit is simply not something most tooling surfaces until it has already been crossed.

Re-verified 31 August 2026: all seven are still at exactly 10.

One of them has since escaped, and it shows the trade

reddit.com was on that list when we measured on 17 August. It is not any more. As of 31 August its record reads:

v=spf1 include:spf0.reddit.com -all

That is 3 DNS-querying terms, down from 10. They did not remove senders — spf0.reddit.com is a single enormous record holding roughly a hundred ip4: ranges, plus one exists: for Salesforce and one include: to a continuation record at spf1.reddit.com.

This is exactly the remedy discussed below: flattening. The include: chains that each cost a lookup have been resolved once, by hand or by tooling, into literal address ranges that cost none. It buys headroom, and the article's caveat applies in full — those ranges are now Reddit's to maintain. When one of their senders changes IP space, nothing in DNS updates automatically and mail from the new addresses fails SPF until someone notices.

We are not claiming any credit for this and have no reason to think anyone there saw the study. We are reporting it because a named example that changed is more useful than one that did not: it is the first evidence in this dataset that a domain sitting on the ceiling can get off it, and the shape of the fix is the one the tooling nudges you towards.

Already over

The worst cases in the sample, by DNS-querying terms reached:

Every one of these publishes a syntactically valid SPF record that a conforming receiver will refuse to evaluate. Three of them are adtech companies whose entire business is delivering messages.

You can re-check any of them yourself — our SPF/DKIM/DMARC checker now counts lookups recursively and reports the total against the limit.

Unlike DMARC, this does not improve at the top

Our DMARC adoption study found enforcement falling by roughly a third as you move down the rankings: the biggest domains were meaningfully better configured. We expected the same gradient here, and it is not there.

Flat. SPF breakage is not a small-organisation problem — it is what happens to anyone who accumulates enough third-party senders, and large companies accumulate more of them, not fewer. Every marketing platform, helpdesk, invoicing tool and CRM you adopt wants an include:, each one costs at least one lookup, and the ones you inherit bring their own.

The other permerror nobody mentions

Twenty domains publish more than one SPF record. RFC 7208 §4.5 is explicit that this is a permerror too — receivers do not merge them, they give up. It usually happens when two teams each add a record instead of editing the existing one:

warnerbros.com · howstuffworks.com · indiatimes.com · bookmyshow.com · olx.com.br · letras.mus.br · education.dz · churnzero.net

This is the easier of the two to fix: merge the mechanisms into a single v=spf1 record.

A footnote on +all

Three domains in the sample end their SPF in +all, which authorises every host on the internet to send mail as them — worse than publishing nothing, because it looks like configuration: siemens.com, sonicwall.com, nessus.org.

Two of the three sell security products. We are reporting a DNS fact rather than making a point about it, and +all is occasionally used deliberately during migrations. It should never be a steady state.

What to do about it

1. Count your lookups. Not your include: statements — the recursive total. Check your domain; anything at 8 or above needs attention now rather than at the next tool adoption.
2. Flatten the expensive includes. Replace an include: whose target publishes a stable set of addresses with the ip4:/ip6: ranges themselves. Costs zero lookups. The trade is that you now own keeping them current, so flatten the stable ones and leave the churning ones alone.
3. Remove senders you no longer use. The commonest cause of a bloated policy is a tool cancelled two years ago whose include: nobody deleted.
4. Do not solve it with a second record. That is the other permerror.
5. Remember what none of this covers. SPF, DKIM and DMARC all authenticate the message; none of them stops an attacker stripping TLS from the connection. That is MTA-STS, which we measured separately — and found that nearly half the domains announcing it enforce nothing.
6. Lean on DKIM and DMARC alignment. DKIM has no lookup ceiling. If SPF is structurally tight, DKIM is where durable authentication lives — though verifying DKIM from outside is far less reliable than it looks, because selectors cannot be enumerated and a "not found" result depends heavily on your provider.

Method

Sample. The Tranco top 5,000, list ID ZJGPG — the same list our DMARC and provider studies used, so results join to both. Tranco is built for research reproducibility.

Queries. For each domain, TXT at the apex to find v=spf1 records. For each include: target and redirect= modifier, TXT at that name, recursively, with results cached across the run. Resolved over DNS-over-HTTPS on 17 August 2026.

Counting. Per RFC 7208 §4.6.4 the terms that cost a DNS lookup are the include, a, mx, ptr and exists mechanisms and the redirect modifier. We count every such term reachable in the policy, following include: and redirect= into nested records, with cycle detection and a depth cap.

This is a worst-case count. A real evaluation stops as soon as a mechanism matches the sending IP, so the exact cost depends on who is sending. The reachable total is what SPF validators report and what determines whether a policy can complete, which is the question that matters. Where a domain is over the limit, some senders may still pass while others hit permerror — a failure mode that is worse than a clean break because it is intermittent.

Denominator. Domains publishing SPF. Our DMARC study gated on MX records, because receiving mail is what makes DMARC relevant. SPF governs sending, and an MX record tells you nothing about whether a domain sends — so MX is deliberately not used here.

Verification. The counter was checked by hand before the run. github.com totals 10: eight direct include: mechanisms plus two reached recursively, via _spf.salesforce.com (which uses an exists: mechanism) and sendgrid.net. GitHub sitting at the SPF ceiling is a documented case, so the agreement is a real check rather than a coincidence.

Script. scripts/study-spf-lookups.mjs in our repository. Run it against the same Tranco list and you should reproduce these numbers within DNS churn. Our first two studies invited readers to reproduce them without shipping the code; that was a gap and this closes it.

Limitations

• 5,000 domains, not 30,000. Recursive resolution multiplies queries far beyond the three-per-domain of our earlier studies, and we would rather sample smaller than hammer a free public resolver. The band analysis shows the rate is stable across ranks, so the figure should hold deeper into the list — but we have not measured that and do not claim it.
• One resolver, one moment. Records change. A domain over the limit today may be fixed tomorrow, and vice versa.
• Sub-limits not measured. RFC 7208 also caps void lookups at two, and the mx and ptr mechanisms carry their own secondary limits. Domains passing our check could still fail on those, so 3% is a floor, not a ceiling.
• We do not know the consequence. permerror handling varies between receivers; some treat it as neutral rather than a failure. What we measured is that these policies cannot be evaluated as specified, not that a given message was rejected. Claiming a deliverability impact would require sending mail and measuring it, which we have not done here.

Corrections

31 August 2026 — reddit.com removed from the title and the at-the-limit list. Reddit was named in this article's headline as one tool away from breaking SPF. That was true on 17 August, when it counted 10. It has since flattened its record to 3 and is no longer close to the limit, so the claim was re-worded rather than left standing: the title now names GitHub, eBay and Oracle, all re-verified at exactly 10 on 31 August, and Reddit's fix has a section of its own because it is the more interesting result.

Found by bun run check:study-claims, which re-probes every domain our studies name against the claim made about it. Naming a real company's configuration is the most checkable thing on this site and the fastest to rot; until 31 August nothing watched it, and this was the fourth drift the script caught in four days.