Valid policy
One SPF record was found and its core syntax is usable. Continue reviewing every authorized sender and the expanded lookup count.
Check your SPF record
Inspect your SPF policy, default enforcement, deprecated mechanisms and DNS lookup budget.
- No account required
- Public DNS records only
- Clear remediation guidance
What is an SPF record?
SPF—Sender Policy Framework—is a TXT record that identifies services allowed to send mail using a domain’s envelope sender. Receiving systems compare the connecting IP address with mechanisms in the published policy, including ip4, ip6, include, a and mx.
A domain should publish one SPF policy beginning with v=spf1. Multiple records do not add together; they can produce a permanent error. Every legitimate sender must be represented in the single policy, directly or through a provider include, and the record should end with an intentional all mechanism such as -all or ~all.
SPF evaluation is limited to ten DNS-causing mechanisms and redirects. Nested include records count toward that budget, so a short-looking policy can still exceed the limit. SPF also authenticates the envelope domain rather than the visible From address, which is why DMARC alignment remains important.
How the checker works
- 01
Read the root TXT records
The checker searches the submitted domain for values beginning with v=spf1.
- 02
Validate policy count
It confirms that exactly one SPF policy exists for the domain.
- 03
Expand DNS mechanisms
Provider includes and redirects are followed within safety limits to estimate the lookup budget.
- 04
Assess enforcement
The final all mechanism, deprecated terms and authorization structure are translated into actionable findings.
How to read SPF results
Softfail
A ~all ending signals that unmatched senders should be treated as suspicious but not necessarily rejected. It can be useful during controlled transition.
Hard fail
A -all ending states that unmatched systems are unauthorized. Use it only after every legitimate sending service is represented.
Lookup-budget risk
Too many DNS-causing mechanisms can make SPF return permerror. Simplify providers or obtain a supported flattened strategy that is kept current.
Common SPF problems and fixes
No SPF policy
Inventory transactional, support, billing and marketing senders, then publish one provider-approved record at the root domain.
Multiple SPF records
Merge authorized mechanisms into a single v=spf1 value. Do not simply delete a record until you know which service depends on it.
More than ten lookups
Remove obsolete includes, ask providers for narrower authorization options, or use a maintained flattening approach with careful change monitoring.
Obsolete ptr mechanism
PTR is deprecated, slow and unreliable for SPF authorization. Replace it with the explicit mechanism recommended by the sending provider.
Frequently asked questions
Practical answers about this checker and the signal it evaluates.
Should I use -all or ~all?+
Use the policy that matches your verified sender inventory and rollout stage. Hard fail is stronger, but an incomplete inventory can break legitimate delivery. DMARC reports can help validate sources before tightening SPF.
Does SPF cover forwarded email?+
Traditional forwarding can change the connecting IP while preserving the original envelope domain, causing SPF to fail. DKIM may survive forwarding, and DMARC can pass when an aligned DKIM signature remains valid.
Can I put SPF on a subdomain?+
Yes. Each envelope-sender domain can publish its own SPF policy. A policy on example.com does not automatically define the policy for every subdomain.
Why is there a ten-lookup limit?+
The limit protects receivers from expensive or abusive recursive DNS evaluation. Include, a, mx, ptr, exists and redirect can trigger lookups; nested provider policies also count.