SPF Record Checker
Check your SPF record, visualise the full DNS lookup tree, and validate policy strength for any domain.
Validation results
How this SPF checker works
SPF (RFC 7208) is the DNS TXT record that tells receivers which servers are allowed to send mail using your domain in the MAIL FROM envelope. Type a domain above and the tool pulls the record, walks every mechanism, follows each include: and redirect= target, and reports back. The evaluation runs in your browser against the same rules a receiving server would apply.
A typical SPF record looks like this:
example.com TXT "v=spf1 include:_spf.google.com include:mailgun.org ~all"What is the 10 DNS lookup limit?
RFC 7208 §4.6.4 caps the total number of DNS-resolving terms a receiver will follow at 10. Every include:, a, mx, ptr, exists, and redirect= counts. Static ip4: and ip6: entries cost nothing because they resolve no DNS. Go past 10 and the receiver returns PermError. Google bounces those messages with 550 5.7.24. The same section caps void lookups, NXDOMAIN or empty answers, at 2. The checker tracks both budgets and shows what's left.
Most "SPF was fine yesterday, why does Google reject us today" tickets trace back to this. An upstream provider adds one more sub-include, your tree quietly tips over 10, and authentication breaks for every recipient on the same morning.
Which terminal qualifier should I use?
The qualifier on all decides what happens to senders that don't match any earlier mechanism. -all (Fail) tells receivers to treat the connection as forged; most large providers reject it outright with 550 5.7.23. ~all (SoftFail) flags the message but still delivers, usually into spam. ?all (Neutral) is the same as having no policy at all. +all hands your domain to anyone with an SMTP client.
Our take: ~all and -all are both fine end states. Start at ~all while you roll DMARC out and watch the aggregate reports until every legitimate sender shows up authorised. Plenty of large senders deliberately stay on ~all long-term because it keeps forwarded mail (mailing lists, alumni redirectors, .forward files) verifying instead of failing outright. Tightening to -all is reasonable once you are sure no legitimate forwarding paths still rely on a soft fail. Either qualifier paired with DMARC p=reject gives you the same spoofing protection. The verdict panel resolves any redirect= chain so you see the qualifier that actually applies, not the one printed on your root record.
Why this matters now
Google and Yahoo have required SPF (with DKIM and a DMARC policy) for any sender pushing over 5,000 messages a day since February 2024. Microsoft turned the same rule on for Outlook.com, Hotmail and Live in May 2025. Mail that fails authentication bounces with 550 5.7.515. A passing SPF result on its own isn't enough either, receivers want SPF or DKIM to align with the visible From: header before they count the message as authenticated.
Hitting the lookup cap, what now?
Cheapest fix first: delete include: entries for senders you no longer use. Half the over-10 records we see are still carrying an old ESP from a migration two years back. Senders with small, stable IP ranges can be inlined as ip4: or ip6:, which cost zero lookups. Heavy marketing or transactional traffic usually belongs on its own sending subdomain (mail.example.com, news.example.com) so each subdomain gets its own budget.
What to do: SPF flattening, replacing includes with their currently-resolved IPs, is a last resort. It works until the provider rotates IPs, at which point mail starts failing and you have to re-flatten. A managed flattening service handles the refresh for you. Hand-rolled flattening is fragile and we don't recommend it. The SPF builder assembles a fresh record from known-good provider includes, and the SPF syntax reference covers the mechanics.
Non-sending domains need SPF too
If the domain doesn't send mail at all, publish a hard-fail record:
example.com TXT "v=spf1 -all"
Pair that with v=DMARC1; p=reject; and a wildcard DKIM revoke (*._domainkey with v=DKIM1; p=) and the domain is sealed off. That's the M3AAWG-recommended posture for parked or admin-only domains. Skip it and spammers will spoof the domain and burn its reputation before you notice. The checker recognises the locked-down case and grades it as a positive verdict rather than a missing-sender error.
Where to go next
SPF is one leg of the authentication stack. For the others, see the DKIM checker and the DMARC checker. The DMARC tags reference covers how SPF and DKIM results fold into the alignment check receivers actually care about.
Frequently Asked Questions
Common questions about SPF records and email sender policy.
Why did SPF break when nothing on my end changed?
An upstream provider added a sub-include. Your record sat at 9 lookups, theirs went from 1 to 2, and the tree quietly tipped over the RFC 7208 cap of 10. Receivers now return PermError and treat the message as if SPF was never there. Most "Google started rejecting us overnight" tickets land here.
The checker walks the full tree and shows the current count. Sitting at 9 or 10 means you're one provider update from breaking. Drop a stale include, move a heavy sender onto its own subdomain, or inline a small static range as ip4:.
Is SPF flattening worth it?
Only as a last resort, and only with a managed service that refreshes the flattened record automatically. Flattening swaps an include: for the IPs it currently resolves to, which gets you under the 10-lookup cap today. The moment the provider rotates a sending IP, your hand-rolled flat record stops authorising the new server and mail starts failing silently.
Cheaper fixes first: delete unused includes, move heavy senders onto a sending subdomain, inline small stable ranges as ip4:. If you've exhausted those and still need flattening, use a service that monitors the upstream record for changes.
Does SPF on its own stop spoofing?
No. SPF only checks the envelope MAIL FROM domain. A spammer can pass SPF for their own throwaway domain while still putting your domain in the From: header your recipient actually sees. SPF has no opinion on that.
DMARC is what closes the gap. It requires SPF or DKIM to align with the visible From: domain before the message counts as authenticated. Without a DMARC policy at p=quarantine or stronger, a clean SPF record on its own does not stop From-header spoofing.