SPF Record Checker: Validate Your Setup in Minutes

An SPF record checker looks up your domain's SPF TXT record, confirms it is syntactically valid, checks it is the only SPF record on the domain, and counts how many DNS lookups it triggers so you can see if you are near the 10-lookup limit that breaks authentication. Run one before every DNS change involving email, not just when something already looks wrong.

SPF (Sender Policy Framework) is a DNS TXT record that lists which servers are allowed to send email for your domain. Get it wrong and mailbox providers either fail your authentication outright or, worse, silently let a misconfiguration sit there until the day you add a new sending tool and everything breaks at once. A checker turns that guesswork into a pass or fail you can see in seconds.

Key takeaways

• An SPF record checker validates three things: correct syntax, a single record per domain, and a DNS lookup count under the RFC 7208 limit of 10.
• Exceeding 10 DNS lookups, or publishing two SPF TXT records, both produce a PermError, which DMARC treats as an outright SPF fail, not a soft warning.
• SPF alone is not enough. It protects the invisible Return-Path domain, not the From address your recipient sees, which is why SPF, DKIM, and DMARC are checked and set up together.
• Checking is not fixing: after you merge duplicate records or cut DNS lookups, always re-run the checker to confirm the change actually published and propagated.
• Free checkers (MxToolbox, dmarcian's SPF Surveyor, Kitterman's validator) cover the syntax and lookup-count check well; you do not need a paid tool for a single-domain validation.

What an SPF record checker actually tests

A good SPF checker runs three separate checks, and knowing which one failed tells you exactly what to fix.

Existence and syntax. Does a TXT record starting with v=spf1 exist at all, and is every mechanism after it spelled and ordered correctly? A missing v=spf1 tag, a misspelled mechanism like ip: instead of ip4:, or a trailing character after your all qualifier will all fail this check even if the record looks fine to a human eye.

Record uniqueness. RFC 7208 permits exactly one SPF record per domain. If you or a vendor added a second TXT record starting with v=spf1, the receiving server cannot decide which one applies and returns a PermError, which fails the whole domain's SPF, not just the newer record.

DNS lookup count. Every include, a, mx, ptr, and exists mechanism, plus any redirect modifier, costs one DNS lookup, and nested includes chain further lookups on top. RFC 7208 caps the total at 10. Go over, and the result is a PermError that DMARC scores as a fail, even though your record is syntactically correct.

A checker worth using shows you the raw record, flags which of these three checks failed, and (for the lookup count) breaks down which mechanism is consuming your budget so you know what to trim. An SPF checker is one piece of a broader pre-send validation habit: see how to test email deliverability before you send for the fuller checklist beyond just SPF.

How to check your SPF record in under 5 minutes

1. Look up the raw record first. Run dig TXT yourdomain.com (or use any DNS lookup tool) and confirm you see one line starting with v=spf1. If you see two, that is your first problem, and no checker output matters until you merge them.
2. Run it through a dedicated SPF checker. Paste your domain into a validator such as MxToolbox's SPF check, dmarcian's SPF Surveyor, or Kitterman's SPF Record Testing Tools. These parse the record the way a real mail server does, not just a generic DNS lookup.
3. Read the DNS lookup count, not just pass or fail. A record can show "valid syntax" and still be one include away from a PermError. Look for the explicit lookup count and treat anything above 8 as a warning, since adding one more provider later will push you over.
4. Check alignment with your actual sending sources. Cross-reference every include: against the tools you actually send from (your ESP, your helpdesk, your CRM). Includes for tools you stopped using years ago are silent lookup budget waste and a spoofing surface.
5. Re-check after every DNS change. DNS propagation can take minutes to 48 hours depending on your TTL. Re-run the checker after a change to confirm the new record is what is actually being served, not just what you saved in your DNS provider's dashboard.

Reading the results: pass, fail, and the errors between

Fixing the two errors that break the most domains

Too many DNS lookups

This is the most common way a previously working SPF record breaks: someone adds one more include: for a new tool and quietly pushes the domain over 10 lookups. The fix is not to add more includes to compensate, it is to reduce them.

Start by removing includes for services you no longer use, since dead includes cost lookups for nothing. Then check whether any include can be replaced with static IP ranges (ip4:/ip6:), which cost zero lookups once flattened, though you take on the maintenance job of updating them if the provider's IPs change. If you are still over the limit after trimming, moving some sending sources to a subdomain with its own SPF record is the standard workaround, since each subdomain gets its own 10-lookup budget.

Multiple SPF records

