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:

  • include
  • a
  • mx
  • ptr (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

MechanismCounts?Notes
includeYesPlus any lookups in the included record
aYesOne lookup for A records
mxYesOne lookup plus one for each MX server's A record
ptrYesAvoid — expensive and unreliable
redirectYesTreated like include
ip4NoDirect IP reference, no DNS lookup
ip6NoDirect IP reference, no DNS lookup
existsYesOne 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 record
  • mx — 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:

ServiceApproximate Lookups
Google Workspace3-4
Microsoft 3652-3
SendGrid1-2
Mailchimp1-2
Amazon SES1
Salesforce2-3
HubSpot1-2
Zendesk1-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