SPF Record Checker

What counts toward the 10

RFC 7208 limits how many terms can trigger a DNS query while a receiver evaluates your SPF record: include, a, mx, ptr, exists, and the redirect modifier each cost one, and it adds up across every nested include. ip4, ip6, and all are free, since they need no lookup. The limit exists so evaluating one email can't be turned into a flood of DNS traffic — and receivers enforce it strictly, so 11 is a failure, not a warning.

How to get back under the limit

• Remove includes you no longer use. Old newsletter platforms and CRMs are the usual culprits — if you've stopped sending through it, its include is just costing lookups.
• Swap a and mx for ip4. If your web server or mail server has a fixed IP, listing it directly costs nothing. Only do this for IPs you control — a provider's IPs change without notice.
• Send from subdomains. SPF is checked per domain, so moving marketing mail to news.example.com gives it its own record and its own 10 lookups, leaving the main domain for day-to-day mail.
• Be wary of "flattening". Replacing includes with the IPs they currently resolve to gets the count down, but the record silently goes stale when the provider changes its ranges. Only flatten with a service that re-checks and updates it automatically.

-all vs ~all

-all (fail) tells receivers to reject mail from servers not listed; ~all (softfail) says to accept it but treat it as suspicious. With DMARC in place, the difference matters much less than it used to — DMARC's own policy decides what happens — so ~all is a reasonable default while you're confident every sender is listed. Never use +all: it authorises the entire internet.

Where SPF lives

SPF is a single TXT record on the domain, starting v=spf1. Two separate SPF records is itself an error, and a common one — adding a new provider's record next to the existing one instead of merging its include into it. See the DNS reference for how TXT records and TTLs work in Route 53.