SPF PermError — Too many DNS lookups

What does SPF PermError mean?

SPF limits the total number of DNS-querying mechanisms to 10 per evaluation. This isn't 10 include: statements in your visible record — it's 10 total across the entire recursive chain, including every nested include inside a vendor's SPF record.

When a receiving server hits lookup 11, it stops evaluating and returns permerror. That means SPF fails — not softfail, not neutral, but a hard processing error. The receiver never gets to your -all or ~all terminator.

You'll see this in headers as:

spf=permerror

Or in bounce messages as variations of:

550 5.7.1 Message rejected because SPF check failed

550 SPF PermError - too many DNS lookups

There's also a lesser-known limit: RFC 7208 recommends no more than 2 void lookups — DNS queries that return NXDOMAIN or empty results. Stale includes pointing to decommissioned vendor domains can silently accumulate these.

DMARCit shows which services are actually sending as your domain, so you can remove unused SPF includes with confidence — and catch new ones before they push you over the limit.

Why did this happen?

Cause 1: Vendor include-chain bloat

Every SaaS vendor that sends email as your domain tells you to add an include: to your SPF record. The problem is that each include can contain nested includes of its own, and they all count toward your 10.

Example total: Google Workspace (4) + Microsoft 365 (3) + SendGrid (4) = 11 lookups → PermError

These counts can change without notice. Vendors add and restructure their own nested includes as their infrastructure evolves. A record that was safely under the limit a few months ago may be over it now without any visible change in your DNS.

Cause 2: Legacy includes that no one cleaned up

Old vendor includes accumulate. A marketing tool from two years ago that nobody uses anymore is still consuming lookups. Worse, if the vendor domain no longer exists, that include generates a void lookup — and two of those can also trigger PermError.

Cause 3: Using a, mx, or ptr mechanisms unnecessarily

Each of these counts as a DNS lookup. a and mx are often added by SPF generators when they're not needed for actual sending infrastructure. ptr is deprecated by RFC 7208 and should not be used.

Cause 4: Multiple SPF records on the same domain

If your domain has two separate TXT records both starting with v=spf1, every receiver returns PermError immediately — before even counting lookups. This usually happens when someone adds a new vendor by creating a second TXT record instead of editing the existing one.

How to fix SPF PermError

Step 1: Audit your current lookup count

Use an SPF checker that counts recursively — not just the top-level includes. You need the total across the entire chain.

While auditing, check for:

• Includes for services you no longer use.
• Includes for services that don't use your domain in the Return-Path.
• a, mx, or ptr mechanisms that aren't needed.
• Duplicate SPF records on the same domain.

Step 2: Remove what you don't need

This is the fastest fix. If a vendor isn't actively sending as your domain, remove its include. If a vendor uses its own domain in the Return-Path (like bnc.salesforce.com), your SPF include for that vendor may not contribute to DMARC alignment — often DKIM alignment is doing the work.

Step 3: Move third-party senders to subdomains

Instead of cramming every vendor into your root domain's SPF record, assign each vendor a subdomain (for example,mail.yourdomain.com or marketing.yourdomain.com). Each subdomain gets its own SPF record and its own 10-lookup budget. This scales better than flattening because each sender gets isolated budget and changes.

Step 4: Consider hosted SPF

Hosted SPF services use SPF macros to consolidate your vendor inventory into a single include that resolves dynamically. Your published SPF record stays short while the vendor handles changing IP inventories behind the scenes. DMARCit's hosted SPF keeps your record under the lookup limit automatically.

Step 5: Be cautious with SPF flattening

Flattening replaces includes with raw IP addresses, reducing lookups but creating maintenance burden. When vendors rotate sending IPs, flattened records go stale and legitimate mail fails. If you flatten, it must be continuously re-resolved and monitored to catch drift.

This isn't a one-time fix

Email authentication tends to break again because:

• Every new SaaS tool is a potential PermError. If you're already near 10 lookups, one new include can push you over.
• Vendor SPF records change underneath you. You don't control what's insideinclude:_spf.google.comorinclude:sendgrid.net.
• Flattened records go stale silently. Every vendor IP rotation can trigger failures with no immediate alert.
• People forget to remove old includes.Offboarding rarely includes SPF cleanup. Stale entries can consume lookups and create void lookups.

Keeping SPF healthy requires monitoring — not just at setup, but continuously.