SPF record checker
Enter a domain. We read its SPF record, follow every include one level down, and count the DNS lookups the record really costs.
The ten-lookup limit is where most records break
An SPF record is one line of text, and it looks harmless. The trouble is that each include sends the receiving server off to fetch another record, which may contain its own includes. RFC 7208 caps the whole chain at ten DNS lookups, and past that the record evaluates to permerror.
A permerror is worse than it sounds. Some receivers treat it as neutral, some as a fail, and DMARC will not count the result as a pass either way. So the domain that added one more marketing tool last quarter stops authenticating, nothing in the record looks wrong, and the mail starts landing in spam.
Four includes is usually where domains get uncomfortable. Google Workspace spends four on its own, and a typical stack of Workspace plus one ESP plus a helpdesk plus a CRM is already close to the edge.
The fix is to stop paying for lookups you do not need. Drop providers you no longer send through. Replace an include with the ip4 ranges behind it when the provider publishes stable addresses, since an ip4 term costs nothing. And drop the mx mechanism if your mail servers do not send outbound mail, which on a hosted domain they usually do not.
| Mechanism | Costs a lookup | What it authorizes |
|---|---|---|
| ip4 / ip6 | No | The address or range you name |
| a | Yes | Whatever the domain's A record points at |
| mx | Yes, one per exchanger | The servers that receive your mail |
| include | Yes, plus whatever that record spends | Everything the other domain authorizes |
| ptr | Yes | Deprecated. Slow, and some receivers ignore it |
Counted per RFC 7208 section 4.6.4.
Reading the ending
The last term decides what happens to everyone the record did not list. Most working records end in ~all, a soft fail, which asks receivers to accept the mail and treat it with suspicion. It is the right setting while you are still discovering who sends as your domain.
A hard fail, -all, asks receivers to reject outright. It is the stronger position and the one to move to, but only after your DMARC reports show that nothing legitimate is failing. Turning it on early is how a company discovers that its invoicing system was sending through a server nobody documented.
Two endings are worth fixing on sight. A record ending in +all authorizes the entire internet to send as your domain, which is never what anyone meant. A record ending in ?all is neutral, which says you have no opinion, and is not far from having no record at all.
Questions people ask
Do I need SPF if I already have DKIM?
Yes. DMARC passes when either one aligns, so having both gives you two chances rather than one. Forwarding breaks SPF routinely and leaves DKIM intact, which is exactly why the pair exists.
Why does my record pass here and fail at the receiver?
Usually because the receiver counted a lookup we did not, or an include resolved differently from where they queried. DNS answers vary by resolver and by the moment you ask.
Should a domain that sends no mail have an SPF record?
Yes, and it should be the strictest one there is: v=spf1 -all. That tells receivers nothing may ever send as this domain, which closes off a parked domain as a spoofing route.
Does SPF apply to the From: address people see?
No. SPF checks the envelope sender, which is usually the Return-Path and often a different domain entirely. Lining those two up is DMARC alignment, not SPF.
Authentication is one half. The list is the other.
A perfect SPF record on a list full of dead addresses still bounces. We tell you which addresses we could settle and which nobody can.