Fix SPF PermError and Multiple SPF Records

Last reviewed: July 13, 2026 · Written by Email Solutions

SPF tells receivers which hosts may send mail for your domain. When the published record is wrong, evaluation fails — and authenticated delivery collapses even if "you have an SPF record."

Check your live TXT set anytime on the free deliverability report.

Primary technical reference: RFC 7208. Google's operational expectations for senders are in the email sender guidelines.

The three failure modes

1. Multiple SPF records (very common)

DNS must expose at most one TXT record whose value starts with v=spf1 for the domain (or subdomain) being evaluated. Two GoDaddy or Namecheap TXT rows both starting with v=spf1 produce a hard fail even if each string looks fine alone.

Before (broken):

v=spf1 include:secureserver.net -all
v=spf1 include:_spf.google.com ~all

After (merged):

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

Only keep includes you still need. Delete the duplicate TXT rows after you merge.

2. PermError from too many DNS lookups

SPF evaluation stops after 10 DNS lookups (include, a, mx, ptr, exists, and redirect mechanisms all count toward the limit). Nested vendor includes burn the budget quickly when you stack Google + Microsoft + ESP + CRM.

Symptoms:

• Tools report PermError
• Soft-looking SPF strings that still fail in production
• Intermittent pass/fail as you add another marketing tool's include

Fixes that work in practice:

1. Drop unused include: mechanisms
2. Prefer vendors that offer flat IP mechanisms or dedicated authenticated domains
3. Move high-volume marketing to a subdomain (mail. / em.) with its own SPF so the corporate apex stays small

3. Syntax / evaluation errors

Examples we clean up on client domains:

• Typos: iclude: instead of include:
• Broken quoting when a registrar splits long TXT strings incorrectly
• Mixing -all and ~all across duplicates so nobody knows which policy applies
• Publishing SPF on www while mail uses the apex @

How to inventory your current SPF

dig +short TXT example.com

Look for every line containing v=spf1. Also check subdomains that send mail (mail.example.com, ESP CNAMEs, etc.).

In registrar panels (GoDaddy DNS Management, Namecheap Advanced DNS, Cloudflare DNS):

1. Filter TXT at @
2. Write down every include before deleting anything
3. Build one merged string
4. Save, wait for TTL, dig again

Merge recipe for Google Workspace + extras

Workspace baseline:

v=spf1 include:_spf.google.com ~all

Microsoft 365 baseline:

v=spf1 include:spf.protection.outlook.com -all

Never publish both as separate TXT records. If you truly send from both systems on the same From domain, merge includes into one string and test — dual-stack orgs often use separate domains or subdomains instead.

Billing tools (Stripe, QuickBooks) and storefronts (Shopify) often need their own authorized senders. Shopify usually expects CNAME records from the Shopify admin, not a blog-generic SPF include — see Shopify email authentication.

Verify the fix

1. Confirm a single v=spf1 TXT returns for the sending domain
2. Send a test message and inspect Authentication-Results for spf=pass
3. Re-scan with /report
4. Watch for Gmail SMTP codes related to SPF failures on bulk traffic (Google documents authentication-related 5.7.x codes in sender troubleshooting materials)

When to stop DIY

If PermError persists after a merge, the lookup tree from vendor includes is usually the culprit. We flatten and republish SPF (plus DKIM/DMARC) through the onboarding / 1-Click Fix flow, or as part of registrar-specific landings like GoDaddy spam fix.