SPF 10 DNS Lookup Limit Explained

The SPF specification (RFC 7208) imposes a hard limit of 10 DNS lookups during SPF evaluation. Exceed this limit and your SPF record returns a permerror — which means SPF is completely broken for every email sent from your domain.

This limit is the single biggest operational headache with SPF. Here's everything you need to know about it.

Why the Limit Exists

SPF evaluation happens in real-time as email is being received. The receiving mail server has to pause the SMTP transaction, query DNS, wait for responses, and then decide whether to accept the message. This all needs to happen quickly.

Without a limit, a malicious (or poorly configured) SPF record could trigger hundreds of DNS queries, effectively turning SPF evaluation into a denial-of-service vector. The 10-lookup limit keeps SPF evaluation fast and prevents abuse of receiving servers' resources.

What Counts Toward the Limit

Every DNS-dependent mechanism and modifier in your SPF record (and any nested SPF records) counts as at least one lookup.

Mechanisms That Count

Mechanisms That Don't Count

This distinction is critical. ip4 and ip6 mechanisms are "free" — you can add as many as you need without affecting your lookup count. This is why replacing include mechanisms with explicit IPs (when possible) is the most effective way to reduce lookups.

How to Count Your Lookups

Counting lookups isn't as simple as counting include statements. You need to follow the entire chain of nested records.

Example Walkthrough

Let's count the lookups for this record:

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

Level 0 (your record):

• include:_spf.google.com — 1 lookup
• include:sendgrid.net — 1 lookup
• ip4:203.0.113.50 — 0 lookups
• -all — 0 lookups

Level 1 (Google's record: _spf.google.com): Google's SPF record typically contains:

v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

• 3 more include lookups

Level 2 (Google's netblocks): Each _netblocks record contains only ip4 and ip6 mechanisms — 0 additional lookups.

Level 1 (SendGrid's record: sendgrid.net): SendGrid's SPF record typically contains:

v=spf1 ip4:... ip4:... ip4:... ~all

• 0 additional lookups (all ip4)

Total: 1 + 1 + 3 + 0 + 0 = 5 lookups. Well within the limit.

Common Provider Lookup Costs

Not all include mechanisms cost the same number of lookups. Some providers have deeply nested records while others keep it simple.

Budget Planning

With 10 lookups total, here's what typical combinations look like:

• Google + SendGrid = ~5 lookups (5 remaining)
• Microsoft + Amazon SES = ~4 lookups (6 remaining)
• Google + SendGrid + Zendesk = ~7 lookups (3 remaining)
• Google + Microsoft + SendGrid + Mailchimp = ~9 lookups (1 remaining)
• Google + Microsoft + Salesforce + SendGrid + Zendesk = ~12 lookups (over the limit)

That last combination is a real scenario many companies face. Five email services isn't unusual — but it breaks SPF.

Strategies to Stay Under the Limit

1. Replace Includes with IP Addresses

If a service gives you dedicated sending IPs, use ip4 instead of include:

# Before: 1+ lookups
include:sendgrid.net

# After: 0 lookups
ip4:167.89.123.45 ip4:167.89.123.46

The downside: if the service changes its IPs, your SPF record breaks until you update it. This works best for services with stable, dedicated IPs.

2. Remove Unused Services

Audit your SPF record every quarter. Services get added when someone sets up a new tool, but they rarely get removed when the tool is decommissioned. That unused include:old-crm-vendor.com is wasting a lookup.

3. Use Subdomains for Different Services

Instead of sending all email from example.com, split by function:

• example.com — Google Workspace (employee email)
• mail.example.com — SendGrid (transactional)
• marketing.example.com — Mailchimp (campaigns)
• support.example.com — Zendesk (helpdesk)

Each subdomain gets its own SPF record with its own 10-lookup budget. This is the cleanest architectural solution.

4. Consolidate Providers

Do you really need both SendGrid and Amazon SES? Could your helpdesk use your main email provider's SMTP relay instead of its own sending infrastructure? Fewer providers means fewer includes.

5. Use redirect for Shared Policies

If you manage multiple domains with the same sending sources, use redirect to point them all at a single SPF record. This doesn't reduce lookups per domain, but it simplifies management.

6. SPF Flattening

Flattening resolves all include mechanisms into their underlying ip4 and ip6 addresses, eliminating DNS lookups. But it comes with significant trade-offs.

The Void Lookup Limit

In addition to the 10-lookup limit, there's a lesser-known limit on "void lookups." A void lookup is a DNS query that returns no records (NXDOMAIN or empty). RFC 7208 recommends a limit of 2 void lookups.

This happens when:

• An include references a domain with no SPF record
• An a or mx query returns no results
• A domain in your record no longer exists

Exceeding this limit produces a permerror, just like exceeding the 10-lookup limit.

The MX Lookup Sub-Limit

The mx mechanism has its own limit: the MX query can return at most 10 MX record entries. If a domain has more than 10 MX records (extremely rare), only the first 10 are processed.

Additionally, each MX hostname needs to be resolved to an IP, and those resolutions count toward the overall 10-lookup limit.

What Happens When You Hit the Limit

When a receiving server reaches the 10th DNS lookup during SPF evaluation and still has more mechanisms to check, it stops and returns permerror. Here's what that means:

• SPF completely fails for every email from your domain
• DMARC evaluation treats it as an SPF failure
• Receiving servers may reject, quarantine, or spam-folder your email depending on their policies and your DMARC setting
• No partial credit — it doesn't matter if the first 9 lookups would have produced a pass. Once the limit is hit, it's over.

Monitoring Your Lookup Count

Your lookup count can change without you doing anything. A provider updates their SPF record, adds a new include, and suddenly you're at 11 lookups.

Best practices for monitoring:

• Check your SPF lookup count at least monthly with SPF Record Check
• Set up alerts if your count reaches 8 or higher
• Review DMARC aggregate reports for permerror results
• Re-check after any change to your SPF record or when a provider announces infrastructure changes
• Make sure DKIM is also configured as a fallback when SPF has issues

Monitor Your New SPF Record

You've created your SPF record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.