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.” The whole policy collapses into an error, because the protocol treats that much DNS work as suspicious.
The protocol isn’t completely wrong. The limit, first written down in RFC 4408 in 2006, exists so that checking one message can’t be turned into a burst of DNS queries aimed at somebody else’s servers — the RFC’s security section says so plainly. 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
all, ip4:, ip6: and the exp modifier cost nothing. The count runs across the entire evaluation, nested records included, and RFC 7208 adds a second, smaller trap: lookups that come back empty (“void lookups”) should be capped at two, and the third is also a PermError.
The big 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. Google’s _spf.google.com used to chain to several more _netblocks records this way; today it lists its address ranges directly and costs one. Vendors change these records whenever they like, in either direction, and nobody emails you about it.
How Real Organizations Hit the Limit
A typical enterprise email setup in 2026:
- Google Workspace or Microsoft 365 for corporate email: 1 lookup (as their records stand today)
- Marketing platform (Mailchimp, HubSpot, SendGrid): 1-2 lookups
- CRM (Salesforce): 2 lookups
- Customer support (Zendesk, Freshdesk): 1 lookup
- HR/onboarding system: 1 lookup
- Transactional email (billing, notifications): 1 lookup
That’s seven or eight before you’ve 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 11. SPF silently breaks. Unless DKIM passes and aligns, DMARC fails with it. Your emails start landing in spam — or getting rejected — and the only clue is a permerror buried in an Authentication-Results header nobody reads. 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. The counterargument is that the limit doesn’t remove that load so much as move it: organizations hit the ceiling, deploy flattening services that re-resolve vendor records on a schedule, and publish longer, more brittle records.
The irony, as I see it: a limit designed to prevent DNS abuse now causes more operational pain for honest senders than the abuse it was written to stop.
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.