The SPF 10-lookup limit is one of those design decisions that made sense when email was smaller, simpler, and less outsourced.
Which is exactly why it’s such a nuisance now.
RFC 7208 says SPF evaluation must limit the number of DNS-querying terms to ten. Exceed that and the result is PermError. Not “you are almost done.” Not “try again with a warning.” An SPF policy that collapses into an error state because the protocol assumes too much DNS work is suspicious.
The protocol isn’t completely wrong. DNS amplification and recursive abuse were real concerns in 2003. But the internet that gave us that limit is not the internet that now asks one domain to send mail through corporate email, marketing automation, help desk software, CRM systems, HR platforms, billing systems, and transactional providers all at once.
The limit stayed frozen. Email did not.
What Counts Toward the Ten
Not every SPF mechanism triggers a DNS query. ip4: and ip6: are literal values — no lookup needed. But these mechanisms and modifiers each consume at least one:
include:— the big one. Each include pulls another domain’s SPF record, which may itself contain includes.a— looks up the A record of the domainmx— looks up MX records, then A records for each MX hostptr— reverse DNS lookup (discouraged by the RFC, still seen in the wild)exists— checks if a domain existsredirect— follows to another SPF record
The trap is that includes are recursive. If include:spf.provider.com itself contains three includes, that’s four lookups for what looks like one line in your record. A single include:_spf.google.com already consumes two or three lookups depending on Google’s current configuration.
How Real Organizations Hit the Limit
A typical enterprise email setup in 2026:
- Google Workspace or Microsoft 365 for corporate email: 2-3 lookups
- Marketing platform (Mailchimp, HubSpot, Sendgrid): 1-2 lookups
- CRM (Salesforce): 1-2 lookups
- Customer support (Zendesk, Freshdesk): 1 lookup
- HR/onboarding system: 1 lookup
- Transactional email (billing, notifications): 1 lookup
That’s 7-10 before you’ve even added every legitimate sender. Now the finance team signs up for an invoice platform that requires an include. An acquisition adds a subsidiary with its own email infrastructure. A SaaS trial nobody documented is sending password reset emails from your domain.
You’re at 12. SPF silently breaks. DMARC alignment fails. Your emails start landing in spam — or getting rejected — and the error message from the receiving server says nothing about SPF lookups. You find out weeks later when someone notices delivery rates dropped.
The Silent Failure
This is the truly maddening part. Exceeding the lookup limit doesn’t generate an error email to you. It doesn’t send a warning to the domain administrator. The SPF record just stops working. Receiving servers see PermError and either treat it as a hard fail or ignore SPF entirely, depending on their configuration.
Most SPF validation tools will tell you if you’re over the limit — if you think to check. But how many administrators audit their SPF record after every SaaS onboarding? After every marketing tool trial? After every vendor integration?
The record grows silently. It breaks silently. The damage accumulates silently.
The Workarounds Are All Hacks
SPF flattening. Resolve all include: chains into literal ip4:/ip6: entries. No lookups needed because everything is hardcoded. The problem: those IP addresses change. Cloud providers rotate IPs. Flattened records go stale unless you re-resolve them regularly — which means you need an automated tool to monitor and update your DNS. You’ve replaced a protocol problem with a maintenance problem.
Subdomain delegation. Send marketing email from mail.example.com with its own SPF record. Support email from support.example.com. Each subdomain gets its own 10-lookup budget. This works but fragments your email identity and complicates DMARC alignment.
SPF macros. Use exists: mechanisms with macros to construct dynamic lookups that short-circuit evaluation. Clever, but fragile, hard to debug, and not every receiving server handles macros correctly.
Every workaround adds complexity and maintenance cost. None of them fix the underlying problem.
Why Nobody Fixes the Standard
The 10-lookup limit is baked into the RFC. Changing it would require a new specification, and the IETF process is slow. There’s also a genuine argument that raising the limit increases DNS load — but the counterargument is that SPF flattening generates more DNS traffic than a higher limit would, because automated flattening tools poll DNS constantly to keep records fresh.
The irony: a limit designed to prevent DNS abuse now causes more operational damage than the abuse it prevents. Organizations hit the limit, deploy flattening tools that hammer DNS with polling, and the net effect on DNS infrastructure is worse than just allowing 20 lookups.
Twenty years. The email ecosystem has completely transformed. The limit hasn’t moved.
What You Can Do
Check your SPF record. Right now. Count the lookups. If you’re at 8 or above, you’re one vendor integration away from silent failure.
If you’re already over: flatten or split subdomains. Set up monitoring for SPF validation failures. And lobby your vendors to consolidate their SPF includes — many SaaS providers use needlessly sprawling include chains that waste your lookup budget.
The limit isn’t going away. The best you can do is manage around a 20-year-old constraint that was written for a simpler internet.