Free tool
Validate a domain's SPF record and catch the mistakes that hurt deliverability.
Enter a domain to check its SPF configuration.
SPF (Sender Policy Framework) is a DNS record that lists which servers are allowed to send email for your domain. Receiving servers check it to help decide whether your mail is legitimate.
Common SPF mistakes silently damage deliverability: having two SPF records, exceeding the ten DNS-lookup limit, or ending with a permissive +all. This checker reads your record and flags each of these, with an approximate lookup count.
SPF is a TXT record on the domain your mail is sent from, strictly the domain in the envelope sender (the return path). It starts with v=spf1, lists the servers allowed to send, and ends with an all mechanism that covers everyone else:
example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 include:_spf.google.com -all"
ip4: and ip6: allow addresses or ranges directly and cost no DNS lookups. include: pulls in another domain's SPF policy, which is how services such as Google Workspace (include:_spf.google.com) and Microsoft 365 (include:spf.protection.outlook.com) are authorised. a and mx allow the addresses in the domain's own A or MX records.
The all mechanism comes last. -all (hard fail) says mail from anywhere else is not authorised, ~all (soft fail) asks receivers to treat it as suspicious, ?all is neutral and +all allows the whole internet. A domain may publish only one SPF record, so each new service is added to it rather than given a record of its own.
It reads the TXT records on the domain you enter, live from Google Public DNS (8.8.8.8) with Cloudflare (1.1.1.1) as the fallback, then shows the SPF record it found and a line for each check. Nothing is stored. The overall result is the worst of the individual checks.
Presence and duplicates. No v=spf1 record is a fail. More than one is also a fail, because RFC 7208 treats it as a permanent error and receivers may then ignore SPF altogether. When there are several, the remaining checks look at the first.
The all mechanism. -all and ~all pass. ?all is a warning because it gives no real protection, and +all or a bare all is a warning because it authorises any server. A record with no all mechanism is a warning too, since it leaves the default undefined.
DNS lookups in the record. It counts the terms in your record that cost a lookup: include:, a, mx, ptr, exists: and the redirect= modifier, with or without a domain, and fails the record above 10. Treat that number as a floor, not a full audit: the checker does not open each include, and the lookups inside them count towards the limit as well. If your record has several includes, expand them by hand (below) before trusting a low number.
A second SPF record for a new service. Merge them: one record, several includes, one all at the end.
Too many lookups. Each email platform's include can contain several lookups of its own. Remove includes for services you no longer use, replace a and mx with ip4: or ip6: ranges where the addresses are stable, and drop ptr, which RFC 7208 says should not be used.
Moving to hard fail too early. If a legitimate sender is missing from the record, -all can get its mail rejected. Many domains run ~all while they review DMARC reports, then tighten.
Relying on SPF alone. SPF breaks when mail is forwarded, because the forwarding server is not in your record, and it checks the envelope sender rather than the From address people see. DKIM signatures survive forwarding, and DMARC ties both to the visible From address, so set up DKIM and DMARC as well.
On macOS or Linux, run dig TXT example.com +short. On Windows, use nslookup -type=TXT example.com, or in PowerShell Resolve-DnsName -Name example.com -Type TXT. Look for the string that starts with v=spf1.
To count lookups properly, repeat the query for each include: domain, for example dig TXT _spf.google.com +short, and keep going until no includes are left. Add one for every include, a, mx, ptr, exists and redirect you meet along the way; the total must stay at 10 or below.
The TXT record lookup lists every TXT record on the domain, which helps when verification tokens sit next to SPF. A PulseStack™ DNS record monitor on a paid plan can watch the TXT record as often as every five minutes and alert you when no record contains the include or value you expect, so an accidental edit does not go unnoticed.
No. RFC 7208 permits exactly one SPF record per domain. Multiple v=spf1 records cause a permerror and receiving servers may ignore SPF entirely. Merge them into a single record.
Terms that make the receiving server do a DNS lookup (include, a, mx, ptr and exists, plus the redirect modifier) are capped at ten per check, and the lookups inside every include count too. Going over the limit causes a permerror, so keep includes lean.
Use -all (hard fail) for the strictest policy once you are confident every legitimate source is listed, or ~all (soft fail) while testing. Avoid ?all (neutral) and never use +all, which authorises anyone to send.
No. SPF is checked against the exact domain in the envelope sender, and records are not inherited. A subdomain that sends mail, such as news.example.com, needs its own SPF record, and names that never send mail can publish v=spf1 -all to say so.
Every one runs a real check, live, with nothing to install.
PulseStack™ DNS record monitors watch TXT records, including SPF, as often as every five minutes and alert you when the value you expect disappears. Included from the Starter plan at £9 a month, with a 14-day trial and no card.