SPF 10 DNS Lookup Limit: Why It Exists and How to Fix It
Learn about the SPF 10 DNS lookup limit, why exceeding it causes PermError failures, and practical solutions to optimize your SPF record.
Last updated: 2026-02-05
If you've ever seen "SPF PermError" or "too many DNS lookups" in your email authentication results, you've hit one of SPF's most frustrating limitations. The 10 DNS lookup limit causes real problems for businesses that use multiple email services, but it exists for good reasons.
What is the 10 DNS Lookup Limit?
The SPF specification (RFC 7208) limits SPF record evaluation to 10 DNS lookups. This includes lookups triggered by these mechanisms:
includeamxptr(deprecated, avoid using)redirect
It also includes any nested lookups. When you use include:_spf.google.com, that's one lookup—but Google's SPF record itself contains additional includes that each count toward your limit.
If your SPF record causes more than 10 lookups during evaluation, the result is a PermError (permanent error). This is treated as an authentication failure, which can cause your emails to be rejected or sent to spam.
PermError is serious
Unlike a soft fail that might still deliver, a PermError indicates your SPF record is fundamentally broken. Many email servers will reject emails outright when they encounter a PermError during SPF evaluation.
Why Does This Limit Exist?
The 10 lookup limit isn't arbitrary—it protects the email ecosystem from abuse.
Performance protection. Every DNS lookup takes time and resources. Without a limit, a malicious SPF record could chain hundreds of lookups, slowing down mail servers.
Denial of service prevention. An attacker could craft an SPF record that triggers endless recursive lookups, potentially overwhelming DNS infrastructure. The limit caps this risk.
Resource fairness. Email servers process millions of messages. If each message required dozens of DNS queries just for SPF checking, it would significantly increase infrastructure costs and latency.
The limit is a reasonable trade-off between flexibility and protection.
How to Count Your DNS Lookups
Counting lookups isn't as simple as counting mechanisms in your SPF record. You need to follow the chain of includes.
What counts as a lookup
| Mechanism | Counts? | Notes |
|---|---|---|
| include | Yes | Plus any lookups in the included record |
| a | Yes | One lookup for A records |
| mx | Yes | One lookup plus one for each MX server's A record |
| ptr | Yes | Avoid — expensive and unreliable |
| redirect | Yes | Treated like include |
| ip4 | No | Direct IP reference, no DNS lookup |
| ip6 | No | Direct IP reference, no DNS lookup |
| exists | Yes | One lookup per exists |
Example: Counting a typical record
v=spf1 include:_spf.google.com include:sendgrid.net mx ~all
Let's count:
include:_spf.google.com— 1 lookup, but Google's record has nested includes (~3 more)include:sendgrid.net— 1 lookup, plus any nested includes in SendGrid's recordmx— 1 lookup for MX records, plus lookups for each MX server's A record
A simple-looking record can quickly approach or exceed 10 lookups once you account for nested includes.
Common services and their lookup costs
Different email services have different lookup footprints:
| Service | Approximate Lookups |
|---|---|
| Google Workspace | 3-4 |
| Microsoft 365 | 2-3 |
| SendGrid | 1-2 |
| Mailchimp | 1-2 |
| Amazon SES | 1 |
| Salesforce | 2-3 |
| HubSpot | 1-2 |
| Zendesk | 1-2 |
These are estimates—services occasionally change their SPF structure. Use a lookup checker to get the current count.
What Happens When You Exceed the Limit
When evaluation hits the 11th lookup, the SPF check immediately returns PermError. The remaining mechanisms aren't evaluated.
Impact on email delivery:
- Some servers reject the email outright
- Others treat it as an SPF failure (similar to
-all) - Your emails may land in spam
- DMARC alignment fails if SPF was your only aligned authentication
Unlike temporary errors (TempError), a PermError doesn't prompt retries. The email is immediately classified as having broken authentication.
Solutions for the 10 Lookup Limit
If you're hitting the limit, you have several options.
1. Remove unnecessary includes
Audit your SPF record. Are all those services still in use? Common culprits:
- Old marketing platforms you no longer use
- Previous email providers from before a migration
- Test services that were never removed
- Duplicate includes for the same provider
Removing just one unused include can bring you back under the limit.
2. Use ip4/ip6 instead of includes
If a service sends from known, stable IP addresses, you can use ip4 or ip6 mechanisms instead of include. These don't count toward the lookup limit.
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all
Caution: IP addresses can change. Only use this approach if:
- The IPs are truly static
- You have a process to update them when they change
- The service explicitly supports this approach
3. Flatten your SPF record
SPF flattening replaces include statements with the actual IP addresses they resolve to. This eliminates the DNS lookups at evaluation time.
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:167.89.0.0/17 ... ~all
The catch: Flattened records become outdated when providers change their IPs. You need to regularly re-flatten or use a service that automates this.
4. Use an SPF flattening service
Several services automatically flatten and maintain your SPF record:
- They resolve your includes to IPs
- They monitor for changes
- They update your record automatically
This solves the maintenance problem but adds a dependency on the service.
5. Split by subdomain
If you can separate email streams by subdomain, each subdomain gets its own 10-lookup budget.
- Marketing emails from
mail.yourdomain.com - Transactional emails from
notify.yourdomain.com - Corporate email from
yourdomain.com
Each domain/subdomain has independent SPF records. This requires changes to your email configuration but can be effective for complex setups.
6. Consolidate email services
Sometimes the best solution is reducing complexity. Do you really need five different email services? Consolidating to fewer providers reduces lookup count and simplifies management.
Monitoring Your Lookup Count
Your SPF record isn't static. Services change their SPF configurations, which can push you over the limit without any action on your part.
What to monitor:
- Total lookup count after each change
- Regular checks even without changes (services update their includes)
- PermError reports in DMARC aggregate data
Avoiding the Problem
When adding new email services, check their SPF lookup cost before adding them. Ask yourself:
- How many lookups does this include add?
- Will this push me over 10?
- Can I use IP addresses instead?
- Is there an existing service I can remove?
Planning ahead is easier than fixing PermError issues after emails start failing.
Monitor Your SPF Records
Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.
Never miss an SPF issue
Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.
Start Monitoring