SPF Record Checker
Read your published sender policy, understand its mechanisms and find syntax or lookup-budget risks.
Enter the domain used in your envelope sender (MAIL FROM). The checker reads TXT records and follows reachable include and redirect references.
No registration required. Checks run on our server using Google Public DNS. Our DNS cache lasts up to five minutes; upstream DNS caches can delay changes further. No email test allowance is used.
How to use SPF Record Checker
- Find the envelope sender domain in your sending platform’s return-path settings or in a delivered message’s
Return-Pathheader. It can differ from the visible From address. - Enter only that domain. For the illustrative address
bounce@news.example.com, enternews.example.com, without@, a URL or the SPF record itself. - Select Check SPF. The domain is required; there are no optional fields and no sending IP to enter.
- Read the syntax findings and lookup breakdown. Change the record at your DNS host only after comparing it with every service that sends for this domain, then check again.
What this tool checks
The checker reads public Domain Name System (DNS) records through Google Public DNS on our server. It inspects the published policy and reachable references:
- Whether exactly one TXT record starting with
v=spf1is present at each inspected policy domain. - Mechanism names, qualifiers, duplicate modifiers, macro syntax, IP address syntax and network prefix lengths such as
ip4:192.0.2.0/24. This is an example network, not a sender recommendation. - The
allpolicy, a missing default policy, ignored redirects, and cycles or depth limits inincludeandredirectreferences. - A conservative count of DNS-triggering terms across reachable branches, observed empty lookups, A/AAAA answers for
a, A answers forexists, and the number of MX hosts formx.
This is not a message SPF test: it does not match a sending IP against the policy, fully expand MX host addresses, resolve PTR mechanisms, or expand sender-dependent macros. An empty answer is distinct from a resolver timeout or refusal. Inspect the original DNS sources when a finding is unclear.
Understanding your results
Keep one SPF TXT record. Inventory every legitimate sender before changing all or removing includes. A valid policy alone does not mean a particular message passes SPF.
| Finding | Meaning & likely cause | Next action |
|---|---|---|
| Pass: publication / syntax | A unique policy or inspected term passed that check. It does not say a particular sender is authorized. | Compare the policy with your actual sending services; review other findings too. |
| Fail: missing, duplicate or invalid policy | No recognized SPF record, multiple policies, a malformed term or a recursive reference prevents a usable inspection. | Check the lookup name; publish one provider-approved policy and correct the named term or reference. |
| All policy / default policy | +all is Fail because it authorizes anyone. ~all and ?all are warnings; no all or redirect leaves unmatched senders neutral. | Choose the ending deliberately after confirming legitimate senders. -all passing here is not a message pass. |
| Warning: lookup budget / void lookups | The static total exceeds 10 DNS-triggering terms, or more than two empty lookups were observed. Branches and message context can change the actual count. | Review nested includes and unused services. Read the guide to too many SPF DNS lookups before restructuring. |
| Warning: PTR / ignored redirect | PTR requires sender context; a redirect beside all is unreachable. | Replace discouraged PTR usage where possible and remove or revise the ignored redirect. |
| Unknown: macro, inspection bound or DNS lookup | Sender context is missing, a branch limit was reached, or DNS could not answer. This is not proof of a missing record. | Use the real message context for dynamic terms; retry technical errors and investigate persistent DNS problems. |
| Info: observations | A redirect, MX expansion or void count is explanatory context, not an extra authentication verdict. | Use the breakdown to trace the policy that needs attention. |
What is SPF and why does it matter?
Sender Policy Framework (SPF) lets a domain publish which servers may send using its envelope identity. A receiving server evaluates that TXT policy against the connecting IP and the SMTP envelope sender. SMTP is the protocol used to transfer email; its envelope sender is separate from the From address a reader sees.
Use this lookup when adding a sending service, troubleshooting a policy error or reviewing nested includes. For example, include asks another domain’s SPF policy whether it authorizes the sender; it does not copy a fixed list of addresses forever. A syntactically valid SPF policy does not prove message authentication or inbox placement. Check DMARC to inspect the policy that relates authenticated domains to the visible From identity.
Frequently asked questions
Which domain should I check if From and Return-Path differ?
For this tool, use the domain of the envelope sender shown in Return-Path or your provider’s custom return-path settings. A visible From domain can have a different SPF record. For SMTP with an empty envelope sender, SPF uses the HELO identity; this page does not reconstruct that message context.
Why is there no SPF record even though I added one?
Verify that the TXT record is at the exact sending domain rather than a different subdomain. Check for a DNS host that appended the domain twice. Our cache can retain DNS answers for up to five minutes; upstream caches follow their own expiry. Recheck after the published TTL, or time to live, has expired.
Does more than 10 displayed lookups always mean SPF fails?
No. The displayed number combines reachable branches as a conservative upper bound. An actual evaluation can stop at an earlier matching mechanism. Investigate the paths your real senders use instead of treating this count as a message verdict.
Can I publish a second SPF record for another email provider?
Keep one SPF policy at that DNS name. Merge the required mechanisms into that policy after checking the provider’s instructions and lookup impact. Separate TXT records starting with v=spf1 are not a way to combine providers.
Why can valid SPF still leave DMARC failing?
A message must pass authentication and use a domain aligned with its visible From address. This record lookup does not establish either for an actual message. See why SPF and DKIM can pass while DMARC fails.