The SPF 10 DNS Lookup Limit Explained

SPF records are limited to 10 DNS lookups. If your record exceeds this limit, it returns a “permerror” and SPF fails for all your email. This isn’t a soft limit or a warning—it’s a hard stop defined in RFC 7208.

Most organizations hit this limit when they add multiple third-party senders: Google Workspace, Microsoft 365, a marketing platform, a CRM, transactional email… each one adds an include: statement, and each include can trigger multiple nested lookups.

Why the 10 Lookup Limit Exists

The limit exists to prevent denial-of-service attacks and infinite loops. Without it, a malicious SPF record could force receiving mail servers to perform thousands of DNS queries for every incoming email.

When a mail server checks your SPF record, it follows every include:, a:, mx:, ptr:, and redirect: mechanism. Each of these requires at least one DNS lookup. Nested includes compound the problem—if your record includes SendGrid, and SendGrid’s record includes three other domains, that’s four lookups just for SendGrid.

What Counts Toward the Limit

These mechanisms require DNS lookups:

• include: — looks up another domain’s SPF record
• a: — looks up A records for a domain
• mx: — looks up MX records (and then A records for each MX)
• ptr: — reverse DNS lookup (avoid this entirely—it’s slow and unreliable)
• redirect= — looks up another domain’s SPF record

These mechanisms do NOT count:

• ip4: — direct IP address, no lookup needed
• ip6: — direct IPv6 address, no lookup needed
• all — the final mechanism, no lookup

How to Check Your Lookup Count

You can check your current lookup count with online tools, but understanding what’s happening helps you fix problems faster.

Here’s what a problematic SPF record looks like:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com 
include:sendgrid.net include:spf.mailchimp.com include:amazonses.com 
include:_spf.salesforce.com include:mail.zendesk.com -all

Each include: is at least one lookup, but nested includes multiply fast:

Include	Lookups
_spf.google.com	3
spf.protection.outlook.com	2
sendgrid.net	1
spf.mailchimp.com	2
amazonses.com	1
_spf.salesforce.com	2
mail.zendesk.com	1
Total	12

This record is already over the limit before you add anything else.

Verkh monitors your SPF lookup count automatically and alerts you when you’re approaching the limit—before it becomes a permerror.

How to Fix SPF Lookup Limit Issues

You have three main options:

1. Remove Unused Includes

The simplest fix: remove services you no longer use. That old marketing platform you canceled six months ago? Its include is still consuming lookups.

Audit your SPF record against your actual sending sources. If you’re using Verkh, the sending sources dashboard shows exactly which services are actively sending as your domain.

2. Use IP Addresses Instead of Includes

If a service sends from a small, stable set of IP addresses, you can replace the include with direct ip4: entries:

# Instead of this (1+ lookups):
include:mail.zendesk.com

# Use this (0 lookups):
ip4:192.168.1.1 ip4:192.168.1.2

The downside: if the service changes their IP addresses, your email breaks until you update the record. Only do this for services with stable, documented IP ranges.

3. SPF Flattening

SPF flattening resolves all includes to their underlying IP addresses at publish time. Instead of:

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

You get:

v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 
ip4:167.89.0.0/17 ip4:168.245.0.0/17 -all

Zero DNS lookups. But there’s a catch: you need to keep the flattened record updated when providers change their IP ranges. Most people use automated tools for this.

Common Mistakes to Avoid

Don’t use ptr: — It’s deprecated, slow, and uses a lookup. Remove it if you have it.

Don’t duplicate includes — include:_spf.google.com appearing twice still counts twice.

Don’t assume nested lookups are free — An include that looks simple might resolve to a record with five more includes.

Don’t forget about subdomains — Each subdomain needs its own SPF record within the lookup limit.

When Flattening Makes Sense

SPF flattening works well when:

• You’re over the limit and can’t remove any services
• Your providers have relatively stable IP ranges
• You have automation to keep the flattened record current

Flattening is risky when:

• You’re managing it manually (you’ll forget to update it)
• Providers frequently change IPs (looking at you, AWS)
• You’re right at 10 lookups (you have room to optimize first)

The Bottom Line

The 10 lookup limit is real and enforced. Exceeding it breaks SPF completely—not partially, completely. Check your current count, remove what you don’t need, and consider flattening only if you’ve exhausted other options.

For the complete guide to fixing SPF issues, see our SPF Troubleshooting Guide.

---

Verkh monitors your SPF record continuously and alerts you when lookup counts approach the limit. Check your SPF status free at verkh.io.