An SPF checker that counts lookups the way receivers do
This SPF checker reads the Sender Policy Framework record a domain publishes in DNS and evaluates it the way receiving mail servers do under RFC 7208 (April 2014). It expands every include: and redirect= into a tree, numbers each DNS-lookup term against the limit of 10, counts void lookups against the limit of 2, and catches loops, duplicate records, syntax errors and weak endings such as ?all or +all.
Then test a real sending server: enter its IP address and the tool runs the full check_host() evaluation — CIDR matching for IPv4 and IPv6, a, mx, exists, ptr and macros — and shows pass, fail, softfail or neutral with the exact mechanism that matched. A generator builds a new record from common mail services, and you can test a draft before publishing it. Only DNS queries leave your browser.
How to use the SPF Record Checker
- Type your domain (or paste an email address — the part after @ is used) and press “Check SPF”.
- Read the verdict and the checks: every row says pass, warning or fail, why, and how to fix it.
- Open the include tree to see which branch uses your lookups; numbers past 10 are shown in red.
- Under “Test a sending IP”, enter the IP from a message’s Received header and press “Test IP”.
- To change the record, open “Generate a record”, tick your services, choose the ending, then press “Check this record” to test the draft.
- Press “Copy report” to paste the findings into a support ticket.
SPF Record Checker features
Lookup counting in evaluation order
include, a, mx, ptr, exists and redirect are numbered as a receiver meets them, across the whole tree, so you see exactly which term is the 11th.
Void-lookup, loop and syntax checks
Names with no records, includes that point back into the chain, unknown mechanisms, include= typos and three-part IPv4 addresses are all reported.
Real IP evaluation
check_host() with IPv4 /24-style and IPv6 /48-style CIDR matching, IPv4-mapped addresses and macros, stopping at the first match like a real receiver.
Every authorised range
A flattened table of ip4, ip6, a and mx addresses with the include each one comes from, plus the total number of IPv4 addresses.
Draft testing and generator
Test a record before it is published; build one from Google Workspace, Microsoft 365, Zoho, Amazon SES, SendGrid or Fastmail presets.
Worked example: 12 lookups and what receivers do with them
Take v=spf1 ip4:192.0.2.0/24 include:a.example include:b.example mx a -all, where a.example includes three more records and b.example includes four more plus an a: term. Counted in evaluation order, the include of a.example is lookup 1, its three includes are 2–4, b.example is 5, its five terms are 6–10, and the final mx and a are lookups 11 and 12 — the checker marks those two in red and reports “12 DNS lookups — the limit is 10”.
The limit only bites when evaluation gets that far. A server listed in the second nested include (say 198.51.100.2) still passes after 3 lookups, because receivers stop at the first match. A forger’s IP matches nothing, reaches the 11th lookup and gets PermError — which DMARC counts as an SPF failure, so your real mail from the late-listed servers fails too.
| Term | Counts towards 10? | Notes |
|---|---|---|
| include, redirect | Yes, 1 each | Plus everything inside the target record |
| a, mx | Yes, 1 each | mx may return at most 10 hosts |
| exists, ptr | Yes, 1 each | ptr is deprecated (RFC 7208 §5.5) |
| ip4, ip6, all, exp | No | No DNS query during evaluation |
What each SPF result means
| Result | Meaning | Typical receiver action |
|---|---|---|
| pass | The IP is authorised | Accept; counts for DMARC if the domain aligns |
| fail (-all) | Explicitly not authorised | Reject or junk; DMARC sees an SPF failure |
| softfail (~all) | Probably not authorised | Accept but mark; DMARC decides |
| neutral (?all) | No statement | Treated like none |
| none | No SPF record | No SPF protection |
| permerror | Broken record (limits, syntax) | Treated as a failure by DMARC |
| temperror | DNS failure | Defer and retry |
Provider include values (checked 14 October 2026)
- Google Workspace:
include:_spf.google.com(Google Workspace Admin Help). - Microsoft 365:
include:spf.protection.outlook.com; GCC High/DoDspf.protection.office365.us; 21Vianetspf.protection.partner.outlook.cn(Microsoft Learn). - Zoho Mail:
include:zohomail.com, orinclude:one.zoho.comwhen several Zoho apps send mail. - Amazon SES:
include:amazonses.comon your custom MAIL FROM subdomain, not the From domain. - SendGrid:
include:sendgrid.netonly with automated security switched off. Fastmail:include:spf.messagingengine.com. - Mailchimp, Mandrill and Brevo’s shared IPs need no SPF include in their current guides — set up their DKIM records with the DKIM Checker instead.
SPF Record Checker FAQ
What does “too many DNS lookups” mean in an SPF check?
RFC 7208 §4.6.4 lets a receiver follow at most 10 include, a, mx, ptr, exists and redirect terms while checking one message. If evaluation needs an 11th, the result is PermError. Every include you add for a mail service brings its own nested lookups, so records quietly drift over the limit when providers change theirs.
Should my SPF record end in -all or ~all?
Both protect you once DMARC enforces a quarantine or reject policy, because DMARC treats softfail and fail the same way. Google’s own example uses ~all; Microsoft’s uses -all. Use ~all while you are still discovering senders and -all when the list is complete. Never use +all, and avoid ?all.
Why can a domain have only one SPF record?
RFC 7208 §4.5 says that if a name publishes more than one TXT record starting with v=spf1, the result is PermError for every message. Merge them into one record with one “all” at the end.
What is a void lookup?
A DNS query made for an SPF term that returns no records — a name that does not exist, or exists without the requested type. RFC 7208 recommends a limit of two; after that, receivers return PermError. They usually come from includes or a: terms for services and servers that were removed.
Do Gmail, Yahoo and Outlook.com require SPF?
Since February 2024 Google and Yahoo require SPF or DKIM from every sender, and SPF and DKIM plus a DMARC record from bulk senders (Google: about 5,000 messages a day to personal Gmail accounts). Outlook.com applies the same rules to senders of more than 5,000 messages a day from 5 May 2025. Check DMARC with the DMARC Checker.
Is this SPF checker private?
The domain names it needs are looked up through Google Public DNS over HTTPS (or Cloudflare as a fallback), which see only the name and record type. The IP addresses you test and draft records never leave your browser. For other record types use the DNS Lookup.