SPF "Too Many DNS Lookups": What It Means and How to Fix It

Last updated: October 2026

Your SPF checker is flashing red: "Too many DNS lookups" or "SPF permerror." Your record looks fine — every sender is listed, the syntax is right — yet receivers treat SPF as failed. This is one of the most common ways business email authentication silently breaks, and it happens to well-maintained domains: not because anyone made a typo, but because the record grew past a hard limit that most setup guides never mention.

The rule: 10 lookups, total, including the hidden ones

SPF is defined by RFC 7208, and section 4.6.4 sets the rule: evaluating an SPF record may trigger at most 10 DNS lookups from mechanisms and modifiers that require them. The ones that count:

• include: — and every lookup-able mechanism inside the included record counts too, recursively
• a, mx, ptr (deprecated — don't use it), exists:, and redirect=

Not counted: ip4:, ip6: and all — they need no lookup. Exceed 10 and the result is a permerror: receivers treat SPF as failed, DMARC loses one of its two legs, and spam filters draw their own conclusions. There's no partial credit and no warning email — the record just stops working.

What the big senders actually cost (counted from live DNS)

Most guides wave at "about 1 lookup per include." That's wrong where it matters: the cost of an include is 1 plus whatever is inside that platform's record. We resolved the live records in October 2026 and counted recursively:

• Google Workspace — include:_spf.google.com = 1. Google's record is pure IP ranges with no nested includes.
• Microsoft 365 — include:spf.protection.outlook.com = 1. Same story: IP ranges only.
• Mailchimp — include:servers.mcsv.net = 1. IP ranges only.
• SendGrid — include:sendgrid.net = 2. Its record contains one nested include of IP ranges. (Some third-party guides claim roughly five; the live record says two.)
• Zoho — include:zoho.com = 5. Zoho's own record includes four more records (spf.zoho.com, zcsend.net, spf.zohomail.com, popspf.zohomail.com). Half your entire budget, from one sender most people assume costs one.

A completely ordinary stack — Google Workspace (1) + Mailchimp (1) + a CRM include (1–2) + your web host's mx (1) — sits at 4–5. Add Zoho anywhere in the mix, or a couple of legacy tools nobody removed, and the ceiling arrives fast.

Fix 1: Remove what's dead (do this first)

Audit before surgery. In most over-limit records, the excess is archaeology: the newsletter tool you migrated away from in 2023, the helpdesk from two vendors ago, the a mechanism pointing at a web server that hasn't sent mail in years. Every include whose platform no longer sends as your domain comes out. Cross-check against your DMARC reports (if you have them — here's how to set that up): the reports list who actually sends; anything in SPF that never appears in reports is a removal candidate. This fix is free, immediate, and usually recovers 2–4 lookups.

Fix 2: Move senders to subdomains

The structural fix. SPF is per-domain — and a subdomain is its own domain for SPF purposes, with its own 10-lookup budget. Platforms that send through their own return-path subdomain already do this for you: SendGrid's Domain Authentication uses an "em…" subdomain CNAME, and Kit's Verified Sending Domain authenticates on its own subdomain too — in both cases, the root record spends 0 lookups on them once the CNAME setup is used instead of a root include.

The same trick works deliberately: send marketing mail from news.yourdomain.com or transactional mail from mail.yourdomain.com, each with its own SPF, DKIM and (inherited or explicit) DMARC policy. Bonus: a subdomain also isolates reputation — a newsletter mishap stops touching your invoices' deliverability.

Fix 3: SPF flattening (with eyes open)

Flattening means replacing include: mechanisms with the raw IP ranges they currently resolve to, so the record costs almost no lookups. It works — and it has a real price: IP ranges change. When a platform moves infrastructure, a hand-flattened record silently stops covering it, and its mail starts failing. Flattening is only safe as a maintained process (a service or script that re-resolves and republishes regularly), never as a one-time hand edit. If you're flattening by hand today, set a monthly reminder to re-check — or use the subdomain strategy instead and skip the treadmill. The Email Authentication Kit walks through both strategies step by step, including the maintenance flattening obliges you to.

Fix 4: Stop the count creeping back

Over-limit records are a process problem, not a knowledge problem. The prevention is a sender inventory: a written list of everything that sends as your domain, where its DKIM lives, and what its SPF costs — updated every time a tool is added or removed. Five minutes per change. Our free wizard counts the lookups for the senders it covers and warns you at 8 before you hit the wall; the kit's printable worksheet is the inventory page you keep.