SPF Record Checker
Validate your Sender Policy Framework record — mechanisms, DNS lookup count, and enforcement strength.
What is SPF?
Sender Policy Framework (SPF) is a DNS TXT record that specifies which mail servers are authorised to send email on behalf of your domain. Without a valid SPF record, your emails may be rejected or marked as spam by receiving mail servers.
Common SPF Issues
- • +all or ~all — allows any server to send, reducing protection
- • More than 10 DNS lookups — causes SPF to perma-fail at receiving servers
- • Multiple SPF records — only one TXT record starting with v=spf1 is allowed
- • ptr mechanism — deprecated and slow, remove it
What this SPF checker actually does
When you submit a domain, the checker queries the TXT records at the root of that domain (using Cloudflare 1.1.1.1 and Google 8.8.8.8 as resolvers, with one retry after a timeout or SERVFAIL) and picks out the record that starts with v=spf1. It then runs four checks: how many SPF records exist, what the effective all mechanism is, how many DNS lookups the record costs, and whether it uses the deprecated ptr mechanism.
It does not send any email and it does not test whether a specific IP address would pass. It reads and analyses the published policy, which is what you need when you are debugging a record, auditing a domain, or checking a record before you rely on it.
How to read each result field
| Field | What it means | What to aim for |
|---|---|---|
| Status | PASS, WARN or FAIL: the worst finding across all checks. | PASS |
| All Mechanism | The effective all at the end of the record, following redirect= if the record itself has none: -all, ~all, ?all, +all, or Missing. | -all once every sender is listed. ~all is acceptable while you finish inventorying senders. |
| DNS Lookups | Count of lookup-triggering terms, expanded through every include: and redirect= chain. Shown as n / 10. | 8 or fewer. 9 and 10 are valid but leave no room to add a sender. |
| Multiple Records | Yes means more than one TXT record at the root starts with v=spf1. | No |
| Mechanisms | Every term in the record except redirect= and exp=. | Only senders you recognise |
Status rules in plain terms: no record, multiple records, a missing or ?all ending, +all, or 11 or more lookups give FAIL. ~all, 8 to 10 lookups, or a ptr mechanism give WARN (unless something else already made it FAIL). Anything else is PASS. If a domain has several v=spf1 records, the checker analyses the first one it receives and flags the duplication.
How the lookup count is calculated
RFC 7208 section 4.6.4 caps SPF evaluation at 10 DNS-querying terms. The checker counts one for each include, a, mx, ptr, exists and redirect term. It then follows every include: and redirect= target and adds the lookups inside those records too. Terms that need no DNS query (ip4, ip6, all) cost nothing. A count of exactly 10 is valid; 11 or more is a violation, and receivers return a permanent error (permerror), which most treat as an SPF failure.
In the example below, the two includes cost 2 lookups, a and mx cost 2 more, and then everything inside Google's and Mailchimp's own records is added on top. Nested includes are where the budget disappears, which is why a short-looking record can still be over the limit.
Example record
v=spf1 include:_spf.google.com include:servers.mcsv.net a mx -all
For a worked walkthrough of getting a count back under the limit, see the guide to SPF too many DNS lookups.
Common SPF errors: cause and fix
| What you see | Cause | Fix |
|---|---|---|
| No SPF record found | No TXT record starting with v=spf1 at the domain root, or it was added to the wrong host (for example under www). | Publish a single TXT record at @ such as v=spf1 include:_spf.google.com ~all. |
| Multiple Records: Yes | A second v=spf1 record was added when a new service was set up, instead of editing the existing one. | Merge them into one record: combine all include:, ip4: and ip6: terms and keep a single all at the end. |
| Missing or neutral all | The record ends with ?all, or has no all at all, so receivers get no instruction for unlisted senders. | End the record with ~all or -all. |
| +all (or bare all) | Any server on the internet is authorised to send as your domain. | Replace with -all (or ~all while testing). |
| 11 / 10 lookups, over the limit | Too many includes, a and mx terms, often from stacked marketing, CRM and helpdesk tools. | Remove services you no longer use, replace a and mx with ip4: ranges, or move a high-volume service to a subdomain. |
| ptr mechanism warning | ptr is slow and unreliable, and RFC 7208 says not to use it. | Delete it and list the sending IPs or includes explicitly. |
| Record passes here but mail still fails SPF | The checker validates the policy, not the sending IP. The mail may come from an unlisted server, or the envelope sender domain may be different from the one you checked. | Read the Received-SPF or Authentication-Results header on a failing message to see the IP and domain that were evaluated. |
How to fix a failing record, step by step
- Run the checker and note the Status, the all mechanism, and the lookup count.
- List every service that sends mail as your domain: your mailbox provider, marketing platform, CRM, billing system, helpdesk, website forms, and any on-premises server. Check recent DMARC aggregate reports or message headers if you are unsure.
- If there are two or more v=spf1 records, delete them all and publish one merged record. DNS providers accept duplicates without complaint, so this error is easy to introduce.
- If the lookup count is above 10, remove dead services first. Then swap a and mx terms for the specific ip4: or ip6: ranges they represent, or move one bulk sender to a subdomain with its own SPF record.
- Start with ~all if you are not certain the list is complete, and move to -all once DMARC reports show no legitimate mail failing SPF.
- Save the change, wait for the old TTL to expire (often up to an hour), and re-run this checker to confirm the new Status and lookup count.
Best practices
- Keep lookups at 8 or fewer. Providers change their own records, so a nested include can add a lookup without any edit on your side.
- One record per domain, and a separate SPF record for each sending subdomain. Subdomains do not inherit the parent's SPF record.
- Do not rely on SPF alone. SPF usually breaks when a message is forwarded and only authenticates the envelope sender (Return-Path), so pair it with DKIM and a DMARC policy.
- Domains that never send mail should publish v=spf1 -all.
- Re-check after every change to your email stack. Adding a new tool is the most common way a working record goes over the limit.
Limitations of this checker
- It counts each unique include target once. A receiver counts every occurrence, so a record that repeats the same include can cost more at a real receiver than shown here.
- It does not enforce the separate limit of two void lookups (lookups that return no data) from RFC 7208, nor the limit on MX host names under the mx mechanism.
- It does not check whether an include: target actually publishes an SPF record, and it does not evaluate IP addresses, macros, or qualifiers on individual mechanisms.
- Only the root domain's TXT record is read. If a sending subdomain has its own record, check that subdomain directly.
- A DNS timeout is retried once and then treated as no record, so a slow nameserver can occasionally produce a false 'no record' result. Re-run the check if the result looks wrong.
Related tools and guides
SPF Record Generator
Build a correct single SPF record for your providers and IP ranges.
SPF too many DNS lookups
How the 10-lookup limit works and how to get back under it.
SPF hard fail vs soft fail
When to use -all and when ~all is the safer choice.
Add third-party senders to SPF
Add a new sending service without breaking your record.
Frequently Asked Questions
What is an SPF record and why do I need one?
An SPF (Sender Policy Framework) record is a DNS TXT record that lists which mail servers are authorised to send email on behalf of your domain. Receiving mail servers check SPF to verify the sending server is allowed. Without a valid SPF record, your emails may be rejected or marked as spam, and your domain is easier to spoof in phishing attacks.
What happens if my SPF record has more than 10 DNS lookups?
SPF has a hard limit of 10 DNS lookups per check. Exceeding this limit causes a permanent error (permerror), meaning SPF fails regardless of your actual sending infrastructure. This is a common misconfiguration for domains that use multiple email services — CRMs, marketing platforms, and helpdesk tools each add to the lookup count. The fix is to flatten include: mechanisms into direct IP ranges.
What does -all vs ~all vs +all mean in SPF?
-all (hard fail) tells receiving servers to reject mail from unlisted senders. ~all (soft fail) marks it as suspicious but still delivers it. +all (pass all) allows any server to send on your domain's behalf — this completely undermines SPF security and is never recommended. Use -all once all legitimate senders are listed in your record.
Can a domain have multiple SPF records?
No. Having more than one DNS TXT record starting with v=spf1 causes an SPF permanent error. Only one SPF record is allowed per domain. If you need to include multiple sending services, combine them into a single record using include: mechanisms or direct IP address ranges.
How do I fix an SPF record that is failing?
Common fixes include: reducing DNS lookups below 10 by flattening include: mechanisms into direct IP ranges; removing the deprecated ptr mechanism; merging multiple SPF records into one; changing +all or ~all to -all for stronger enforcement; and adding any missing mail servers or third-party sending services. Run this checker to identify which specific issue applies to your domain.