SPF Too Many DNS Lookups: How to Fix the 10-Lookup Limit

The short answer: Exceeding SPF's 10-lookup limit causes every email from your domain to fail SPF authentication with a permanent error (PermError), regardless of whether the sending server is authorised. The fix is to reduce your lookup count by removing unused senders, replacing include: statements with direct IP ranges (flattening), or using SPF subdomains. Check your current count with a free SPF Checker before making changes.

SPF has a hard limit: no more than 10 DNS lookups per evaluation. Exceed it, and every email from your domain fails SPF — regardless of whether the sending server is actually authorised. Receiving mail servers don't check who's asking. They just see permerror and apply their policy.

This is one of the most common SPF issues for businesses using multiple marketing tools, CRMs, and email services. Each one you add pushes your lookup count higher. At some point, you cross the line without realising it.

Here's how to understand the limit, identify your count, and fix it.

Why the 10-Lookup Limit Exists

SPF is evaluated in real time by receiving mail servers. To prevent performance problems, the SPF specification (RFC 7208) caps the number of DNS lookups that can occur during a single SPF check at 10. If evaluation requires more than 10 lookups, the check must return permerror — a permanent error.

This isn't a soft guideline. It's a hard rule built into the protocol.

What Counts as a DNS Lookup

Not all SPF mechanisms trigger a lookup. This is where many SPF records go wrong — a mechanism that looks simple may trigger several lookups once the chain resolves.

These mechanisms each count as one lookup (plus any lookups they trigger):

These do not count toward the limit:

The problem is nested: when you use include:_spf.google.com, that fetches Google's SPF record, which may itself contain include: statements that trigger further lookups. Those count too.

What Happens When You Exceed the Limit

When a receiving server evaluates your SPF record and hits more than 10 lookups before finishing, it returns permerror. This means:

• SPF fails permanently for that email
• If your DMARC policy is p=quarantine or p=reject, the email may be filtered or blocked
• If you're relying on SPF to pass DMARC, it won't — DKIM must also be configured correctly to compensate
• The failure affects all email from your domain, not just bulk or marketing mail — including transactional receipts, support replies, and invoices

How to Count Your Lookups

The safest way is to use a free SPF checker that automatically counts lookups and identifies which mechanisms are causing the problem. The count isn't always obvious from reading the record because nested includes multiply.

Check your SPF lookup count now — free SPF Record Checker at EmailAudit.io

If you want to count manually, trace each include: to its target domain, fetch that domain's SPF record, and count every lookup mechanism it contains. Add those to your top-level count.

Common Culprits

Businesses commonly exceed 10 lookups when they use multiple tools that each require an SPF include:

Add four or five of these to a single record and you're already at or near the limit — before accounting for any lookups their own SPF records trigger.

How to Fix It

Option 1: Remove Unnecessary Mechanisms

Start by auditing what's actually in your record. Are you still using all those services? Remove any include: for tools you no longer use. This is the simplest fix with no downside.

Also check for:

• Duplicate mechanisms (the same include listed twice)
• The ptr mechanism — deprecated and slow, remove it
• Any a or mx mechanisms that aren't strictly needed

Option 2: Replace includes with Direct IPs (SPF Flattening)

SPF flattening means resolving each include: mechanism to the underlying IP addresses it authorises, and replacing the include: with direct ip4: and ip6: statements.

Instead of:

v=spf1 include:sendgrid.net -all

You'd publish:

v=spf1 ip4:167.89.0.0/17 ip4:198.37.144.0/20 -all

Direct IPs don't count toward the lookup limit, so flattening can dramatically reduce your count.

The catch: IP addresses change. If SendGrid, HubSpot, or any other provider changes their sending IPs (which they do periodically), your flattened record becomes incorrect and those emails start failing. Flattened records require regular monitoring and updates — either manually or via a service that does it automatically.

Option 3: Use Subdomains for Different Senders

If you're sending different types of email from different services, consider using subdomains. Marketing email from mail.yourdomain.com with its own SPF record, transactional email from notify.yourdomain.com with another — each record stays well under the limit independently.

This requires changes to your sending configuration and DNS, but it cleanly solves the problem without flattening.

Rebuilding Your SPF Record

Once you've decided which mechanisms to keep, rebuild the record from scratch rather than patching the existing one. This avoids accidentally carrying over old or duplicate entries.

Generate a clean SPF record — free SPF Record Generator at EmailAudit.io

The generator lets you select your email providers, add custom includes, specify IP ranges, and choose an enforcement level — with a live lookup count shown as you add mechanisms.

After publishing the updated record, verify it with the SPF checker to confirm the lookup count is under 10 and the record passes validation.

Related Guides

• SPF, DKIM, and DMARC: What They Are and Why Every Business Needs All Three
• How to Add Mailchimp, HubSpot, or Salesforce to Your SPF Record Without Breaking It
• Why Are My Emails Going to Spam?

Not sure where your SPF record stands? Run a free Full Audit at EmailAudit.io — it checks your SPF lookup count, mechanism syntax, enforcement strength, and all other authentication records. No account required. Results in under 60 seconds.