SPF Permerror: Causes and Solutions

What SPF Permerror Means

When a receiving server evaluates your SPF record and encounters a permerror, it means the record is permanently broken. The server can't determine whether to pass or fail the sender — it's simply unable to complete the check.

This differs from temperror, which happens when DNS is temporarily unreachable. Permerror means something is structurally wrong with your record itself.

Common Causes

1. Exceeding 10 DNS Lookups

SPF has a hard limit of 10 DNS lookups per evaluation. These mechanisms count toward the limit:

• include: — 1 lookup + any lookups in the included record
• a — 1 lookup
• mx — 1 lookup + lookups for each MX record
• ptr — 1 lookup (don't use this)
• redirect= — 1 lookup

These do not count:

• ip4: and ip6: — direct IPs, no lookup
• all — no lookup

When your record exceeds 10 total lookups (including nested includes), you get permerror.

Example: If your record has include:_spf.google.com (2 lookups), include:spf.protection.outlook.com (1 lookup), include:sendgrid.net (1 lookup), include:mailgun.org (2 lookups), include:amazonses.com (1 lookup), and a few more — you're over the limit.

Practitioner note: I see this constantly with agencies running multiple ESPs. Every new tool adds an include, and nobody counts. By the time they call me, they're at 15+ lookups and wondering why authentication randomly fails.

2. Syntax Errors

Common syntax mistakes that cause permerror:

# Missing mechanism before ip4
v=spf1 ip4:192.168.1.1 include:_spf.google.com all
# Should be: ~all or -all

# Typo in mechanism
v=spf1 includ:_spf.google.com -all
# Should be: include:

# Invalid IP format
v=spf1 ip4:192.168.1 -all
# Should be: ip4:192.168.1.0/24 or ip4:192.168.1.1

# Multiple SPF records (creates error)
# Record 1: v=spf1 include:_spf.google.com -all
# Record 2: v=spf1 include:sendgrid.net -all
# Must combine into ONE record

3. Void Lookup Limit (More Than 2)

A "void lookup" happens when a DNS lookup returns zero results. SPF allows a maximum of 2 void lookups before returning permerror.

This happens when you include a domain that:

• Has no SPF record
• Points to a non-existent hostname
• Returns NXDOMAIN

Example: include:old-service.example.com where that record no longer exists.

4. Recursive Loops

If your SPF record includes a domain that includes back to you (directly or through a chain), you get permerror.

# yourdomain.com SPF:
v=spf1 include:partner.com -all

# partner.com SPF:
v=spf1 include:yourdomain.com -all

# This creates an infinite loop = permerror

How to Diagnose

Step 1: Check Your Record

Use MXToolbox SPF Lookup or dmarcian SPF Surveyor:

1. Enter your domain
2. Look for "permerror" in results
3. Note the specific error message

Step 2: Count DNS Lookups

MXToolbox shows total lookups. If you're at 10+, that's your problem.

To manually count:

1. List every include:, a, mx, ptr, and redirect=
2. For each include, recursively count its lookups
3. Sum everything

Step 3: Validate Syntax

Check for:

• Missing v=spf1 at the start
• Missing mechanism before qualifier (-all, ~all)
• Typos in mechanism names
• Invalid IP ranges

How to Fix

Fix 1: Flatten Your SPF Record

Replace include: mechanisms with direct IP addresses:

Before:

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:168.245.0.0/16 -all

The downside: you must update IPs when ESPs change them. Use tools like Auto SPF or dmarcian to automate this.

Practitioner note: Manual flattening works until it doesn't. I've had clients break their email when an ESP quietly added new IPs. If you flatten, set calendar reminders to verify quarterly — or use a dynamic solution.

Fix 2: Remove Unnecessary Includes

Audit every include:

• Is this ESP still in use?
• Is this service still sending email?
• Can multiple services be consolidated?

Often, old includes from cancelled services linger in SPF records.

Fix 3: Use Subdomains

Move different senders to subdomains with their own SPF records:

• marketing.yourdomain.com — marketing ESP
• transactional.yourdomain.com — transactional ESP
• yourdomain.com — primary email (Google/Microsoft)

Each subdomain gets its own 10-lookup limit.

Fix 4: Fix Syntax Errors

Correct the specific syntax issue:

• Combine multiple SPF records into one
• Fix typos in mechanism names
• Ensure valid IP formats
• Add missing qualifiers

Fix 5: Remove Dead Includes

If you have includes pointing to non-existent domains, remove them. Check each include manually to verify the target still exists and has an SPF record.

Prevention

1. Document your SPF record — keep a list of every include and why it's there
2. Audit quarterly — count lookups and verify all includes resolve
3. Test before publishing — use MXToolbox to validate before DNS changes
4. Monitor DMARC reports — SPF failures show up in aggregate reports

If you're dealing with complex multi-ESP infrastructure and can't figure out how to stay under the lookup limit, schedule a consultation — I'll help you architect an SPF strategy that actually works.

Sources

• RFC 7208: Sender Policy Framework (SPF)
• MXToolbox SPF Lookup
• dmarcian SPF Surveyor
• Google: SPF record syntax

---

v1.0 · March 2026