SPF Permerror: How to Fix Too Many DNS Lookups Safely

An SPF permerror is a permanent SPF evaluation failure. The most common cause is too many DNS lookups (more than 10 across include, redirect, a, mx, exists, and related mechanisms). Receivers stop evaluating a valid pass/fail and treat the check as an error — which can break deliverability and DMARC alignment for real mail. SPF temperror is different: a temporary DNS or lookup failure that may clear without a permanent record change.

SPF problems are easy to underestimate because the record looks so small. One TXT value in DNS does not seem like it should break invoice emails, support notifications, or marketing campaigns. A single SPF permerror can do exactly that.

The good news is that most SPF failures are fixable. The bad news is that rushed fixes often make the situation worse by removing legitimate senders, masking root causes, or flattening records without a maintenance plan. This guide is the safe sequence: inventory first, then clean the record, then validate — with links to the full SPF setup guide, DKIM setup, and DMARC setup.

What is an SPF permerror?

A permerror (permanent error) means the receiver could not complete SPF evaluation in a way that yields pass, fail, softfail, neutral, or none. The check failed as a process, not as “this IP is not authorised.”

In practice, the top causes are:

1. Too many DNS lookups — over the hard limit of 10 DNS-driven mechanisms in one evaluation (nested includes count toward the same budget)
2. Syntax or structural problems — malformed record, multiple conflicting SPF TXT strings on the same name, broken redirect / include targets
3. Void lookups / dead includes — too many lookups that return nothing useful (void lookup limits exist alongside the 10-lookup rule)
4. Ambiguous or unusable DNS answers for mechanisms the evaluator must resolve

Depending on your mail flow and DMARC alignment, a permerror can start affecting legitimate mail immediately — especially when that sender relies on SPF-aligned paths and has weak or missing DKIM.

SPF temperror vs permerror

Result	Meaning	Typical cause	What to do
permerror	Permanent evaluation error	Lookup limit, bad syntax, unusable permanent DNS state	Fix the record / inventory; re-test
temperror	Temporary evaluation error	DNS timeout, transient resolver failure, temporary NXDOMAIN/glitch	Wait and re-check; fix only if it persists

Do not “fix” a one-off temperror by deleting includes. Confirm it is stable across tools and time, then treat it like any other DNS reliability issue. Persistent temperrors on a specific include: target may mean that vendor’s SPF host is unhealthy — open a ticket with them rather than flattening blindly.

Why “too many DNS lookups” happens

SPF has a hard limit of 10 DNS lookups across mechanisms such as:

• include
• redirect
• a
• mx
• exists
• (and other DNS-using mechanisms in the evaluation path)

Plain ip4: / ip6: mechanisms do not consume that lookup budget. Nested includes still count: one vendor include: can pull in several more lookups underneath.

The pattern that hits the limit is almost always the same. Over time, new systems are added:

• Microsoft 365
• Google Workspace
• Mailchimp, Brevo, or similar ESPs
• accounting software
• CRM tools
• support desks
• web servers or contact-form relays

Each tool comes with its own SPF include. Nobody removes old ones. Nobody checks whether two systems do the same thing. Nobody keeps a sender inventory. Then one more platform is added and the record tips over into permerror: permanent error / too many DNS lookups.

This is why SPF problems are not only DNS problems. They are change-management problems. Pair every new sender with DKIM where possible so you are not hanging all authentication on a fragile SPF chain.

How to fix an SPF record (safe cleanup checklist)

Do not edit production SPF until you can complete this list.

1. Build a sender inventory first

List every system that sends mail as your domain or subdomain. Include:

• primary mailbox provider
• newsletter platform
• billing and invoicing tools
• CRM and ticketing systems
• website forms
• internal applications
• outsourced vendors sending on your behalf

Do not edit SPF until this list exists. New SaaS tools should follow a sender onboarding checklist before they touch DNS.

2. Measure the current lookup cost

Use a checker that expands nested includes and reports lookup count (not only “valid syntax”). Note:

• total lookups under the 10 limit
• which includes are the heaviest
• whether more than one SPF TXT exists on the same host (a common permanent foot-gun)

Baseline public posture with free tools before and after changes.

3. Check what is actually in use

Some includes live in DNS long after the platform was retired. Others were published for a short proof of concept and never removed.

Ask three questions for each include:

1. Is the platform still in use?
2. Does it still send as this exact domain?
3. Is there another authenticated route already covering the same mail flow?

You are not trying to get the shortest record possible. You are trying to remove what is obsolete without touching what the business still needs.

4. Prefer DKIM support where possible

If a platform supports DKIM, that gives you a second reliable path for DMARC alignment. That matters because SPF is more fragile than DKIM in real-world mail routing (forwarding, some gateways, and list expansion often break SPF while leaving DKIM intact).

