SPF Record Checker

Validate Sender Policy Framework (SPF) records published in DNS TXT for a domain. The tool fetches v=spf1 records, lists mechanisms (include, ip4, ip6, a, mx, etc.), checks the required terminal all qualifier, and flags common misconfigurations: missing SPF, multiple SPF records, permissive +all, softfail ~all without DMARC, and excessive include chains approaching the 10-DNS-lookup limit. DNS-over-HTTPS via Google resolver. Helps email admins before migrations — does not send test mail or validate DKIM/DMARC (use the dedicated checkers for those).

How to Use the SPF Record Checker

Enter a domain to fetch its SPF TXT record, review mechanisms and the all qualifier, and read flagged configuration issues.

  1. Open SPF Record Checker.
  2. Enter the domain that sends email (usually your apex domain).
  3. Click Run check to query TXT records for v=spf1.
  4. Read Found, Version, and All qualifier summary tiles.
  5. Review the raw SPF string and mechanism chips (include:, ip4:, mx, etc.).
  6. Read the issues list — errors (red) vs warnings (amber) for misconfigurations.
  7. Fix DNS at your provider and re-check; pair with DMARC Record Checker for full email auth.

How SPF validation works

The tool performs a TXT lookup, filters records starting with v=spf1, parses space-separated mechanisms, and applies RFC-informed rules: single record, terminal all present, +all flagged insecure, high include count noted.

Worked example

  • Google Workspace — expect include:_spf.google.com and -all or ~all during testing.
  • Multiple v=spf1 TXT rows — merge into one record to fix permerror risk.
  • +all at the end — replace with -all after listing every authorized sender.

Common mistakes

  • Publishing SPF on a subdomain but not the From: domain receivers evaluate.
  • Forgetting to update SPF after adding a new marketing mail SaaS include.
  • Using ptr mechanism (deprecated and lookup-expensive) — prefer explicit ip4/include.

Limitations

DNS snapshot only — does not simulate receiver SPF evaluation against a specific message. Does not check DKIM selectors or DMARC alignment — use the dedicated DKIM and DMARC tools on this site.

FAQ

Where is SPF published?

SPF lives in a TXT record at the domain apex (example.com) starting with v=spf1. Some providers use a subdomain, but inbound mail auth typically checks the From domain's SPF.

What does the all qualifier mean?

-all fails unauthorized senders (strict), ~all softfails (lenient), +all allows everyone (insecure), ?all is neutral. Every valid SPF record must end with an all mechanism.

Why is multiple SPF records an error?

RFC 7208 permits only one SPF TXT record per domain. Multiple v=spf1 strings cause permerror and unpredictable receiver behavior — merge into one record.

What is the 10-DNS-lookup limit?

SPF evaluation may perform at most 10 DNS lookups (includes, a, mx, ptr, exists). Deep include chains cause permerror — flatten includes where possible.

Does SPF alone stop spoofing?

No. SPF validates envelope sender paths. DMARC aligns From: header with SPF/DKIM for receiver policy — deploy all three for robust protection.

Why does ~all show a warning?

~all (softfail) marks suspicious mail but may still deliver it. With DMARC p=reject, many operators prefer -all for authorized senders only.

Can this checker send a test email?

No. It performs DNS TXT lookup and static syntax/mechanism analysis only.

What if no SPF record is found?

Receivers may treat mail as neutral or suspicious. Publish v=spf1 with authorized includes/ips and -all (or ~all during testing with DMARC monitoring).

Does it validate ip6 and ip4 mechanisms?

It lists mechanisms and flags structural issues. It does not verify that every listed IP is still owned by your mail provider — review includes against provider docs.

Which resolver fetches TXT records?

SPF checks query TXT via Google DNS-over-HTTPS, same family of resolver used by other email DNS tools on ToolsLibrary.