If dig TXT yourdomain.com shows two lines starting with v=spf1, merge them into one. Take every mechanism from both records (skip duplicates like a or mx appearing twice), combine them under a single v=spf1, and end with exactly one all qualifier. For example, two records like:

v=spf1 a mx include:_spf.google.com ~all
v=spf1 include:mailgun.org ~all

become one merged record:

v=spf1 a mx include:_spf.google.com include:mailgun.org ~all

Delete the old records from your DNS provider, publish the merged one, then re-run your checker to confirm only one record resolves.

SPF, DKIM, and DMARC: why checking SPF alone is not enough

SPF checks where an email came from, by verifying the sending server against the domain in the invisible Return-Path (the "envelope from"), not the From address a recipient actually sees. That is SPF's known limitation: an attacker can pass SPF by sending from a domain they control while spoofing your display name, and most recipients never notice the mismatch.

DKIM signs the message with a cryptographic key so the receiving server can confirm the content was not altered in transit. DMARC is the policy layer that ties both together: it requires SPF or DKIM to pass and align with the visible From domain, and it tells receiving servers what to do (none, quarantine, or reject) when that alignment fails. Checking SPF in isolation tells you one-third of the story. If you have not set up DKIM and DMARC yet, SPF, DKIM, and DMARC explained walks through all three together so you are not authenticating your domain piecemeal.

A minimal but complete authentication set looks like this:

SPF (TXT on yourdomain.com):
v=spf1 include:amazonses.com -all

DKIM (TXT on selector._domainkey.yourdomain.com):
provided by your sending platform, published as-is

DMARC (TXT on _dmarc.yourdomain.com):
v=DMARC1; p=quarantine; rua=mailto:[email protected]

What good SPF hygiene looks like ongoing

Checking once at setup is not enough, because SPF breaks silently when a marketing tool, helpdesk, or CRM gets added later without anyone updating DNS. Treat SPF the way you treat any shared config file: review it whenever a new sending tool is connected, and again on a quarterly cadence even if nothing changed on purpose, since a vendor can alter their required include without telling you. Pair the review with a periodic domain reputation check, since a broken SPF record and a declining sender reputation tend to surface around the same time.

This is also where deliverability and engineering responsibilities blur for most small teams: whoever owns DNS access is rarely the person adding a new email tool, so the SPF record drifts out of sync with reality. If your SaaS routes lifecycle and broadcast email through a platform like Meisa, sender identities and DKIM/SPF domain verification live in the same place your sequences and campaigns do, so the person managing email does not need a separate DNS ticket every time a sending source changes. A clean SPF record also protects the sender reputation you spend months building, since a PermError can tank deliverability faster than almost any content issue. For the fuller picture of how SPF fits into inbox placement overall, see the email deliverability guide.

FAQ

What does an SPF record checker actually check for?

It confirms three things: that a valid v=spf1 TXT record exists, that it is the only SPF record on the domain, and that it stays within the RFC 7208 limit of 10 DNS lookups. Good checkers also show which mechanism (include, a, mx) is consuming your lookup budget.

Why does my SPF record show "too many DNS lookups"?

Each include, a, mx, ptr, and exists mechanism costs one DNS lookup, and includes can nest further lookups inside them. RFC 7208 caps the total at 10. Adding one more sending tool without removing an unused include is the most common way domains cross that limit.

Can I have two SPF records for redundancy?

No. RFC 7208 requires exactly one SPF record per domain. Two records starting with v=spf1 cause a PermError because the receiving server cannot determine which one to evaluate, and that failure applies to the whole domain, not just the newer record.

Is SPF enough on its own, or do I need DKIM and DMARC too?

SPF alone is not enough. It authenticates the invisible Return-Path domain, not the From address recipients see, so it does not stop display-name spoofing by itself. DKIM verifies message integrity with a signature, and DMARC enforces alignment between them and tells receivers what to do on failure. All three together are what mailbox providers expect from a legitimate sender.

How long does it take for an SPF change to take effect?

DNS propagation typically ranges from a few minutes up to 48 hours, depending on the TTL set on the record. After making a change, wait for propagation and then re-run your checker to confirm the live record matches what you published, rather than assuming the dashboard save was the final step.

Should I use ~all or -all at the end of my SPF record?

~all (SoftFail) is a reasonable transition setting while you confirm every legitimate sender is included, since it tells receivers to accept but flag unmatched mail rather than reject it outright. Once you have verified your include list is complete, move to -all (Fail), which is the stricter, correct end state for a domain sending real production email.

Once your SPF record passes cleanly, the more useful habit is checking it again every time you connect a new sending tool, not just when a delivery problem forces you to look.