SPF “too many DNS lookups”: why it breaks and the fix that holds

Your SPF record is being ignored, not failing. Every receiver treats it as missing. Cut includes you no longer use, and move cold email to separate sending domains that need only one include.

What the limit counts

RFC 7208 caps SPF at 10 DNS-querying mechanisms per evaluation. include:, a, mx, exists:, ptr and redirect= each count one, and includes count recursively. ip4: and ip6: cost nothing. A single include:_spf.google.com costs 4: itself plus the three includes inside it.

How records get there

One tool at a time. HubSpot wants an include. Then the help desk. Then the sending platform, the CRM, the survey tool, the old marketing platform nobody removed. Six includes at two or three lookups each and you are past 10 without noticing, because nothing warns you. Mail keeps going out; receivers just quietly stop trusting the SPF half of your authentication.

Two fixes that make it worse

• A second SPF record. A domain may publish exactly one. Two is a permanent error, same outcome as none.
• Hard-coding IPs. Replacing include: with copied ip4: ranges works today. Vendors rotate IPs; in a few months some of your mail fails SPF and nobody knows why.

The fix that holds

1. Run the domain check to see your current lookup count.
2. Remove every include for a tool you no longer send from. Most domains drop 3 to 5 lookups here.
3. Move cold email to dedicated sending domains. Each needs one include (your sending provider) and never approaches the limit. Your main domain keeps transactional mail, which usually fits.
4. Only if you must keep everything on one domain: use an SPF flattening service that refreshes IPs automatically. Never flatten by hand.

Re-check after every change. DNS propagation can take up to 48 hours but usually shows within the hour.