SPF Record Checker
Check whether a domain publishes a valid SPF record, and see how many of the 10 allowed DNS lookups it actually uses once every include is expanded.
An SPF record is a TXT record at your domain that lists which servers may send email as you. A checker confirms one record exists, that it starts with v=spf1, and that expanding every include, a, mx, ptr, exists and redirect term stays within the RFC 7208 limit of 10 DNS lookups.
Source: RFC 7208: Sender Policy Framework, published by IETF.
This tool reads public DNS records, specifically the TXT records published at the domain you enter, and follows the include and redirect targets those records name. SPF records are published by the domain owner for the express purpose of being queried by anyone. Results are a point-in-time snapshot from the resolver we used: DNS is cached and propagates unevenly, so a record changed in the last hour may not appear yet. We validate syntax, structure and the RFC 7208 lookup limit. We cannot tell you whether a specific message will pass SPF, since that depends on the sending server's IP address, and we cannot predict inbox placement. Terms using macros are counted but not expanded, because they resolve per message. 1Lookup is not affiliated with, endorsed by, or acting on behalf of any government agency, standards body or email provider named on this page.
Need this at scale? Email Validation API
Check deliverability on whole lists through the API or a bulk CSV upload.
What an SPF record does, and how it quietly breaks
SPF, the Sender Policy Framework, is a single line of DNS text that names the servers allowed to send email using your domain. Publishing one is easy. Keeping it valid is not. RFC 7208 caps the whole record at 10 DNS lookups once every include is followed, and going over that limit is a permanent error: receivers stop evaluating SPF for your domain entirely. Nothing bounces with a helpful message. Mail just starts failing authentication, usually weeks after somebody added one more marketing tool to the record.
Counting those lookups correctly means expanding the record. include, a, mx, ptr, exists and redirect each cost one lookup, and the count is global across the entire tree, not per record. ip4, ip6, all and exp cost nothing. Chains run deeper than people expect: servicenow.com nests nine levels through a flattening service. When we expanded 50 large brand domains on 13 August 2026, southwest.com came back at 11 of 10, a permanent error, and six others sat at exactly 10 of 10, one vendor away from breaking.
The other silent failure is publishing two SPF records. More than one is also a permanent error, and it is not rare: 1.2% of the 1,200 domains we sampled from the Tranco top 100,000 had multiple records, roughly one in 85. DNS returns them in random order, so a checker that shows you a single record is showing you a coin flip. We list all of them. What we cannot tell you is whether a given message will pass, because that depends on the sending IP of that message.
How the check works
We read every TXT record at the domain
Large domains publish a lot of TXT records: google.com returns 15, stripe.com returns 35. We keep only records whose version section is exactly v=spf1, which is what RFC 7208 requires, and we join multi-part records without adding spaces so the IP ranges inside them stay intact.
We expand the whole tree and count lookups
Every include and redirect is followed, and the target's record is fetched and expanded too, carrying one shared counter. include, a, mx, ptr, exists and redirect each add 1. ip4, ip6, all and exp add nothing. Over 10 in total is a permanent error under RFC 7208.
We report the count, the chain and the policy
You get lookups used out of 10, every domain in the expansion chain, the all qualifier translated into plain English, any void lookups, and a blocking red state if more than one SPF record exists. If a lookup times out we say we could not check, never that no record was found.
Real recursive lookup counting
The lookup limit is global across the full expansion, not per record, which is the part most free checkers get wrong. We follow every include and redirect, carry one counter, keep a visited set so loops cannot run away, and show the depth. Chains of nine levels are real and common enough to matter.
Multiple SPF records flagged, all of them listed
More than one v=spf1 record is a permanent error and receivers stop evaluating SPF entirely. DNS returns the records in a different order each time: eight queries against one domain in our testing returned four different first records. We show every record we find rather than picking one.
The all qualifier in plain English
-all asks receivers to reject forged mail. ~all tells them it is probably forged but to deliver anyway, usually to spam. ?all states no opinion. +all says anyone on the internet may send as you, which certifies forgeries as legitimate. We name which one you have and what it does.
Three honest result states, not two
Found, not found, and could not check. A timeout or a broken nameserver on the domain's side is not the same as having no SPF record, and reporting it that way would be wrong. We also flag ptr, which RFC 7208 says should not be used, and macro terms that can only be resolved per message.
Who uses this tool
Before adding another sending tool
Every new CRM, help desk or newsletter platform usually asks you to add one more include. Check the current count first. If you are at 9 or 10 of 10, the next one breaks SPF for your whole domain, and six of the 50 large brands we expanded were sitting in exactly that position.
When mail suddenly starts landing in spam
A permanent SPF error produces no bounce and no warning. If deliverability dropped and nobody changed the mail platform, checking whether the record now exceeds 10 lookups or whether a second record appeared is the fastest thing to rule out before you start blaming content or reputation.
Auditing client or portfolio domains
Agencies and IT providers inherit domains with records nobody has read in years. Run each one, note the lookup count and the all qualifier, and you have a concrete list. In our 1,200-domain sample, 30.6% had no SPF record at all, so expect gaps rather than subtle problems.
Vendor and partner review
Before you accept mail flows or shared sending from a partner, look at what their domain actually publishes. A record ending in ?all or a domain with no SPF at all tells you that anyone can forge their address, which changes how much you should trust mail claiming to be from them.
Frequently asked questions
What is the SPF 10 lookup limit?
RFC 7208 says an SPF evaluation must not use more than 10 DNS-querying terms in total, counted across the whole record after every include and redirect has been followed. Exceed it and receivers must return permerror, which means SPF is not evaluated for your domain at all. That is worse than having no record, and nothing in your normal mail flow tells you it happened.
Which parts of an SPF record count toward the 10?
Six terms count one each: include, a, mx, ptr, exists and redirect. Four cost nothing: ip4, ip6, all and exp. So you can list hundreds of IP ranges for free, but a handful of vendor includes will use up the budget. Two separate sub-limits also apply: an mx term fails if the domain has more than 10 MX hosts, and more than two void lookups, meaning terms pointing at names with no record, is treated as an error by most receivers.
What is the difference between -all and ~all?
-all is Fail: nobody other than the listed servers may send as you, and receivers may reject forged mail outright. ~all is SoftFail: forged mail is usually still delivered, often to the spam folder. It is a normal deliberate choice while rolling SPF out. Across the 833 domains with SPF in our sample, 48.0% used ~all and 46.5% used -all. Avoid +all entirely, it tells receivers that anyone on the internet is authorised to send as you.
Can a domain have two SPF records?
It can publish two, but it should not. RFC 7208 says more than one v=spf1 record produces a permanent error, so receivers cannot evaluate SPF at all. We measured this on 1.2% of 1,200 sampled domains, about one in 85, with one domain publishing six separate records. Because DNS returns them in a random order, any tool that shows you one record here is showing you an arbitrary pick. Merge them into a single record.
Does a valid record mean my email will pass SPF?
No, and no checker can tell you that. SPF passes or fails per message, based on the IP address of the server that actually sent it, which a DNS check never sees. What we can verify is the record itself: that exactly one exists, that its syntax is valid, that the expansion stays within 10 lookups, and what its all qualifier asks receivers to do. Correct DNS also does not guarantee inbox placement, since reputation, volume and content drive that.
How many domains have no SPF record at all?
In a random sample of 1,200 domains drawn from the Tranco top 100,000 and measured on 13 August 2026, 30.6% had no SPF record, 68.3% had exactly one, and 1.2% had more than one. That is our own measurement with its method stated, which matters because published vendor figures on email authentication disagree with each other by wide margins depending on whose customers they count.