Free SPF Record Checker
Look up and validate the SPF record for any domain. The checker confirms the record exists, checks its syntax, counts DNS lookups against the RFC 7208 limit of 10 including every nested include, and gives you actionable recommendations in plain language.
Need DMARC, SPF and TLS together? Run the free domain security check, or check DMARC or TLS on their own.
What the SPF checker tests
- Record present. The domain publishes exactly one TXT record that starts with
v=spf1. Missing records and multiple records are both flagged, because receivers treat more than one as a permanent error. - Syntax. The record parses under RFC 7208, and syntax problems in the record are called out.
- DNS lookups. The lookups your record makes directly, and the chain total once every nested
include:andredirect=record is followed. You get a warning above 8 and an error above the limit of 10. - The closing all mechanism. The qualifier on
alldecides what happens to mail from servers you have not listed, so the checker tells you whether yours provides real protection. - Domain status. If the domain appears unregistered, or DNS cannot be reached, the checker says so rather than reporting a missing record.
How to read the lookup counts
The result shows two numbers. Record is the number of DNS lookups the mechanisms in your own record trigger. Chain total adds the lookups made by every record your includes and redirects pull in, which is the number receiving servers actually count.
The chain total is the one to watch. A record with three includes can easily pass 10 once each provider's own includes are followed, and a provider can grow its record without telling you. When the total passes 10, receivers return a permanent error and your SPF record stops authenticating any mail at all, which under DMARC means your email depends entirely on DKIM.
Aim to keep the chain total at 8 or below so a provider change does not tip you over the edge.
Common SPF problems and how to fix them
- Too many DNS lookups. Remove includes for services you no longer use, replace an
aormxmechanism with the equivalentip4:orip6:addresses where they are stable, and move bulk senders to their own subdomain with its own record. - Multiple SPF records. Merge every
v=spf1record into a single TXT record. Receivers do not combine them; they fail the lookup. - +all at the end. Change it to
~allor-all. With+allany server on the internet can send as your domain. - Stale includes. Records grow every time a tool or agency is added and nothing is ever removed. Observed usage in the VerifyDMARC dashboard shows which mechanisms match real traffic so you can prune safely.
- No record at all. Add a TXT record at the domain root starting with
v=spf1, list the services that send as your domain, and end with~alluntil you are confident nothing is missing.
Keep SPF healthy across every domain
A one-off check tells you where you stand today. The VerifyDMARC dashboard analyses SPF records to flag issues or misconfiguration, with hourly checks and Observed usage showing which mechanisms match real traffic, and sends regression alerts if the status downgrades. It sits alongside DMARC and TLS reporting for every domain you manage.
Start Free TrialSPF checker FAQ
What is an SPF record?
SPF (Sender Policy Framework) is a TXT record in your domain's DNS that lists the mail servers allowed to send email using your domain in the return-path address. A receiving mail server looks up the record and checks whether the connecting server is on the list.
The record starts with v=spf1, lists mechanisms such as include:, ip4:, a and mx, and ends with an all mechanism that says what to do with everything else.
Why is there a limit of 10 DNS lookups?
RFC 7208 caps the number of terms that trigger DNS queries during one SPF evaluation at 10: include:, a, mx, ptr, exists and redirect= each count, and every record they pull in adds its own terms to the total. A separate limit of 10 applies to the extra lookups that mx and ptr generate. The cap protects receivers from records that would otherwise trigger an unbounded number of queries.
Once the total passes 10 the receiver returns a permanent error and your record stops authenticating anything, so the checker shows both the count for your record and the chain total including nested records. If your record still contains ptr, remove it: RFC 7208 says it should not be used, and it costs lookups for no benefit.
Does SPF stop email spoofing on its own?
No. SPF authenticates the return-path domain used during the SMTP handshake, not the "From" address the recipient sees. An attacker can pass SPF with their own domain in the return-path while showing your domain in the visible From line.
DMARC closes that gap by requiring the From domain to align with the domain that passed SPF or DKIM, and by telling receivers to quarantine or reject mail that fails. Learn how DMARC protects your domain from spoofing, or run the free domain security check.
What is the difference between ~all and -all?
The qualifier on the closing all mechanism decides what a receiver should do with mail from a server that is not listed. -all (fail) asks receivers to reject it. ~all (softfail) asks them to accept it but treat it as suspicious, which under DMARC still counts as an SPF failure.
+all allows every server on the internet to send as your domain and defeats the purpose of publishing SPF. ?all (neutral) is equivalent to having no policy at all.
How often should I check my SPF record?
Whenever you add or remove an email service, and after any DNS change. Third-party includes also change on their own: a provider can add lookups to its record without telling you and push your chain total over the limit overnight.
The VerifyDMARC dashboard checks every domain's SPF record hourly, alerts you when the status regresses, and its Observed usage shows which mechanisms match real email traffic so you can remove the stale ones with confidence.