Too many SPF lookups

“Too many DNS lookups” means your SPF record needs more than 10 lookups to evaluate, so receivers return a permerror and stop trusting your SPF. Here’s why it happens and how to get back under the limit.

SPF is validated by counting DNS-lookup-causing mechanisms. Per RFC 7208 §4.6.4, evaluating a record may trigger at most 10 of these:

• include
• a
• mx
• ptr (deprecated — avoid)
• exists
• redirect

ip4:, ip6:, all, and exp do not count. Crucially, each include can contain its own nested includes, and every lookup in that tree counts — so a handful of legitimate providers compounds past 10 fast. There is also a separate limit of 2 “void” lookups (mechanisms that resolve to nothing); exceeding either produces a permerror.

Why real domains blow past 10

The limit sounds generous until you count recursively. A single provider include can nest several more:

• Microsoft 365 — 1 lookup
• Google Workspace (_spf.google.com) — 3–4
• A CRM or agency platform — often 4–8 (deeply nested)
• Legacy hosts (GoDaddy secureserver.net, 1&1/IONOS) — 3 and up
• A self-referential include:yourdomain.com — doubles everything (always a mistake)

Four or five legitimate services routinely add up to 15–25 real lookups. And you cannot shrink the nested provider records — those belong to Microsoft, Google, and your vendors, and they change whenever those vendors want.

A worked example

Here is a realistic record for a business running Microsoft 365 plus a CRM and a couple of legacy hosts:

v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com
       include:secureserver.net include:sendgrid.net include:mail.example.com ~all

Counting recursively, the includes above can expand well past 10 DNS lookups — even though every sender is legitimate. The domain owner can’t shrink the nested provider records (those belong to Microsoft, Salesforce, and so on), and those providers change their IPs whenever they need to. That is exactly the situation flattening and macros are designed to solve.

How to fix too many SPF lookups

1. Prune first. Remove any self-include and any dead/legacy sender you no longer use. Many domains get under 10 for free this way. See the GoDaddy legacy-include example.
2. Move senders to subdomains. Providers like SendGrid and Amazon SES can validate SPF on a delegated subdomain, keeping them off your root budget entirely.
3. Flatten. If real senders still exceed 10, flatten the record to raw IPs (zero lookups).
4. Or use a macro. A single exists macro holds unlimited senders in one lookup and updates itself.

The three ways to fix too many SPF lookups

There are only three real strategies for getting an over-limit SPF record back under 10 lookups. Each has trade-offs:

The practical takeaway: pruning is great when it’s enough. Beyond that, static flattening trades one silent-failure mode for another, which is why the reliable answer for most domains is a managed, self-healing record — flattening (or macros) kept continuously in sync so it never goes stale.

Why this matters for DMARC

A permerror means SPF didn’t return a clean pass. Under DMARC, that removes SPF as a passing authentication method, so alignment now rests on DKIM alone. If DKIM also fails or isn’t aligned, a p=quarantine or p=reject policy will send legitimate mail to spam or bounce it outright. Keeping SPF under the limit is a prerequisite for enforcing DMARC safely.