SPF Record Checker & Lookup Counter

An SPF record answers one question for every mail server on earth: which machines are allowed to send mail as your domain? It is a single TXT record starting v=spf1, listing IP ranges and — far more often — include: pointers at the SPF records of the services that send for you: Google Workspace, your marketing platform, your helpdesk, your invoicing tool. Receivers fetch it, expand it and compare the connecting IP. SPF is one third of the email-authentication stack alongside DKIM and DMARC.

The catch is that expansion costs DNS queries, and the receiver pays for them — on every single inbound message. That is why RFC 7208 caps evaluation at 10 DNS-querying mechanisms: without the cap, a hostile record with deeply nested includes would turn every mail server into a DNS flood machine, so the limit is denial-of-service protection, not pedantry. Each include, a, mx, ptr and exists costs one lookup, redirect= costs one, and the count is recursive — an include costs one lookup itself plus everything inside the record it points at.

Cross the limit and receivers return permerror — which they treat exactly as if you had no SPF record at all. That is expensive now that Gmail and Yahoo's bulk-sender rules require passing authentication before your mail is accepted. And the failure mode is sneaky: includes accumulate silently. Each SaaS tool you onboard says "just add our include", each of those includes contains its own lookups, and one day a vendor restructures their record and your total ticks from 10 to 11 without anyone touching your DNS. The common fix, SPF flattening, replaces includes with the raw IPs behind them — it works, but flattened records rot as vendors move IPs, so it only holds up when the re-flattening is automated. While you're here, check your DMARC and DKIM too — SPF alone stops nothing without a DMARC policy on top.