How to Fix SPF PermError in 2026

Published June 3, 2026 · 4 min read · spFlat!

If your SPF record exceeds the 10-DNS-lookup limit, receiving mail servers will reject it with a PermError — a permanent error. Your email doesn't get a soft fail. It gets a hard stop.

Here's what causes it, how to detect it, and how to fix it for good.

What is SPF PermError?

SPF (Sender Policy Framework) lets domain owners specify which mail servers are authorized to send email on their behalf. The SPF specification (RFC 7208) imposes a hard limit of 10 DNS lookups during SPF evaluation.

When your record exceeds this limit, the receiving mail server returns a PermError and stops processing the SPF check entirely. The result varies by receiver:

• Strict receivers (Gmail, Outlook.com) — treat it as SPF fail
• Lenient receivers — treat it as neutral or softfail
• Either way — your deliverability takes a hit

Why does this happen?

The 10-lookup limit is easy to hit because SPF include: statements count as one lookup each — but they can also nest more lookups inside them.

Common culprits:

• Google Workspace (include:_spf.google.com) — adds ~4-5 lookups internally
• Microsoft 365 (include:spf.protection.outlook.com) — adds ~2-3 lookups
• Mailchimp, SendGrid, Mailgun, Mandrill, HubSpot, Salesforce — each adds at least 1 lookup
• Custom a: or mx: mechanisms with multiple A/AAAA records

A typical mid-size company using Gmail, Outlook, Mailchimp, and one CRM is already at 8-12 lookups on paper — but the actual chain often goes well past 15 once nested includes are resolved.

How to detect it

Option 1: Use the SPFlat checker (free, no signup)

Go to spflat.cloud, enter your domain, and hit Check. The tool resolves your full SPF chain including all nested includes and shows you exactly how many lookups you're consuming.

Option 2: Manual dig chain

