SPF Record Checker
Validate the SPF (Sender Policy Framework) record for any domain and understand its email authentication policy.
Did this tool work for you?
How to use this calculator
- 1
Enter the domain name whose SPF record you want to check.
- 2
Click "Check Now" to retrieve and parse the SPF record.
- 3
The tool shows the policy, included domains, IP ranges, and the "all" mechanism.
- 4
A "-all" (hard fail) policy offers the strongest protection.
Frequently asked questions
What exactly does this checker look up?
It asks Cloudflare’s DNS-over-HTTPS service for the TXT records of the domain you enter and picks the first one that begins with v=spf1. It then lists the record, the policy from the final all mechanism, each include:, ip4: and ip6: entry, any redirect= target, and a mechanism count. A domain with no such record reports Not found.
Does it count DNS lookups for the 10-lookup limit?
Yes. SPF allows ten DNS-querying terms (include, a, mx, ptr, exists and the redirect modifier) per evaluation, counted across nested includes; ip4, ip6 and all do not count. The tool follows include and redirect targets, looking up each one, and shows the total as, for example, 3 of 10 allowed: green up to 8, amber at 9 or 10, red above 10. To stay quick it makes at most 20 extra lookups and says so if it stops early. It counts each include, a, mx, ptr, exists and redirect term once and does not count the extra address lookups that a receiver makes for each mx host, so a record shown at 9 or 10 may already be over the limit in practice.
What is the difference between -all, ~all, ?all and +all?
The qualifier on all sets the result for senders that matched nothing earlier: - is fail, ~ is softfail, ? is neutral and + is pass. A +all lets any server send as your domain, so the tool flags it as an error. -all is shown as good, while ~all and ?all are shown as warnings. Many organisations publish ~all while they confirm every sender is listed, then tighten to -all.
Why does it say there is no "all" mechanism?
The tool recognises all in any case and with or without a qualifier; a bare all is treated as +all, which allows anyone to send. If none is present and the record uses redirect=, the Policy line says the policy is delegated to the redirect target, and you should check that domain’s record for its all. A record with neither an all nor a redirect has no default result, so receivers treat unmatched senders as neutral.
Can I have two SPF records on one domain?
No. A domain must publish exactly one v=spf1 record, and receivers treat two as a permanent error. If the tool finds more than one at the domain you entered, or at any include or redirect target it follows, it shows a Multiple SPF records or Problem line. It analyses the first record it sees, so merge your senders into one record and re-check.
Does a passing SPF record mean my email is authenticated?
Not by itself. SPF checks the sending server against the envelope sender (the Return-Path domain), not the visible From address. A message can pass SPF and still fail DMARC if the two domains do not align. SPF also commonly fails when mail is forwarded. Check DKIM and DMARC as well.
Why can a record be correct but look different from what I published?
DNS providers split long TXT values into quoted strings of up to 255 characters. The tool joins those strings back together before displaying the record. Recent changes may also take time to appear because resolvers cache answers until the TTL expires.
SPF records: how to read what the checker reports
How a receiving server uses SPF
SPF, defined in RFC 7208, lets a domain publish the servers allowed to send mail for it. When a message arrives, the receiver takes the domain from the envelope sender (the MAIL FROM address, or the HELO name when that is empty), fetches its TXT records, picks the one starting v=spf1 and evaluates its terms from left to right. The first term that matches the connecting IP address decides the result. If nothing matches, the qualifier on all or the default of neutral applies. Because it checks the envelope and not the From header you see in your mail client, SPF alone does not stop display-name or header spoofing.
Mechanisms the tool shows and ones it does not
The checker lists include, ip4, ip6 and redirect terms. The a, mx, ptr and exists mechanisms are counted in the DNS lookup total but not listed individually.
| Term | Meaning | Counts toward 10 lookups | Listed by this tool |
|---|---|---|---|
| ip4:203.0.113.10 | Matches a single IPv4 address or CIDR range | No | Yes, as IPv4 range |
| ip6: | Matches an IPv6 address or range | No | Yes, as IPv6 range |
| include:_spf.google.com | Evaluates another domain’s record and matches if it passes | Yes, plus its nested terms | Yes, as Include |
| a, mx | Match the domain’s A records or mail servers | Yes | No (counted in the lookup total only) |
| redirect=other.com | Uses the other domain’s record in place of this one | Yes | Yes, target only |
| -all / ~all | Result for senders that matched nothing | No | Yes, as Policy |
What a typical result looks like
Take a domain that sends only through Google Workspace and publishes v=spf1 include:_spf.google.com ~all. The tool shows that record in full, a Policy of soft fail, one Include entry reading _spf.google.com, and two mechanisms. For a company that adds a transactional email provider and a fixed server, the list grows by one Include and one IPv4 range, and the policy line is the first thing to review. A result of Not found means no TXT record starting with v=spf1 was returned for the exact name entered. SPF is looked up per domain, so a subdomain that sends mail needs its own record.
Limits to remember when reading results
Since this tool does not expand includes, a record that looks short can still exceed the ten-lookup limit once providers’ nested includes are counted, which makes receivers return a permanent error. Run a full expansion in a dedicated SPF validator if you list several services. The tool also cannot tell you whether every legitimate sender is covered; that needs a review of your actual mail sources, ideally with DMARC aggregate reports. Use the DMARC and DKIM checkers alongside this one for the full picture.
Learn more from an authoritative source:
MDN Web DocsDKIM Record Checker
Look up and validate the DKIM (DomainKeys Identified Mail) public key record for a domain and selector.
DMARC Record Checker
Check and analyse the DMARC policy for any domain to understand how email authentication failures are handled.
DNS Propagation Checker
Check whether your DNS changes have propagated across Cloudflare, Google, and Quad9 resolvers worldwide.
SSL Certificate Checker
Inspect the SSL/TLS certificate for any domain — view issuer, expiry date, SANs, and days remaining.
Domain Age Checker
Find out how old any domain is — see its registration date, age in years, and expiry date via RDAP.
WHOIS Lookup
Look up domain registration information — registrar, dates, nameservers, and status via the RDAP protocol.
Results are estimates for informational purposes only and do not constitute professional financial, medical, legal, or technical advice. Read full disclaimer →