Fix SPF PermError: Too Many DNS Lookups

What This Error Means

An SPF "too many DNS lookups" PermError means your SPF record exceeds the 10-lookup limit defined in RFC 7208, causing every email you send to fail SPF authentication. This is not a temporary glitch. The error persists until you reduce the lookup count in your SPF record, either by removing unnecessary includes or by using SPF flattening to consolidate them.

The 10-lookup limit is defined in RFC 7208 Section 4.6.4 and is enforced by every major email provider, including Gmail, Microsoft 365, and Yahoo.

Why the SPF Lookup Limit Matters

A PermError does not just mean "SPF failed" — it means SPF cannot be evaluated at all. The consequences are significant:

Even if some emails still get through via DKIM alignment, a broken SPF record signals to receiving servers that your domain's email authentication is misconfigured. This is especially damaging if you are subject to the bulk sender requirements from Gmail, Yahoo, and Microsoft, which set strong authentication expectations that vary by provider and traffic profile.

How to Check Your SPF Lookup Count

Use the mxio SPF Checker to see exactly how many DNS lookups your SPF record uses. The tool traces every include:, a:, mx:, redirect=, and exists: mechanism, including nested lookups inside included records.

Enter your domain and look for the Lookup Count in the results. If it shows 10 or fewer, your record is within limits. If it exceeds 10, follow the fix steps below.

Which SPF Mechanisms Count as DNS Lookups?

Not all SPF mechanisms trigger DNS lookups. Here is the breakdown:

Counts against SPF's 10-term DNS-lookup budget (mechanisms like mx can trigger multiple DNS queries during evaluation):

• include: — Fetches and evaluates another SPF record
• a: or a — Resolves A/AAAA records
• mx: or mx — Resolves MX records, then A records for each MX host
• redirect= — Fetches and evaluates another SPF record
• exists: — Checks if a DNS record exists

Does NOT count:

• ip4: — Direct IP comparison, no DNS query
• ip6: — Direct IP comparison, no DNS query
• all — Match-all mechanism, no DNS query

The critical detail: Lookups are recursive. If your SPF record includes _spf.google.com, and Google's record itself has 3 includes, that's 4 total lookups (1 for the initial include + 3 for Google's nested includes). This is why modern email setups hit the limit so easily.

How to Fix SPF Too Many Lookups

Audit Your SPF Record

List every include: in your SPF record and check if each service is still actively sending email on your behalf. Common culprits of unnecessary includes:

• Old marketing platforms you no longer use (Mailchimp, Constant Contact)
• Previous email providers after a migration (e.g., old Google Workspace includes after moving to Microsoft 365)
• Development/staging services that shouldn't be in the production SPF record
• Duplicate includes that cover the same IP ranges

Remove any includes that are no longer needed.

Consolidate IP Ranges Where Possible

Some providers share IP ranges. For example, if you use both Mailgun and another Rackspace-owned service, their IP ranges may overlap. In these cases, you can sometimes replace two includes with specific ip4: mechanisms that cover both.

Check your provider documentation or ask their support team which IP ranges they actually use.

Use Managed SPF for Permanent Resolution

If you legitimately need many sending services, SPF flattening is the permanent solution. Flattening replaces include: mechanisms with their resolved IP addresses, reducing your lookup count dramatically — often to just 1 or 2 lookups. mxio's Managed SPF handles this automatically: it resolves your includes, publishes a single optimized record, and updates it whenever provider IP ranges change. See What Is SPF Flattening? for a full explanation of the technique.

# Before flattening (7+ lookups):
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.mailchimp.com ~all

# After flattening (1 lookup):
v=spf1 include:_spf.mxio.io ~all

Warning: Manual flattening (copying IP addresses directly into your TXT record) is dangerous. Provider IP ranges change without notice — Google, Microsoft, and SendGrid all rotate IPs regularly. A stale flattened record silently breaks your email authentication. Always use an automated service that monitors and updates IPs continuously.

Verify the Fix

After making changes, run the mxio SPF Checker again to confirm your lookup count is within limits. Also verify that all your legitimate sending services are still authorized by sending test emails and checking the Authentication-Results headers.

Common SPF Include Mechanisms and Their DNS Lookup Costs

As you can see, Google + Microsoft alone can consume 5-7 of your 10 lookups. Add two more SaaS tools and you're over the limit.

Prevention and Ongoing SPF Monitoring

The lookup limit is not a one-time problem. Every time you add a new sending service or a provider changes their SPF record structure, your count can shift. To prevent future PermErrors:

1. Set up domain health monitoring — Use the mxio Domain Health tool to get alerts when your SPF lookup count approaches 10 or when your record changes unexpectedly
2. Document your sending services — Maintain a list of every service authorized to send email for your domain
3. Use Managed SPF — Let automated flattening handle provider IP changes for you. mxio's Managed SPF monitors your includes and republishes an optimized record whenever provider IPs change.
4. Test before changes go live — Always run the mxio SPF Checker to check the lookup impact before adding a new include:

Related Issues

• Multiple SPF Records on One Domain — Another common SPF misconfiguration that causes PermErrors
• SPF ~all vs -all: Softfail vs Hardfail — Choosing the right SPF enforcement level
• What Is SPF Flattening? — Deep dive into how SPF flattening works and why automation matters
• Why Is DMARC Failing? — SPF failures often cascade into DMARC failures
• Email Authentication Guide — How SPF, DKIM, and DMARC work together