SPF Lookup Checker

When a receiving server checks your SPF record, it has to resolve every mechanism that points somewhere else. include:_spf.google.com is one lookup — but that record has its own includes, and each of those counts too. The total is cumulative across the whole tree, not just the record you wrote.

RFC 7208 section 4.6.4 caps that at 10. Cross it and the check returns PermError, and most receivers treat a PermError exactly the same as a domain with no SPF record at all.

Which terms cost a lookup

• Counted: include:, a, mx, ptr, exists:, and the redirect= modifier
• Free: ip4:, ip6:, all, and the exp= modifier

Why this breaks quietly

Nothing tells you when it happens. Your record still looks correct when you read it, your DNS provider accepts it, and your ESP reports messages as sent. The failure only shows up as a slow slide in inbox placement — which is why domains sit broken for months.

It usually creeps in over time. You add Google Workspace, then a marketing platform, then a helpdesk, then invoicing. Each one adds an include, and one of those providers expanding their own record can push you over without you touching anything.

How to fix it

• Remove what you no longer send from. Retired vendors are the most common dead weight, and they often show up as void lookups.
• Replace small includes with their IPs. If a provider publishes one or two addresses, ip4: entries cost nothing.
• Move bulk sending to a subdomain. A separate subdomain gets its own SPF record and its own budget of 10 — and it protects your main domain's reputation at the same time.

Flattening — expanding every include into raw IPs — also works, but a flattened record goes stale the moment a provider changes their addresses, so it needs monitoring.