SPF Include Chain Limits: Why You Might Be Hitting PermError

If your email deliverability has suddenly taken a nosedive, or you're seeing mysterious permerror results in your DMARC reports, there's a good chance your SPF record is breaking a rule most people don't know exists: the 10 DNS lookup limit.

It's one of the most common — and most misunderstood — SPF issues affecting New Zealand businesses today. Let's break down what's happening, why it matters, and how to fix it.

What Is the SPF 10 Lookup Limit?

RFC 7208 (the SPF specification) states that an SPF record must not require more than 10 DNS lookups to fully evaluate. This rule exists to prevent denial-of-service attacks via recursive SPF queries.

If a receiving mail server hits more than 10 lookups while processing your SPF record, it stops and returns:

spf=permerror (SPF permanent error: too many DNS lookups)

When this happens, your SPF record is effectively invalid. That means:

  • Receiving servers may reject or quarantine your mail
  • DMARC alignment fails
  • Your legitimate mail looks suspicious to spam filters

Which SPF Mechanisms Count as Lookups?

Not every part of your SPF record triggers a DNS lookup. Here's what does:

  • include: — each one counts, plus any nested includes
  • a — counts as 1
  • mx — counts as 1 (plus 1 per MX record returned)
  • ptr — counts (and should be avoided entirely)
  • exists: — counts as 1
  • redirect= — counts as 1

What doesn't count:

  • ip4: and ip6: mechanisms
  • all, +all, -all, ~all
  • The initial lookup for your own domain's SPF record

A Real-World Example

Let's say you're a Wellington-based business using Microsoft 365, Xero for invoices, Mailchimp for newsletters, and a CRM like HubSpot. Your SPF record might look like this:

v=spf1 include:spf.protection.outlook.com include:_spf.mailchimp.com include:mail.xero.com include:_spf.hubspot.com include:sendgrid.net -all

Looks harmless, right? But here's the catch — each of those include: statements can trigger multiple nested lookups:

  • spf.protection.outlook.com → 3 lookups
  • _spf.mailchimp.com → 2 lookups
  • mail.xero.com → 2 lookups
  • _spf.hubspot.com → 3 lookups
  • sendgrid.net → 2 lookups

Total: 12 lookups. Permerror.

And because vendors change their SPF records without warning, a record that worked fine six months ago can silently break today.

Why This Happens So Often in NZ

Kiwi businesses tend to stack multiple cloud services: accounting platforms, local e-commerce tools, marketing suites, transactional email providers, and support desk software. Each one wants to send email on your behalf, and each one hands you another include: to paste into your DNS.

Before long, you've chained together 5–7 includes, each with their own sub-includes, and you're well past the limit.

How to Diagnose an SPF PermError

1. Check your DMARC aggregate reports

Look for spf=permerror in the authentication results. This is the clearest signal.

2. Count your lookups manually

Use dig or an SPF checker to flatten the chain and count every DNS query required.

3. Watch for intermittent failures

Permerror doesn't always cause immediate bounces — some receivers are lenient. But Gmail, Outlook, and Yahoo increasingly enforce strict SPF evaluation.

How to Fix SPF PermError: 5 Practical Steps

1. Audit What's Actually Sending Mail

Pull your last 30 days of DMARC reports and list every sending source. You'll often find old vendors you forgot to remove — like a newsletter tool you stopped using two years ago.

2. Remove Unused Includes

This is the fastest win. If a service isn't sending mail anymore, delete its include: immediately.

3. Use Subdomains for Bulk Senders

Instead of stuffing everything into your root domain's SPF record, delegate bulk sending to subdomains:

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

Then for marketing:

newsletter.yourbusiness.co.nz  TXT  "v=spf1 include:_spf.mailchimp.com -all"

This keeps your primary SPF lean and isolates each sender.

4. Replace Includes With IP Ranges (Carefully)

Some vendors publish static IP ranges. You can replace an include: with direct ip4: entries, which don't count toward the lookup limit:

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 -all

Warning: only do this if the vendor explicitly publishes stable IP ranges. Otherwise you'll break mail when they change infrastructure.

5. Use SPF Flattening — With Caution

SPF flattening tools resolve all your includes into a static list of IPs. This eliminates lookup issues but requires ongoing monitoring — if a vendor adds new sending IPs, your flattened record won't know.

Flattening is a valid tool, but it's not "set and forget."

Common Mistakes to Avoid

  • Stacking multiple -all or ~all mechanisms — only one should appear, at the end
  • Using ptr — deprecated, slow, and unreliable
  • Copying vendor setup guides blindly — they assume you have no other senders
  • Forgetting to update SPF when changing providers — leaves dead includes consuming lookups

The Bigger Picture

SPF permerror isn't just a technical nuisance — it undermines your entire email authentication stack. DMARC relies on SPF (and DKIM) alignment to work. If SPF is broken, DMARC enforcement weakens, BIMI won't display your logo, and phishers have an easier time spoofing your domain.

Getting SPF right is foundational to protecting your brand and ensuring your mail reaches the inbox.

Check Your SPF Record in Seconds

Not sure if your domain is hitting the 10 lookup limit? Try xteam's free MailCheck tool — it analyses your SPF, DKIM, and DMARC setup, counts your DNS lookups, flags permerrors, and gives you plain-English recommendations tailored to NZ businesses.

Run a free check on your domain today, and stop losing email to silent SPF failures.