A domain with strong DKIM coverage is easier to clean up safely because one SPF mistake is less likely to destroy all alignment. Marketing senders should also map work to Gmail and Yahoo sender rules.

5. Consolidate duplicate or unnecessary mechanisms

Look for:

• duplicate includes
• unnecessary a or mx lookups (each costs budget; prefer explicit ip4/ip6 only when you own and understand the addresses)
• overlapping relay services
• vendor includes left behind after migration
• “temporary” marketing tools still authorised on the apex domain

Small cleanups add up quickly and often drop you back under 10 without flattening.

6. Flatten only if you can maintain it

SPF flattening can reduce lookups by replacing nested includes with explicit IPs. That can help, but it creates a new responsibility: when the vendor changes their sending IPs, your flattened record must be updated.

If you flatten, do it deliberately and assign ownership. A stale flattened record becomes tomorrow’s outage. Prefer vendor includes you can keep under the limit over unowned IP lists.

7. Validate before and after

Check the resulting record in a DNS lookup tool and send test messages through every major platform you kept.

You want evidence for:

• no lookup overflow (under 10)
• no syntax errors / single SPF TXT per name
• legitimate senders still pass SPF where you expect
• DMARC alignment still holds where expected (review aggregate reports)

The wrong way to fix SPF permerror

Teams under pressure often try one of these shortcuts:

• delete includes at random and hope delivery still works
• swap ~all for -all without validating senders
• flatten the record once and forget about it
• keep adding subdomains as a workaround without ownership
• paste every vendor’s sample record without merging into one SPF string

These approaches reduce confidence, not risk. -all does not fix a permerror; a broken evaluation still fails before the all mechanism helps you.

A simple before-and-after example

A typical overgrown record might look like this:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:servers.mcsv.net include:spf.mailvendor.example include:spf.crm.example include:spf.old-tool.example mx a ~all

That may be valid syntactically and still be operationally unsafe: nested lookups under each include can push the evaluator past 10 even when the apex string looks short.

A cleaned-up record is not automatically shorter because shorter is better. It is better because it reflects current, intentional mail flow — for example, retire spf.old-tool.example, drop redundant mx/a if they only double-authorise hosts already covered, and ensure remaining vendors have DKIM so DMARC does not depend solely on SPF.

After cleanup, re-check lookup count and send test mail from each remaining platform. Then watch DMARC sources for a few days using the how to read aggregate reports workflow.

Warning signs that SPF is still unmanaged

Even after one cleanup, these patterns mean the underlying process is still weak:

• no owner for DNS mail records
• marketing can add sending platforms without review
• finance tools send from the main domain without IT involvement
• subdomains are created ad hoc for “temporary” tools
• nobody reviews DMARC reports after adding a sender
• lookup count sits at 9–10 with no headroom for the next tool

If these stay true, the SPF permerror will return. Adopt a light change gate: inventory entry → SPF/DKIM validation → DMARC report check → only then production use. See the new SaaS sender onboarding checklist.

SPF and DMARC should be reviewed together

An SPF fix is incomplete if you do not check how it affects DMARC.

Questions to verify:

• If SPF fails or permerrors for a sender, does DKIM still align?
• If DKIM is missing, is SPF alignment definitely correct and under the lookup limit?
• Are reply paths, envelope senders, and visible From domains consistent with your policy expectations?
• After cleanup, do aggregate reports show the same known sources with better pass/alignment rates?

This is where many teams get surprised. They “fix SPF” and only later discover that a critical sender was passing DMARC only because of a fragile alignment path. When inventory is clean, plan policy movement with the path from p=none to p=reject.

Exact-domain spoofing is what strong DMARC targets; lookalike domains need a different control set — see lookalike domains vs spoofing.

A better operating model

The long-term answer is simple:

• maintain a sender inventory
• require review before a new platform sends as your domain
• validate SPF and DKIM before launch (SPF, DKIM)
• monitor DMARC after launch (DMARC setup + report review)
• remove sender access when a platform is retired
• leave lookup headroom so the next tool does not recreate a permerror

This is slower than copying a vendor include into DNS. It is also how you avoid repeating the same outage every quarter.

Final takeaway

An SPF permerror is a symptom. The root cause is usually unmanaged sender growth — often visible as permanent error: too many DNS lookups.

Fix the record, but also fix the process that allowed it to grow without review. Inventory first. Remove obsolete entries carefully. Prefer DKIM so alignment is not SPF-only. Flatten only if you can maintain it. Test every legitimate sender before you declare success. Distinguish temperror (temporary) from permerror (fix the published state).

If you are not sure whether your current record is already close to the lookup limit, start with a full domain check on free tools before making the next sender change. For ongoing visibility after cleanup, use Monitor; for hands-on remediation, see managed service. Full reference: how to set up SPF.