Defaults.Exposed › Reports
Why Is My SPF Failing? The SaaS 10-Lookup Problem for UK and EU Senders (2026)
Published 2026-07-09
Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.
When SPF fails for a business using SaaS tools in the UK or EU, the most likely cause is a single RFC rule you’ve never had to think about: past 10 DNS lookups, SPF doesn’t return “fail” — it returns PermError, which means the record is treated as if it doesn’t exist. At least 797,263 domains have already crossed that line. Another 2,119,539 are sitting at exactly 9–10 lookups — one new tool away from the same cliff.
Why does SPF break when you add a SaaS tool?
SPF works by listing the mail servers authorised to send on behalf of your domain. Modern businesses don’t run their own mail servers — they use Google Workspace for internal email, Mailchimp for campaigns, HubSpot for sales sequences, Pipedrive for CRM outreach. Each platform hands you an include: line to paste into your DNS.
The problem: every include: is itself a DNS lookup. And every record inside that include can trigger more lookups recursively. RFC 7208 §4.6.4 sets a hard cap of ten. Past ten, the receiving mail server stops evaluating and returns PermError — and a PermError is not a soft failure that ends up in spam. It means your SPF record is treated as absent. Email authentication fails on the SPF leg.
You won’t see this in your DNS panel. The counter only fires during live evaluation. You can have three include: lines in your visible record and still be twelve lookups deep, because each vendor’s SPF record pulls in sub-includes of its own.
How many domains are already over the limit?
At least 797,263. That is the count after we resolved every SPF include: target referenced 100 or more times — 10,842 distinct targets covering 95.2% of all include references — and priced each domain’s full chain. The surface count (what you’d find by counting only the visible lines in a record) finds roughly 7,958. The chain-priced figure is 100 times larger, because nearly all the damage is invisible inside include targets.
The situation most likely to affect a European business:
| Scenario | What happens |
|---|---|
| Google Workspace + Mailchimp + HubSpot + one other | Likely at or over 10 lookups |
| IONOS hosting + any three SaaS tools | High risk: IONOS’s own SPF target adds multiple hops |
| OVH hosting + two transactional tools + a CRM | Risk depends on OVH SPF depth at evaluation time |
| Microsoft 365 alone | Low risk: Microsoft’s SPF is compact and well-maintained |
European hosting providers and weak SPF defaults
The hosting provider you started with matters — because some set SPF defaults that already consume several of your ten lookups before you connect a single SaaS tool.
Among the largest hosting providers used by European domains in our census:
| Provider | Domains using it | SPF strict (-all) | DMARC enforcing |
|---|---|---|---|
| IONOS (EU) | 4,346,526 | 0.3% | 1.0% |
| OVH | 2,132,049 | 43.7% | 2.2% |
| Microsoft 365 | 10,205,070 | 85.0% | 21.7% |
| Google Workspace | 12,145,313 | 8.0% | 18.5% |
IONOS stands out: 1.0% of IONOS-hosted domains have enforcing DMARC, which means the overwhelming majority have no meaningful sender authentication at all. OVH domains do better on the SPF strict setting (43.7%) but still fall to 2.2% on DMARC enforcement — SPF alone, without DMARC to tie it to the From: header, only protects the envelope, not what the recipient sees.
Microsoft 365 is the outlier in a good way: 85.0% of Microsoft-hosted domains use strict SPF, largely because Microsoft’s mail-flow wizard sets -all by default. Google Workspace sets ~all (softfail) by default, leaving 92% of its domains without strict protection.
How to diagnose your SPF failure in under 60 seconds
The fastest check is a free tool that evaluates the full lookup chain — not just the visible record. Run nslookup -type=TXT yourdomain.com at the command line and count every include: you see. Then look up each of those records and count theirs. If you run out of fingers before you run out of includes, you’re in the danger zone.
A more reliable approach: check your domain here — the scanner evaluates the full resolved chain, flags PermError, and shows you which mechanisms are consuming your lookup budget.
Three diagnostic outcomes:
- PermError — you’re already over ten. Every email you send fails the SPF check at the receiver.
- At 9–10 lookups — you’re on the cliff. The next SaaS integration tips you over.
- Softfail (~all) instead of hardfail (-all) — you’re under the limit but the record is set too permissively to provide real protection. See the SPF misconfiguration report for the full picture on
-allvs~all.
How to fix SPF when you use multiple SaaS tools
There are three approaches, in order of permanence:
1. Audit and prune. Start by listing every include: in your current record. Remove any platform you no longer use — old ESPs, CRM tools from previous contracts, platforms you tested but abandoned. This is free and often recovers several lookups. Each removed include: may eliminate 1–3 sub-lookups.
2. Flatten your SPF record. SPF flattening resolves all the include: targets into their underlying IP ranges and writes them directly into your record as ip4: and ip6: mechanisms. IP mechanisms don’t trigger lookups, so a flattened record can list dozens of sending sources and still sit at zero lookups. The downside: you need to re-flatten whenever a vendor updates their sending IPs, which happens without notice. Most businesses use a paid SPF flattening service (PowerDMARC, EasyDMARC, Dmarcian, and others offer this) or build a monitoring workflow.
3. Use SPF macros. RFC 7208 macros let you build records that perform a single DNS lookup per check and answer dynamically, rather than a chain of includes. Macros require DNS hosting support and some implementation effort, but they’re the architecturally clean solution for organisations with many SaaS senders.
After fixing SPF, pair it with DMARC enforcement — SPF without DMARC only authenticates the envelope sender, not the header From: address that recipients see.
Frequently asked questions
Why does my SPF record pass my DNS tool but still fail in email headers?
Most DNS lookup tools count only the mechanisms visible in your own record, not the sub-lookups those mechanisms trigger. You can have two include: lines and still be over the limit if each vendor’s record contains several more. Only a chain-pricing tool (or a receiving mail server) counts the full depth. Check your domain to see the real chain count.
Does SPF failing mean my emails go to spam?
PermError (too many lookups) means the SPF leg of authentication returns a non-result — effectively absent. DMARC evaluates both SPF and DKIM; if DKIM passes, DMARC can still pass despite the SPF PermError. If neither passes, DMARC fails, and the outcome depends on your DMARC policy. At p=none, email still delivers but the failure is logged. At p=quarantine or p=reject, email is filtered or bounced. Fix SPF so you’re not relying on DKIM alone.
How many lookups does a typical SaaS stack use? The p99 SPF record in our census already sits at 9 lookups — right at the limit — before adding anything. A Google Workspace record adds 3–4 lookups; Mailchimp adds 1–2; HubSpot adds 1–3 depending on their current configuration. Three mainstream tools plus your hosting provider’s default is often enough to tip over ten.
Is SPF flattening safe?
Yes, provided you keep it current. Flattening converts include: chains into static IP ranges — if a vendor rotates their sending IPs and you don’t re-flatten, you’ll start rejecting their mail. Most organisations use a managed flattening service that monitors for IP changes rather than maintaining it manually.
My SPF has been like this for years — why is it suddenly failing? Because your vendors updated their SPF records, not yours. Every time a SaaS platform adds a new sending IP range or nests another include, your chain cost rises without any change on your end. The 10-lookup limit is evaluated live at message receipt, so a vendor change on a Tuesday morning can break your SPF by Tuesday afternoon.
Does fixing SPF improve email deliverability? It removes a source of authentication failure, which is a prerequisite for consistent delivery — particularly since Google and Yahoo now enforce DMARC alignment for bulk senders. SPF alone isn’t the whole picture: pair it with DKIM and DMARC for full email authentication.
Check your SPF free
If you’re not sure whether your SPF record is over the lookup limit — or is set too weakly to protect your domain — run a free check. It evaluates the full resolved chain and shows you exactly where the budget is being spent.
Check your domain → · Fix SPF → · The SPF PermError report → · SPF misconfiguration report → · The SPF adoption maturity model → · Fix DMARC → · Aggregate data only. Data stored and processed in the EU.