SPF Record Checker
Look up any domain's SPF record and validate it against RFC 7208: syntax, sender mechanisms, the 10-lookup limit and the mistakes that silently break email authentication.
About SPF Record Checker
SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are allowed to send email using your domain in the envelope-from address. Receiving servers read it to tell genuine mail from forgeries. This checker queries your domain's TXT records from our EU-based recursive resolver, isolates the record beginning with v=spf1, and breaks it into its individual mechanisms and qualifiers so you can see precisely what your published policy authorises.
Every mechanism carries a qualifier that decides how matching mail is treated. A leading plus (pass) is the default, minus is a hardfail, tilde is a softfail and question mark is neutral. The tool surfaces your terminal policy and flags the dangerous ones: +all lets the entire internet send as your domain, ?all offers no protection at all, and a record with no closing all or redirect is effectively undefined. It also warns on the deprecated ptr mechanism and on records approaching the 512-byte UDP answer limit.
The single most common reason SPF fails in the real world is the DNS-lookup limit. Mechanisms such as include, a, mx, ptr, exists and redirect each trigger a lookup, and nested includes from your SaaS and email providers add more. RFC 7208 caps this at 10; go over and receivers return a permerror and stop evaluating. The checker walks every nested include recursively and shows the true total, so you catch a flattening problem before your mail does. It also detects the case of two SPF records on one domain, which is itself a permerror.
Because the lookup runs server-side from our own European infrastructure rather than a third-party API, results reflect a neutral, public view of your DNS with no account and no data retention.
How to use it
- 1Enter the domain you send mail from (for example example.eu) - use the exact sending domain, not a subdomain unless that subdomain sends its own mail.
- 2Run the check; the tool fetches the domain's TXT records and extracts the record starting with v=spf1.
- 3Review the parsed mechanisms, their qualifiers and the terminal all policy the checker reports.
- 4Confirm the DNS-lookup counter stays at or below 10, following nested includes.
- 5Fix any flagged errors or warnings, republish the record, and re-run to confirm.
Common use cases
- -Diagnosing why legitimate mail is rejected or lands in spam
- -Confirming a new email provider or ESP is authorised before cutover
- -Auditing the 10-lookup limit after adding SaaS senders
- -Catching a duplicate SPF record left behind after a migration
- -Verifying the record before tightening ~all to -all
Frequently asked questions
- What is an SPF record?
- An SPF record is a DNS TXT record beginning with v=spf1 that lists the IP addresses and mail servers authorised to send email for a domain. Receiving servers check it to detect forged senders.
- How many DNS lookups can an SPF record have?
- SPF permits a maximum of 10 DNS-querying mechanisms (include, a, mx, ptr, exists and redirect). Exceeding 10 causes a permerror and receivers stop evaluating the record. This checker counts them recursively across every nested include.
- What is the difference between ~all and -all?
- ~all (softfail) marks unauthorised mail as suspicious but usually still delivers it, while -all (hardfail) tells receivers to reject it. ?all is neutral and provides no protection, and +all lets anyone send as your domain and should never be used.
- Can a domain have more than one SPF record?
- No. RFC 7208 requires exactly one v=spf1 record per domain. Two or more produce a permanent error and receivers ignore SPF entirely, so you must consolidate them into a single record.
- Does SPF alone stop email spoofing?
- No. SPF only authorises the envelope sender and does not survive message forwarding. Combine it with DKIM and a DMARC policy for reliable protection against spoofing.
- Where does this SPF check run?
- The lookup runs server-side from our EU infrastructure using a self-hosted recursive resolver, so results reflect a neutral public view of your DNS without relying on any third-party service.