SPF Checker
Validate a domain's SPF record: mechanisms, the include tree, the 10 DNS lookup limit, +all and syntax mistakes.
Check an SPF record
Every include and redirect is followed so the DNS lookup count is the one receivers see.
What the SPF Checker does
SPF Checker fetches the TXT records of a domain, finds the one that starts with v=spf1 and takes it apart mechanism by mechanism: ip4 and ip6 ranges, a, mx, ptr and exists, every include, and the redirect and all terms with their qualifiers. It then follows each include and redirect recursively, fetching those domains' records too, and draws the whole tree so you can see which third-party senders your record really authorises.
The most common SPF failure is invisible in the record itself: RFC 7208 allows at most ten DNS-querying mechanisms across the entire tree, and a record that merely lists Google, Microsoft, a CRM and a newsletter tool is often already over. Receivers answer permerror and treat the record as if it did not exist. The tool counts the lookups the way a receiver does and shows where they come from.
It also flags several records (a permanent error on its own), +all and ?all, mechanisms placed after all, the deprecated ptr, includes that point at domains with no record, and malformed addresses.
Step by step
- 01Enter the domain exactly as it appears after the @ in your sending address.
- 02Press Check. The record and every include it references are fetched live.
- 03Read the lookup count against the limit of ten and the warnings above the tree.
- 04Open the tree to see which includes bring in which addresses, and remove senders you no longer use.
Common questions
-all (fail) tells receivers to reject mail from servers not in the record; ~all (soft fail) tells them to accept it but mark it suspicious. With DMARC in place both count as a failure for alignment, so -all is the stricter, recommended choice once you are sure every legitimate sender is listed. Start with ~all while you are still discovering senders.
Remove includes for services you no longer use; replace a and mx with the actual ip4 and ip6 ranges when they are stable; ask vendors for an include with fewer nested lookups; and for senders you control, publish the addresses directly. Automated "SPF flattening" services exist but need to re-check vendor ranges constantly.
SPF is not inherited. mail.example.com needs its own TXT record if anything sends from addresses on it, and so does every subdomain in your bounce (Return-Path) addresses. A subdomain that never sends mail should publish "v=spf1 -all" so it cannot be spoofed.
SPF checks the envelope sender (Return-Path), not the From header you see. Mail sent through a newsletter or CRM tool usually has the vendor's domain in the Return-Path, so your record is never consulted; DMARC alignment then needs DKIM instead. Use the Email Header Analyzer on a bounced message to see which domain was actually evaluated.
Keep checking
DKIM Checker
Find and validate a domain's DKIM record by selector: tags, key type and size, test mode, or try the common selectors.
Free toolDMARC Checker
Validate a domain's DMARC record: policy, subdomain policy, pct, reporting addresses, alignment and common mistakes.
Free toolDNS Lookup
Look up the A, AAAA, CNAME, MX, NS, TXT, SOA, SRV and CAA records of any domain with their TTLs in one query.
Free toolEmail Header Analyzer
Paste raw email headers to see the delivery path hop by hop with delays, SPF, DKIM and DMARC results and spoofing warnings.
Free toolBlacklist Checker
Check whether an IP or mail server is listed on Spamhaus, SpamCop, Barracuda, SORBS and ten more DNS blacklists.
Want these fixes done for you?
Our team runs the audit, makes the changes and reports the result.