SPF checker
An SPF record is a DNS TXT record on your domain, beginning with v=spf1, that lists which hosts are authorised to send mail using that domain as the envelope sender. This checker reads the record, breaks it into its mechanisms, and counts how many DNS lookups an evaluation costs — following every include: and redirect= down to the bottom, because RFC 7208 charges the whole chain against a hard limit of ten. Over that limit the evaluation returns permerror and receivers treat SPF as failed, which is the failure this tool exists to catch. It also flags a missing record, duplicate records, +all, and the deprecated ptr mechanism.
Run the check
Result
Enter a domain to run the check. Results appear here.
How the check works
The first query is a TXT lookup on the domain itself — SPF has no dedicated record type, and the experimental SPF RR type was deprecated in RFC 7208. Records beginning with v=spf1 are SPF records; anything else at the name, and most domains have several, is ignored. Finding two is a result in itself, because RFC 7208 section 4.5 makes duplicate records a permanent error.
The record is then split into terms. Each term has an optional qualifier — plus for pass, minus for fail, tilde for softfail, question mark for neutral, with plus assumed when none is written — and a mechanism. Six of those mechanisms make DNS queries: include, a, mx, ptr, exists and the redirect modifier. Each costs one of the ten. ip4: and ip6: cost nothing at all, which is the entire logic behind flattening a record that has grown too expensive.
The count is what makes this worth running, because it is not local. Every include: is expanded and the target record's own querying terms are added to the same budget, recursively, so a record with three includes can be eleven lookups deep without a single line of it looking wrong. It also means your count can change without you touching your DNS: a provider you include adds a mechanism to their record, and yours goes over the limit. The expansion here is cycle-safe — an include loop is a real thing people publish — and bounded by a query budget. When a branch cannot be expanded, because it timed out or uses a macro that only resolves against a real message, the result is reported as a floor rather than a total.
One nuance worth knowing: the ten-lookup cap is not the only limit in RFC 7208. The mx mechanism counts as one lookup but may not resolve more than ten MX hosts, and there is a separate limit of two void lookups — queries that return nothing. This tool counts against the ten-term limit, which is the one that breaks real sending stacks.
A worked example
v=spf1 ip4:203.0.113.0/24 include:_spf.example-esp.com include:servers.example-crm.net mx ~all
This record costs at least three lookups before anything is expanded: include:_spf.example-esp.com, include:servers.example-crm.net and mx. The ip4:203.0.113.0/24 range is free — the addresses are written in the record, so nothing has to be resolved to use them. Then the two includes are expanded, and whatever querying terms their records contain are added to the same budget of ten. If the ESP's record contains four includes of its own, this record is at seven and the owner has no way of knowing from reading it. ~all closes it: anything not matched above softfails, so receivers accept and mark rather than reject.
Questions
- What is an SPF record?
- A DNS TXT record on the domain itself, beginning with v=spf1, that lists the hosts authorised to send mail using that domain in the envelope sender. A receiving server takes the connecting IP, evaluates the record against it, and gets back pass, fail, softfail, neutral, none, temperror or permerror. It is defined by RFC 7208.
- What is the SPF 10-lookup limit?
- RFC 7208 section 4.6.4 limits a single SPF evaluation to ten DNS-querying terms. The include, a, mx, ptr and exists mechanisms and the redirect modifier each cost one, and the cost is counted across everything reached through include: and redirect=, not just the terms you wrote. Exceed it and the evaluation returns permerror, which receivers treat as a failed SPF check rather than as an unknown.
- Which parts of an SPF record are free?
- ip4: and ip6: cost nothing, because the address is in the record and no query is needed to find it. So does all. This is why flattening — replacing an include: with the IP ranges it resolves to — reduces the lookup count. The trade is maintenance: a flattened record is a snapshot, and it goes wrong silently the day the provider changes its ranges.
- Can I publish two SPF records?
- No. RFC 7208 section 4.5 requires the evaluation to return permerror when more than one v=spf1 record is found on a name. The records are not merged and the receiver does not pick the better one. This is the usual result of adding a second sending platform by publishing its record alongside the existing one instead of adding an include: to the record already there.
- What is the difference between ~all and -all?
- ~all is softfail: hosts not matched are not authorised, but receivers are asked to accept the mail and mark it rather than reject it. -all is fail: receivers may reject outright. -all is the stronger statement, and it is safe only once you are confident every legitimate sender for the domain is covered by the record — which, with DMARC in place, is a question the aggregate reports answer for you.
- Why does SPF still fail when the sending IP is listed?
- Usually because SPF is checked against the envelope sender rather than the From header the recipient sees, and under DMARC the two have to align. A platform sending on your behalf commonly uses its own domain in the envelope, so SPF passes for that domain, not for yours. Alignment, not the raw SPF result, is what DMARC evaluates.
The rest of the set
DMARC checker
One TXT lookup, every tag translated, and the four conditions that make a record useless.
DKIM checker
Selector lookup or fourteen common selectors tried at once, with exact key sizes.
Blacklist checker
Domain and MX hosts resolved to IPs, checked against blocklists verified live on every request.
Read further
- SPF records for cold email: the 10-lookup limit that breaks multi-domain sending
- Google Workspace SPF record: step by step, with the failure modes
- SPF, DKIM and DMARC for cold email: the setup that keeps you out of spam
- Glossary: email authentication
For the economics rather than the DNS, our free calculators cover cost per meeting, cold email ROI and a spam word checker that runs in your browser.
Authentication is the floor, not the plan.
An SPF record inside the lookup limit is table stakes. Whether the mail gets read depends on who you targeted and what you wrote — which is the part we run for clients, paid on meetings that get attended rather than on emails sent.