SPF record checker
Look up any domain's SPF record and read each mechanism in plain English: who may send as the domain, what happens to everyone else, and whether it is inside the ten-lookup limit. No signup.
Same check from your code
The API returns has_spf and has_dmarc on every email and domain score, and folds a missing policy into the risk score alongside domain age, MX and disposable detection — the check runs on every signup rather than one domain at a time.
curl "https://www.layercall.com/v1/score/domain?domain=example.com" \ -H "x-api-key: YOUR_KEY"
1,000 lookups a month free, no card. Get a key or read the docs.
What each signal means
include:
Borrow another domain's SPF record. include:_spf.google.com means 'whoever Google says may send, may send as me too'.
This is how every third-party sender is authorised — the mail provider, the CRM, the newsletter tool. It is also where records quietly grow past the lookup limit, because each include can contain more includes.
ip4: / ip6:
An address or CIDR range that may send as this domain. No DNS lookup involved.
The cheapest and most explicit mechanism. A record built from ip4: ranges cannot exceed the lookup limit, which is why large senders flatten their includes into these.
a / mx
The domain's own A records, or its MX hosts, may send as it.
Convenient for a small domain that sends from the server it receives on. Each one costs a lookup, and mx: can cost several — one per MX host.
The all qualifier
What happens to a sender matching nothing above. -all fails them, ~all softfails (accept but mark), ?all is neutral, +all passes everyone.
~all is the common cautious choice and -all the strict one. +all makes the record worthless: it authorises the entire internet. A record with no all term at all defaults to neutral, which says nothing about who is NOT allowed.
The ten-lookup limit
RFC 7208 allows at most 10 DNS-querying mechanisms per evaluation — include, a, mx, ptr, exists and redirect — counting the ones inside every nested include.
Over 10 and receivers return permerror, which most treat as a fail for EVERY sender. The failure is silent: mail just starts landing in spam. This tool counts the top level; the nested count is what actually bites.
Questions
What does an SPF record do?
It is a public list, in DNS, of the servers allowed to send email using your domain in the envelope sender. A receiving server looks up the sending IP against that list. It does not sign anything and it does not protect the From address a person sees — that is DKIM and DMARC. SPF answers one question: is this server on the list.
Why is my SPF failing for legitimate mail?
Usually one of three things. A sender you use is not in the record — a new tool, or one whose include: changed. The record exceeds ten DNS lookups, which fails everything with a permerror. Or the mail is being forwarded: forwarding rewrites the sending server, so SPF fails at the final hop, which is why DMARC is designed to pass on DKIM alone in that case.
~all or -all?
~all if you are not certain the record is complete; failures are accepted but marked, and you find the gaps in your DMARC reports without losing mail. -all once the reports are clean. Never +all, and if the domain sends no mail at all, v=spf1 -all says so in the shortest possible record.
How do I fix 'too many DNS lookups'?
Count the includes and what they include — this tool shows the top level, and each include: you see may contain several more. Remove senders you no longer use, replace an include with the ip4: ranges it resolves to where those are stable, or use a flattening service that maintains the ip4: list for you. The limit is ten in total, not ten per record.
Can I have two SPF records?
No. Two TXT records starting v=spf1 is a permerror — receivers treat it as no valid record. Merge them into one. This is the most common mistake after adding a new provider that told you to 'add' a record rather than edit the existing one.
Does SPF matter for fraud detection?
As one signal among several. A domain publishing neither SPF nor DMARC has not been set up to send mail properly, which describes most disposable and throwaway domains and a minority of legitimate ones. Our email scoring treats the absence as a small risk factor that becomes meaningful when the domain is also new, has no website, or is on a risky TLD.