Skip to content
BlacklistMonitoring
Free tool

SPF Checker

This SPF checker reads your domain's SPF record, validates the syntax, follows every include and counts the DNS lookups against the RFC 7208 limit of 10. It flags duplicate records, void lookups and risky settings, and tells you how to fix each one.

Checks run by DNS only. Nothing is sent from or to your domain.

What SPF does

SPF (Sender Policy Framework) is a DNS TXT record that lists the servers allowed to send email for your domain. When a message arrives, the receiving server takes the domain from the envelope sender (the Return-Path), looks up its SPF record and checks whether the connecting IP is on the list. The result is pass, fail, softfail, neutral, none, or an error.

SPF on its own only checks the Return-Path, which recipients never see. To protect the visible From address, SPF has to align with it under DMARC. That is why SPF, DKIM and DMARC work as a set. Check the other two with the DKIM checker and the DMARC checker.

How to read an SPF record

A typical record looks like v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all. It always starts with v=spf1 and is read left to right until a term matches.

TermMeaningCounts toward 10 lookups
ip4 / ip6Allows a single IP or a rangeNo
includePulls in another domain's SPF record, used for email servicesYes, plus every lookup inside it
a / mxAllows the IPs in your A or MX recordsYes
ptrReverse DNS match, slow and discouraged by RFC 7208Yes
existsAdvanced, matches if a built name resolvesYes
redirectUses another domain's record insteadYes
-all / ~allFail or softfail everything not listedNo
Sysadmin editing DNS records on a laptop next to a printed checklist

The 10 lookup limit and void lookups

RFC 7208 limits SPF evaluation to 10 DNS lookups. Every include, a, mx, ptr, exists and redirect counts, and so does everything inside each include. Many email services use several lookups in their own records, so adding a CRM, a help desk and a newsletter tool can push you over without anyone noticing. Past 10, receivers return permerror, and SPF fails for all your mail, not just the newest service.

The same RFC limits void lookups to 2. A void lookup is one that returns no answer, for example an include pointing to a domain that no longer has an SPF record. Old includes for tools you stopped using are the usual cause.

  • Remove includes for services you no longer use.
  • Replace a and mx with ip4 ranges when those addresses are stable.
  • Move some senders to a subdomain with its own SPF record, for example news.yourcompany.com.
  • Be careful with flattening tools that replace includes with IPs. Providers change their IPs and a flattened record goes stale.

How to check SPF manually

  1. 1 Run dig +short yourcompany.com TXT and find the line starting with v=spf1.
  2. 2 Make sure there is only one. Two SPF records on the same domain cause a permerror.
  3. 3 For each include, run the same lookup on the included domain and count its lookups too.
  4. 4 Add them up. The total must be 10 or fewer.
  5. 5 Check that every service sending as your domain is covered, then send a test message to Gmail and confirm spf=pass in Show original.

Common SPF mistakes

  • Two separate v=spf1 records instead of one combined record.
  • Ending with +all, which allows anyone in the world to pass SPF as you.
  • Leaving out a service, so its mail fails SPF and can only pass DMARC through DKIM.
  • Typos such as include: sendgrid.net with a space, which breaks the term.
  • Adding SPF to a subdomain and expecting the parent domain to cover it. Each domain needs its own record.
  • No SPF on domains that never send mail. Publish v=spf1 -all there so spammers cannot use them.

SPF and the bulk sender rules

Since February 2024, Gmail and Yahoo require every sender to pass SPF or DKIM, and bulk senders (over 5,000 messages a day) to have SPF and DKIM together plus DMARC. Microsoft requires the same for high volume senders to Outlook.com since May 2025. A permerror from too many lookups counts as a failure under these rules. The email deliverability test checks SPF together with the rest of your setup.

Keep SPF valid over time

SPF records break when someone adds a new tool or when a provider changes its own record, which moves your lookup count without any change on your side. BlacklistMonitoring rechecks SPF for every domain you add, counts lookups each time and alerts you before or when the record breaks, with a finding like "SPF uses 12 DNS lookups (limit 10): receivers return permerror." On Business and higher plans, sender source discovery from DMARC reports shows every service sending as your domain, so you know what SPF needs to cover. See DMARC monitoring and the pricing page.

Frequently asked questions

How do I check my SPF record?

Enter your domain in the checker above. It shows the record, validates it and counts DNS lookups. Manually, run dig yourdomain.com TXT and look for the line starting with v=spf1.

What happens if SPF has more than 10 lookups?

Receivers stop evaluating and return permerror, which counts as an SPF failure for every message. Mail can still pass DMARC through aligned DKIM, but you lose SPF as a backup.

Should I use ~all or -all?

Both work once DMARC is in place, since DMARC policy decides what happens to failing mail. Many teams use ~all while setting up and move to -all once every sender is covered. Never use +all.

Can I have two SPF records?

No. A domain must have exactly one SPF record. Two records cause a permerror. Combine all includes and IPs into one record that starts with v=spf1.

Is SPF enough to stop spoofing?

No. SPF checks the hidden Return-Path, not the From address people see. You need DMARC with SPF or DKIM alignment, and a policy of quarantine or reject, to block spoofing of your visible domain.

Stop finding out from your clients

Every domain and IP you send from, watched around the clock, with the fix in every alert.