Free SPF Checker

What counts toward the 10-lookup limit, and what does not

Almost every broken SPF record in the wild is broken the same way: it exceeds ten DNS lookups and receivers return permerror, which they treat as an SPF failure even though the record is perfectly sensible to read. The limit comes from RFC 7208 section 4.6.4 and it is a hard cap, not a guideline.

The part people get wrong is which mechanisms are charged:

So a record with eight include: entries is not at eight of ten. It is at eight plus whatever those includes nest, and that is usually where the budget goes.

There is a second, quieter cap in the same section: more than two "void" lookups (ones that return NXDOMAIN or no answer) is also a permerror. Includes pointing at providers you stopped using years ago are the common cause, and no error surfaces until a receiver enforces it.

What each provider actually costs you

The numbers repeated in most SPF guides are stale. These were measured directly with dig on 2026-08-16, counting the include itself plus everything it nests:

Two things worth pulling out. Google Workspace is widely documented as costing four lookups because _spf.google.com used to fan out to three _netblocks records; it is flat today, so that advice now overstates your usage by three. And HubSpot costs three rather than one because it includes SendGrid, which includes its own subrecord. If you run both HubSpot and SendGrid directly, you are paying for that chain twice.

Providers change these records without notice, which is the argument for re-running the check rather than trusting any table, including this one.

What to do when you are over the limit

In rough order of how much they help against how much they cost you:

1. Delete includes you no longer use. Most over-limit records are carrying two or three dead vendors. This is free and it is usually enough.
2. Replace a and mx with explicit ip4: entries. Same result, zero lookups, at the cost of having to update them when the addresses move.
3. Move a sender to its own subdomain. Marketing mail from mail.example.com gets its own independent budget of ten lookups, because the limit is per record. This is the cleanest fix and the most underused one.
4. Flatten the record. Resolving every include down to raw ip4: blocks makes the lookup count near zero. The honest cost: you have taken ownership of IP ranges the provider expects to change, and when they do, your mail fails silently until someone re-flattens. If you flatten, automate the refresh.

SPF on its own does very little

SPF authenticates the envelope sender, not the From: header the recipient sees, so a message can pass SPF and still be a convincing forgery. What closes that gap is DMARC, which requires the authenticated domain to align with the visible From: domain and lets you publish a policy for failures.

The practical sequence is SPF, then DKIM, then DMARC at p=none while you read reports, then enforcement. Check the other two with the DKIM record checker and the DMARC record checker.

From the command line

Keyless, no signup:

curl -s "https://api.domainee.dev/v1/tools/spf-record-checker?domain=example.com" | jq

The response includes the parsed mechanisms, the recursive lookup count and a list of issues by severity. Rate limits are per IP and there is no uptime commitment, so it fits scripts and audits rather than a production dependency.

Domainee is a custom domains API for SaaS with a native MCP server, 50 domains and 100 GB free. Mail authentication and web custom domains are separate problems; this tool covers the first, the docs cover the second.