The SPF 10-lookup limit, explained

The single most common SPF problem is exceeding the 10-lookup limit. This is what the limit actually is, why it’s so easy to hit, and how to get — and stay — under it.

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 the limit exists

SPF evaluation happens in real time as mail arrives. Without a cap, a maliciously or accidentally deep chain of includes could force a receiver into a huge number of DNS queries per message — a denial-of-service risk. RFC 7208 caps lookups at 10 (and void lookups at 2) to keep evaluation bounded.

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.

Getting under the limit

Prune what you don’t use, move eligible senders to delegated subdomains, and if real senders still exceed 10, flatten the record or adopt a single-lookup macro. The durable answer for multi-sender domains is a managed, self-healing record so you never drift back over the line.

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.