DDDevDomeTrack. Protect. Grow.

SPF Checker

Finds the SPF record for your domain and validates it against the rules receivers actually enforce: exactly one record, at most 10 DNS lookups, no +all. Every finding cites the record text.

Your browser queries these services directly, so the name you look up and your IP address are visible to them: Cloudflare DNS and Google Public DNS (both public recursive resolvers) for records and comparison, and rdap.org, a redirector that forwards to the registry's RDAP server, for registration data. DevDome does not proxy, see or store these lookups. Privacy policy.

Run a lookup to get an evidence-based summary: web resolution, delegation, DNSSEC, email records, CAA and expiration, each with the observation behind it.
Enter a name above to query common DNS records (A, AAAA, CNAME, MX, TXT, NS, SOA, CAA) from a public recursive resolver, or pick a specific type including DS, DNSKEY, SRV, TLSA, SVCB and HTTPS.
Registration data appears here via RDAP: registrar, creation and expiration dates, EPP status codes, nameservers and DNSSEC delegation state.
SPF and DMARC analysis appears here: record syntax, the 10-DNS-lookup limit, policy strength and common misconfigurations, with the exact records as evidence.
Compares one record type between Cloudflare and Google. These are observations from two public recursive resolvers, not proof of global propagation. Add an expected value above to check whether your change is visible to each.

The three SPF mistakes that silently break mail

Almost every SPF-caused delivery failure is one of three publishing mistakes, and all three are checkable from the record alone. Multiple v=spf1 records: receivers return permerror instead of merging them. More than 10 DNS lookups: include chains from years of accumulated services blow the RFC 7208 budget and, again, permerror. And +all, sometimes pasted from a misread tutorial, which authorizes every server on earth and tells reputation systems to ignore your record entirely. The checker above tests all three and shows the lookup count against the limit.

What no record checker can see is whether your real sending infrastructure is covered: that requires watching authentication results over time. If the syntax is green here but delivery is not, the next step is a DMARC record with rua reporting, which turns receiver verdicts into weekly evidence.

Set up the feedback loop: DMARC checker →

SPF FAQ

What does an SPF record do?

SPF publishes, in a TXT record starting v=spf1, the list of servers allowed to send mail claiming to be from your domain. Receivers check the connecting server against that list. It is one leg of the email authentication tripod with DKIM and DMARC: SPF authorizes the sending server, DKIM signs the message content, and DMARC tells receivers what to do when both fail.

What is the SPF 10 DNS lookup limit?

RFC 7208 caps the DNS lookups an SPF check may perform at 10: every include, a, mx, ptr, exists and redirect counts, and nested includes count all the way down their chain at evaluation time. Go over and receivers return permerror, which DMARC treats as failure. This checker counts the lookup mechanisms visible in your record; note that nested includes resolve to more lookups than the top-level count shows, so staying well under 10 at the top level is the safe practice.

Why are two SPF records worse than none?

RFC 7208 requires exactly one record starting v=spf1. Two or more is a permanent error: receivers do not merge them, they fail the check entirely, so your legitimate mail authenticates worse than if you had published nothing. It usually happens when a new email service’s setup guide says "add this TXT record" and someone adds instead of merges. The fix is one record with all includes combined.

Should my SPF record end with -all or ~all?

-all (fail) tells receivers to reject unlisted senders outright; ~all (softfail) marks them suspicious and lets DMARC make the final call. Modern practice: use ~all while you are still confirming every legitimate sender through DMARC reports, then either stays defensible since DMARC alignment is what actually drives enforcement. Never use +all: it authorizes the entire internet and makes your SPF record meaningless.

My SPF record is valid but mail still fails. Why?

Syntax is necessary, not sufficient. The usual causes: the actual sending server is not covered by any mechanism (common after adding a new tool that sends email), the mail fails alignment because the envelope-from domain differs from your visible domain, or a forwarder breaks SPF by design, which is what DKIM survives and SPF does not. Aggregate DMARC reports are the only reliable way to see which servers are failing and why.

More free tools: DMARC Checker · MX Lookup · TXT Lookup · DNS & WHOIS Lookup