SPF Checker
Validate any domain's SPF record, count its DNS lookups against the limit of 10, and catch the mistakes that quietly break email delivery.
What is SPF, in plain English?
SPF (Sender Policy Framework) is a DNS record that lists which mail servers are allowed to send email for your domain. When a receiving server gets a message from [email protected], it reads your SPF record and checks whether the sending server is on the list. If it is not, the message is flagged, sent to spam, or rejected outright — depending on how strict the receiver is and what your DMARC policy says.
Think of it as the guest list at the door. Your domain is the venue, your mail servers are the invited guests, and SPF is the list the bouncer checks. Anyone not on the list is treated as an impostor — which is exactly the point, because without SPF, anyone on the internet can send mail that claims to be from your domain.
The mistake that breaks most SPF records: the 10-lookup limit
SPF was designed in a simpler era, so it carries a hard rule from RFC 7208: evaluating a record may cause at most 10 DNS lookups. Every include:, every a, mx, ptr and exists mechanism costs lookups — and includes cost their own lookups too, recursively. Add Google Workspace, Microsoft 365, a marketing platform, a helpdesk and a CRM, and records sail past 10 without anyone noticing.
Past the limit, receivers return a PermError and treat your mail as if SPF does not exist. The cruel part: nothing bounces and nobody gets an alert. Your invoices and password resets just start landing in spam. Our checker counts lookups the way a receiver does — recursively, including every nested include — so the number above is the number that matters.
Reading your result
Ending matters. A record should end in -all (hardfail) once every legitimate sender is listed. ~all (softfail) is a testing setting, ?all says nothing at all, and +all is an open door — worse than having no record, because it actively tells receivers that every server on earth is authorised.
One record only. Two v=spf1 TXT records on the same domain is an automatic PermError. If you see that above, merge them into a single record.
Flattening is a trap. Tools that "flatten" SPF by replacing includes with IP addresses work until the provider changes its IPs — then your mail breaks silently. Reducing senders or using subdomains for third-party mail is the durable fix.
SPF is one leg of three
SPF alone cannot stop spoofing of the visible From address, and it breaks when mail is forwarded. That is why it works as a trio: DKIM signs the message itself, and DMARC ties SPF and DKIM to your domain and tells receivers what to do when they fail. Check all three — or run the Full Site Health Check and get them in one report.
SPF Checker — frequently asked questions
Why is my email going to spam even though SPF passes?
SPF passing only proves the sending server was authorised. Spam placement also depends on DKIM, DMARC alignment, blacklist status and content. Run the domain through our Blacklist Checker and the Full Site Health Check to see the whole picture.
How do I fix "too many DNS lookups"?
Remove senders you no longer use, replace a and mx mechanisms with explicit ip4:/ip6: entries where stable, and move third-party senders (marketing, ticketing) onto their own subdomain with its own SPF record.
Does SPF stop phishing with my domain?
Partly. SPF stops unauthorised servers sending as your domain's envelope address, but only DMARC with a quarantine or reject policy protects the From address your customers actually see.
How often should I check my SPF record?
Every time you add or remove a service that sends mail — and continuously, ideally. Records rot silently as providers change their infrastructure, which is why the monitoring version of this check exists.