Critical SeveritySPF

Fix: SPF Too Many DNS Lookups

Your SPF record exceeds the 10 DNS lookup limit defined in RFC 7208. When an email receiver evaluates your SPF record and the lookup count exceeds 10, it returns a PermError and the SPF check fails entirely.

Quick Fix

Flatten your SPF record by replacing include mechanisms with their resolved IP addresses.

What This Error Means

Every "include", "a", "mx", "ptr", "exists", and "redirect" mechanism in your SPF record triggers a DNS lookup. The SPF specification limits the total number of these lookups to 10. When this limit is exceeded, receiving mail servers return a PermError, which means your SPF authentication fails completely — not just for the extra entries, but for all of them.

Why It Matters

An SPF PermError caused by too many lookups means none of your legitimate emails pass SPF authentication. This dramatically increases the chance your emails land in spam or are rejected outright. It also weakens your DMARC policy since SPF alignment will always fail.

Step-by-Step Fix

Check your current DNS lookup count

Use dig or nslookup to retrieve your SPF record and count each mechanism that triggers a DNS lookup. Remember that nested includes also count toward the limit.

Example

dig +short TXT yourdomain.com | grep "v=spf1"

Identify unnecessary includes

Review each include mechanism. Remove any that belong to services you no longer use for sending email. Common culprits are old marketing platforms, former CRMs, or test services.

Before

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com include:servers.mcsv.net include:sendgrid.net include:spf.sendinblue.com include:amazonses.com ~all

After

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

Flatten includes to IP addresses

For services with stable IP ranges, replace the include mechanism with explicit ip4 and ip6 mechanisms. The ip4 and ip6 mechanisms do not count toward the 10-lookup limit.

Before

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

After

v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 include:sendgrid.net include:amazonses.com -all

Verify with an SPF checker

After making changes, test your SPF record to confirm the lookup count is at or below 10. Also send a test email and check the Authentication-Results header.

Example

dig +short TXT yourdomain.com | grep "v=spf1"
# Count lookups: include, a, mx, ptr, exists, redirect each = 1 lookup
# ip4, ip6, all = 0 lookups

Common Gotchas

The 10-lookup limit includes nested lookups from includes within includes. For example, include:_spf.google.com itself triggers 3-4 additional lookups.
Flattened IP addresses can change without notice. If a provider updates their IP ranges, your flattened record becomes stale and legitimate mail may fail SPF.
Some SPF flattening services automatically update records, but they add their own include — which still counts as a lookup.

Verify Your Fix

After making changes, use our free scanner to verify the fix is working correctly. DNS changes can take up to 48 hours to propagate, but most propagate within minutes.

Frequently Asked Questions

What counts as a DNS lookup in SPF?

The mechanisms "include", "a", "mx", "ptr", "exists", and "redirect" each count as one DNS lookup. The "ip4", "ip6", and "all" mechanisms do not count. Nested includes (an include that itself has includes) also count toward the total.

Can I have more than one SPF record to get around the limit?

No. Having multiple SPF records on a domain is itself an error (PermError). You must have exactly one SPF TXT record per domain. Instead, flatten your record or remove unused includes.

How often do flattened IP addresses change?

It depends on the provider. Large providers like Google and Microsoft update their IP ranges periodically. If you flatten, you should re-check the resolved IPs at least monthly, or use an automated SPF flattening service.