SPF Record Checker
Queries a public record from our server — not your files.
Check the SPF record a domain actually publishes, and get the number that matters: the total DNS lookups receivers will perform. That count is recursive — one include: can contain several of its own — so a record that looks like it uses four can already be past the limit of ten and failing every message. This follows the whole include tree and shows it. Doing that needs a resolver, so the domain you enter is sent to our server, which queries public DNS records for it; no file of yours is involved.
This tool is an exception on this site. Everything else here runs entirely in your browser, but a web page cannot query DNS, read a certificate or see another site’s response headers — so the name or URL you enter is sent to our server, which looks up the public record and sends the answer back. The answer is cached for up to a minute. No file of yours is read, uploaded or stored, and there is no account.
How to use SPF Checker
- 1
Enter the domain that sends your mail — the one in the From: address.
- 2
Read the lookup count first. Over 10 is a permanent error, and 8 or 9 is a record about to break on its own.
- 3
Work down the include tree to find which provider is spending the lookups.
Share
Embed this tool on your site
Paste this where you want the tool to appear. It runs entirely in your visitor's browser — no uploads, no account, no tracking.
Please keep the attribution line — it's what keeps these tools free.
Need a different size, a dark theme, or a different tool? Build an embed lets you preview it first.
Frequently asked questions
Does this send my data anywhere?+
It sends the domain name, and the domain of every include: found inside its record, to our server, which resolves each one against public DNS. SPF records are published to the entire internet by design — that is how receiving mail servers read them. Nothing else leaves your machine.
My record only has four includes. Why does it say twelve lookups?+
Because each include: is a whole record of its own, and the mechanisms inside it count too. _spf.google.com alone expands into several. RFC 7208 caps the total at ten across the entire recursion, which is why a record can be over the limit while looking short — and why most SPF tools, which count only the terms they can see, report a number that receivers do not agree with.
What actually happens when a record goes over 10?+
Receivers must return permerror. Many treat that as an outright fail, so mail that would otherwise have been delivered is rejected or filed as spam — and nothing tells you. The usual way this happens is that a provider adds an include to their own record, silently pushing yours over, months after you last touched it.
How do I get back under the limit?+
Remove includes for services you no longer use, which is nearly always the first win. Replace a low-traffic provider's include with the ip4: ranges it publishes, accepting that you now have to watch for changes. Move a marketing platform to its own subdomain with its own record. Flattening services do the same thing automatically and keep the result up to date.
Is ~all or -all correct?+
-all is a hard fail and the destination; ~all is a soft fail and the safe place to sit while you confirm nothing legitimate is missing. What is never correct is +all, which authorises the whole internet, or no all at all, which is exactly as protective as publishing no SPF record.