SPF Checker
Validate and recursively expand the SPF record, with mechanism breakdown.
No result yet
Enter the inputs above and press Run. Results appear here in a moment.
Monitor this 24/7 — get alerts on the first failure.
Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our Terms.
What is SPF Checker?
SPF (Sender Policy Framework, RFC 7208) is the DNS record that says "these servers are allowed to send mail for my domain." Mail receivers query it during SMTP delivery: if the connecting IP isn't on the list, the mail is treated as suspicious or rejected. SPF is the oldest of the email authentication trio (SPF, DKIM, DMARC) and the most commonly misconfigured.
This tool fetches and parses your SPF record, validates the syntax, and recursively expands every include:, redirect=, and reference — showing you the full set of authorised IP ranges that receivers will accept mail from on your domain's behalf. It also counts DNS lookups (RFC 7208 caps at 10, exceed and your SPF silently fails everywhere).
How it works
SPF evaluation is recursive DNS plus a tiny pattern language:
- 1Fetch the SPF record — Query
TXT <domain>. SPF lives in a TXT record starting withv=spf1. Multiple TXT records may exist for other purposes (DMARC at_dmarc, verification records); we filter for the SPF one. - 2Parse mechanisms — Each space-separated token is a mechanism.
ip4:1.2.3.4authorises an IP.ip6:2001:db8::/32authorises an IPv6 range.a:andmx:authorise the domain's A/MX records.include:other.comrecursively checksother.com's SPF.redirect=other.comreplaces the lookup entirely. - 3Recursively expand includes — Each
include:does another DNS lookup. We follow the chain and report the full expansion. Common:include:_spf.google.comexpands to ~10 sub-records, each with its own IP ranges. The full set of authorised IPs is the union. - 4Apply the terminating mechanism —
~all= soft fail (mail from unlisted IPs is marked suspicious).-all= hard fail (mail rejected).?all= neutral (no opinion).+all= pass everyone (always wrong, never use). The terminating mechanism is what receivers apply when an inbound IP doesn't match any other mechanism.
When you'd use it
Adding a new ESP / sender
Onboarding SendGrid, Mailchimp, Postmark, etc. They give you an include: to add. Run an SPF check before AND after to confirm the new include resolved correctly, the total DNS lookup count is still ≤10, and you didn't accidentally end up with two SPF records.
Investigating an SPF "PermError"
Receiver bounces with "SPF PermError" — your SPF is invalid. Most common cause: >10 DNS lookups. Run the check, count the lookups, flatten or remove unnecessary includes to get under the limit.
Auditing what your domain currently authorises
Run the check, expand all includes, look at the full list of IPs. Surprise entries (an old ESP you stopped using years ago, a third party with broad include) are technical debt. Removing them tightens your security posture.
Pre-DMARC `p=reject` deployment
Before moving DMARC to p=reject, confirm SPF authorises every legitimate sender you have. SPF check shows the full list; cross-reference against your actual sending infrastructure. Anything sending from outside the list will start bouncing under p=reject.
Brand spoofing investigation
Phishing campaign using your domain. Check your SPF — does it have ~all (soft fail, receivers may still deliver to spam) or -all (hard fail, receivers reject)? Move from ~all to -all for stricter protection.
Reading the result
Mechanism list
Each ip4:, ip6:, a:, mx:, include: is one mechanism. The order matters — SPF evaluation stops at the first matching mechanism. So ip4:1.2.3.4 -all means: if you're 1.2.3.4 you pass, anything else hard-fails.
Expanded IP list
After recursive include expansion, the full set of authorised IPs. Useful for cross-checking against your actual sending infrastructure logs. If you see your sending servers in this list, SPF will pass. If not, SPF will fail.
DNS lookup count
RFC 7208 limit is 10. Each include:, a:, mx:, ptr:, exists: counts as one. redirect= also counts. ip4:/ip6: are free. Exceed 10 and your SPF returns PermError — silent fail at most receivers.
Terminator (`all` mechanism)
-all = strict (reject unauthorised). ~all = soft fail (mark suspicious). ?all = no opinion. +all = always pass (misconfiguration). Without a terminator, your SPF is incomplete and behaviour for unauthorised senders is undefined.
Common pitfalls
More than 10 DNS lookups
Most common SPF failure mode. Each include:google._spf.com-style adds 1; nested includes add their own. Audit and flatten: replace heavy include: with literal ip4: ranges, or use an SPF flattening service that periodically rewrites your record into a single flat list.
Multiple SPF records on one domain
Only ONE TXT record starting with v=spf1 is allowed per domain. Two = PermError, mail fails. Common when adding a new ESP — admins add a new record instead of merging into the existing one. Consolidate to a single record with all include: mechanisms.
`include:` for an ESP you no longer use
Each unused include: is an authorised sender (any IP they own can send as you), a DNS lookup against your limit, and an audit-trail mess. Periodically prune.
`+all` set during testing and never removed
+all authorises every sender on the internet to send as your domain. Effectively no SPF protection. Remove immediately; replace with ~all or -all.
Run SPF Checker on every change, not just once.
Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card.
Start freeFrequently asked questions
What's the SPF DNS lookup limit and why does it exist?
include:, a:, mx:, ptr:, exists: adds one lookup. Exceed 10 and receivers MUST return PermError (treat as if SPF doesn't exist).Does SPF protect against email spoofing?
Can I have multiple SPF records?
v=spf1. If you have two, receivers will reject SPF evaluation entirely (PermError). Consolidate into one record.What does ~all vs -all mean for actual delivery?
p=reject in place, both behave similarly — DMARC enforces. Without DMARC, ~all is a softer signal (receivers may quarantine to spam) and -all is stricter (receivers should reject). Modern recommendation: -all + DMARC p=reject.Why does my SPF show +a or +mx mechanisms?
+a authorises the domain's own A records as senders (i.e. if example.com resolves to 1.2.3.4, then 1.2.3.4 can send for example.com). +mx authorises the domain's MX records. + is the default qualifier — a and +a are equivalent.How do I flatten my SPF record?
include: reference, resolve its full IP range list, then write those IPs directly in your SPF as ip4:/ip6: mechanisms. This avoids the DNS lookups but means your SPF is now a snapshot — if the ESP changes their IPs, you have to re-flatten. SPF flattening services automate this.Will failing SPF send my mail to spam?
p=quarantine or p=reject, SPF failure typically means spam folder or bounce. Without DMARC, receivers vary — Gmail is strict, others lenient. Don't rely on lenient receivers.