dig TXT yourdomain.com +short | grep -o 'include:[^ ]*' | while read inc; do
  dig TXT ${inc#include:} +short
done

This gives you a rough count but misses nested recursion unless you script deeper loops.

Option 3: Online SPF validators

Tools like dmarcian.com or mxtoolbox.com can help, but many cap at 10 lookups and stop resolving — which gives you a false sense of security.

How to fix it (the hard way)

If you want to do this manually:

1. Resolve every include:, a:, mx:, and ptr: in your record
2. Collect all resulting IP addresses and CIDR ranges
3. Build a new record with only ip4: and ip6: mechanisms
4. Publish it in your DNS

Before:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mailgun.org ~all

After manually flattening:

v=spf1 ip4:209.85.128.0/17 ip4:40.92.0.0/15 ip4:209.61.151.0/24 ~all

How to fix it (the smart way)

This is exactly what SPFlat solves:

1. Check your domain on spflat.cloud — see your current lookup count instantly
2. Add your domain to SPFlat with your current includes
3. Publish one DNS record — SPFlat monitors provider IP changes 24/7 and keeps your record updated automatically

No manual lookups. No spreadsheets tracking IP changes. No late-night debugging when Google rotates their ranges.

Prevention

Once your SPF is flattened, keep it clean:

• Add new email services through SPFlat — don't modify the TXT record directly
• Monitor DMARC reports — a sudden dip in SPF-aligned messages is often the first sign of a provider IP change
• Use automated monitoring — SPFlat watches your records with 99.9% uptime across 12 global locations

SPF vs DKIM vs DMARC: What Each One Actually Does

Published June 3, 2026 · 6 min read · spFlat! Blog

If you've ever set up email authentication for a domain, you've come across three acronyms: SPF, DKIM, and DMARC. They're often mentioned in the same breath, but they do fundamentally different things.

The confusion is understandable. They all live in DNS, they all protect your email reputation, and they all need to work together. But confusing one for another is like confusing a lock, a key, and a security camera — they work as a system, but they're not the same thing.

Here's what each one actually does, in plain language.

The Short Version

You need at least SPF or DKIM passing for DMARC to work. And if you want reliable email delivery, you need all three.

SPF: The Visitor List

Sender Policy Framework is a DNS record that lists which IP addresses are allowed to send email for your domain. It's the oldest of the three (RFC 4408, 2006) and the most straightforward.

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

When a receiving server gets an email claiming to be from yourdomain.com, it looks up your SPF record and checks if the sending server's IP is on the list.

What SPF does well:

• Stops simple domain spoofing
• Fast to check — receivers can reject at the SMTP level
• Well-understood and widely supported

What SPF does not do:

• It does not sign or encrypt the message
• It does not prevent a legitimate sender's email from being forwarded and then failing (this is called "SPF breakage on forward")
• It does not tell receivers what to do when the check fails

DKIM: The Wax Seal

DomainKeys Identified Mail uses public-key cryptography to sign your outgoing emails. You generate a key pair, put the public key in a DNS record (selector._domainkey.yourdomain.com), and your mail server signs each outgoing message with the private key.

default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."

When a receiver gets your email, it looks up the public key in your DNS, decrypts the signature, and checks if the message body and headers match. If they do, the email is DKIM-verified.

What DKIM does well:

• Proves the email wasn't altered in transit
• Survives email forwarding (SPF breaks, DKIM doesn't)
• Provides a cryptographic layer SPF can't match

What DKIM does not do:

• It does not verify the sender — only the signature. An attacker can set up DKIM for their own domain and sign emails that still claim to be from yours (though they'd fail DMARC alignment)
• It does not prevent someone from sending unsigned email using your domain
• It does not tell receivers what to do on failure

DMARC: The Policy Maker

Domain-based Message Authentication, Reporting & Conformance is the layer that sits on top of SPF and DKIM. It tells receiving mail servers: "If an email claiming to be from my domain fails SPF and DKIM, here's what you should do with it."

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100

DMARC also introduces the concept of alignment: even if SPF or DKIM pass individually, the domain in the From: header must align with the domain used in the SPF check or DKIM signature. This prevents a sophisticated attack where someone sends from yourdomain.com using their own authenticated server.

Three DMARC policies:

• p=none — monitor only. No action taken. Used for gathering data before enforcing
• p=quarantine — mark failing emails as spam
• p=reject — reject failing emails outright. The strongest policy

What DMARC does well:

• Gives you control over how receivers handle unauthenticated email
• Provides daily/weekly reports (rua) showing who's sending email using your domain
• Essential for brand protection against exact-domain spoofing

What DMARC does not do:

• It does not authenticate email itself — it relies on SPF and DKIM results
• It does not fix broken SPF or DKIM configurations
• It does not help if SPF PermErrors silently invalidate your SPF checks

How they work together

Think of it as a three-layer system:

1. SPF checks who sent it (server IP)
2. DKIM checks what was sent (message integrity)
3. DMARC decides what to do when something's wrong

For DMARC to pass, an email needs at least one of SPF or DKIM to pass and be aligned with the domain in the From: header.

This is why you sometimes see emails pass DMARC even when SPF fails — DKIM was valid and aligned, which is enough. And conversely, an email can pass SPF but fail DMARC if there's no DKIM signature and the SPF domain doesn't align with the From: domain.

The most common mistakes

1. SPF is broken but you don't know it.
   This happens constantly. The record validates syntactically, so DNS tools report "OK", but nested includes push it past 10 lookups. Every SPF check returns PermError. Your DMARC reports show a shocking amount of SPF-fail mail you never knew about.
2. DMARC at p=reject with no monitoring.
   If you flip to reject before confirming all your legitimate senders pass authentication, you will silently lose email. Start at p=none, read your reports, then step up.
3. DKIM selector rot.
   DKIM keys can expire or get rotated without updating your DNS. A selector that worked last year may return NXDOMAIN today, breaking DKIM verification for any email still signed with the old key.
4. Third-party senders not covered.
   You set up DMARC for your domain, but your CRM sends marketing email through a different subdomain with no SPF or DKIM. Those emails fail authentication entirely.

Where to start

If you're setting this up for the first time or auditing an existing configuration:

1. Check your SPF record — get the full lookup count including nested includes
2. Verify DKIM is publishing correctly for each email service you use
3. Start DMARC at p=none with a report address (rua) you actually check
4. Review reports for 2-4 weeks before moving to p=quarantine or p=reject
5. Monitor continuously — provider IP changes, key rotations, and new services all affect your authentication chain