The SPF 10-Lookup Limit: Why It Exists and How to Fix It

The 10-Lookup Limit

RFC 7208 specifies that SPF evaluations must not result in more than 10 DNS lookups. This limit exists to prevent SPF from being used as a denial-of-service amplification vector — without it, a carefully crafted SPF record could trigger an exponential cascade of DNS queries.

When the limit is exceeded, the SPF check returns permerror (permanent error). Most receivers treat this as an SPF failure, which means your emails fail authentication even though your SPF record lists the correct senders.

What Counts as a Lookup?

Not every SPF mechanism triggers a DNS lookup. Here's the breakdown:

Mechanisms That Count (1 lookup each)

Mechanism	Why It Needs a Lookup
`include:domain.com`	Fetches domain's SPF record
`a` or `a:domain.com`	Resolves A/AAAA records
`mx` or `mx:domain.com`	Resolves MX records
`redirect=domain.com`	Fetches domain's SPF record
`exists:domain.com`	Checks for A record existence

Mechanisms That Don't Count

Mechanism	Why
`ip4:203.0.113.0/24`	IP is directly specified, no lookup
`ip6:2001:db8::/32`	IP is directly specified, no lookup
`all`	Matches unconditionally, no lookup

Nested Lookups Count

This is where organizations get caught. Each include may reference an SPF record that contains its own include statements, and those count against your total.

Example chain:

Your record: v=spf1 include:_spf.google.com include:sendgrid.net -all
  → _spf.google.com: v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all
    → Each _netblocks record contains ip4/ip6 entries (no further lookups)

Google Workspace alone consumes 4 lookups (1 for the initial include + 3 for the nested netblocks). Add a few more services and you're at the limit quickly.

Real-World Example

A typical SaaS company might use:

v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com include:spf.mandrillapp.com include:amazonses.com -all

Lookup count:

include:_spf.google.com → 4 (1 + 3 nested)
include:sendgrid.net → 1
include:mail.zendesk.com → 3 (1 + nested includes)
include:spf.mandrillapp.com → 2 (1 + nested)
include:amazonses.com → 1

Total: 11 lookups — over the limit.

The SPF check returns permerror. Every email from this domain fails SPF authentication.

How to Check Your Lookup Count

Use an SPF checker tool: Enter your domain and see the total lookup count with the full resolution chain
Manual inspection: Follow each include and count every mechanism that triggers a DNS lookup
Monitor DMARC reports: Look for SPF permerror results — this is the symptom of exceeding the limit

Strategies to Stay Under the Limit

1. Remove Unused Services

The simplest fix. Audit your SPF record and remove include statements for services you no longer use. Common culprits:

Old marketing platforms you've migrated away from
Decommissioned on-premise mail servers
Trial services that were never fully deployed

2. Replace `include` with `ip4`/`ip6`

If a service sends from a small, stable set of IPs, replace the include with direct IP entries:

Before: include:mail.example-saas.com (1+ lookups) After: ip4:203.0.113.0/24 ip4:198.51.100.0/24 (0 lookups)

Caution: If the service changes their IPs, your SPF record becomes stale and their emails fail. Only do this for services with documented, stable IP ranges.

3. SPF Flattening

SPF flattening automatically resolves all include chains to their final IP addresses and replaces the dynamic lookups with static ip4/ip6 entries.

Before flattening:

v=spf1 include:_spf.google.com include:sendgrid.net -all

After flattening:

v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:... -all

This eliminates DNS lookups entirely, but the record can become very long. DNS TXT records have a 255-character string limit (though multiple strings can be concatenated), and the total UDP response must fit in 512 bytes (or use TCP fallback).

Critical requirement: Flattened records must be monitored for changes. When Google or SendGrid updates their IP ranges, your flattened record needs updating too. Use automated SPF flattening tools that monitor for changes and alert you.

4. Use Subdomains

Send different types of email from different subdomains, each with its own SPF record:

marketing.example.com → SPF includes marketing platform only
support.example.com → SPF includes helpdesk platform only
example.com → SPF includes core business email only

Each subdomain gets its own 10-lookup budget. This also improves deliverability isolation — reputation issues with marketing email don't affect your transactional email.

5. Consolidate Services

If possible, route multiple types of email through fewer providers. Instead of using separate services for transactional email, marketing email, and support notifications, consolidate onto fewer platforms. Fewer providers means fewer include statements.

What About the 512-Byte UDP Limit?

DNS responses larger than 512 bytes may require TCP fallback, which some resolvers don't support properly. Long SPF records (especially flattened ones with many IP ranges) can hit this limit.

Solutions:

Use CIDR notation to aggregate IP ranges (/24 instead of individual IPs)
Split across subdomains to keep each record smaller
Use the redirect modifier to point to a dedicated SPF domain you control

Monitoring Your SPF Record

After optimizing, set up ongoing monitoring:

Track lookup count: Alert if your count reaches 8+ (buffer for changes)
Monitor IP changes: If you're flattening, watch for upstream IP changes
Check DMARC reports: SPF permerror in DMARC reports means you've exceeded the limit
Test after changes: Every time you add a new email service, re-check your lookup count

Summary

The SPF 10-lookup limit catches most organizations by surprise, usually after adding their fourth or fifth email service. The fix isn't to ignore SPF or abandon authentication — it's to optimize your record through removal of unused services, SPF flattening, subdomain separation, or service consolidation.

Stay proactive: monitor your lookup count, automate flattening if you use it, and test after every change. A broken SPF record silently undermines your entire email authentication stack.