SPF Checker & Validator
Validate and analyze SPF (Sender Policy Framework) records for any domain. Check SPF syntax, detect configuration issues, visualize DNS lookup chains, identify deprecated mechanisms, and ensure email authentication compliance with comprehensive validation reports.
SPF Record Check
What is SPF?
SPF (Sender Policy Framework) is an email authentication method that defines which mail servers are authorized to send email on behalf of your domain.
SPF records are published in DNS as TXT records and contain mechanisms that specify allowed senders (IP addresses, domains, includes).
SPF helps prevent email spoofing by allowing receiving mail servers to verify that incoming email from a domain comes from an authorized server.
Popular Domains
SPF Best Practices
Keep DNS Lookups Under 10
SPF limits DNS lookups to 10. Each include, mx, a, exists, and ptr mechanism counts as a lookup. Exceeding this limit causes validation to fail with permerror.
Always End with -all or ~all
Use -all (hard fail) to reject unauthorized senders, or ~all (soft fail) to mark them as suspicious. Never use +all as it allows anyone to send email.
Avoid PTR Mechanism
PTR mechanism is deprecated and unreliable. Use ip4/ip6 mechanisms instead to specify authorized sender IPs directly.
Flatten Include Chains
When possible, replace includes with direct ip4/ip6 mechanisms to reduce DNS lookup count. This improves SPF validation performance and reliability.
Qualifier Reference
Explicitly allow email from this source. This is the default if no qualifier is specified.
Reject email from this source. Commonly used with -all to reject all unauthorized senders.
Accept email but mark as suspicious. Commonly used with ~all as a transitional policy.
No explicit policy. Equivalent to no SPF record. Rarely used in production.
About SPF Checker & Validator
The SPF Checker & Validator is a comprehensive email authentication analysis tool that fetches and validates SPF (Sender Policy Framework) records for any domain. It parses the raw SPF TXT record, walks every `include`, `a`, `mx`, and `exists` reference, counts the total DNS lookups against the spec's 10-lookup limit, validates each mechanism's syntax and qualifier, flags deprecated patterns (`+all`, `ptr`), and explains every directive in plain English. Pairs naturally with the MX Lookup, SMTP Test, and Trace Email tools for an end-to-end deliverability audit.
Why use a SPF Checker & Validator?
SPF is the foundation layer of email authentication and the most common cause of legitimate mail being rejected as spoofed. Three things break SPF in production: exceeding the 10-DNS-lookup limit (silent failure), using `+all` or no terminator (lets anyone spoof the domain), and forgetting to update the record after a SaaS migration (your new sender becomes unauthenticated). This tool catches all three before they cost you. Hand-counting includes for the 10-lookup limit is tedious and error-prone — running an automated check is the only reliable way.
Who is it for?
Built for DevOps and email administrators auditing newly configured domains, marketing-ops teams adding ESP includes (Klaviyo, SendGrid, Mailchimp), security professionals verifying SPF as part of DMARC implementation, IT teams inheriting unfamiliar email infrastructure, and developers debugging why their transactional email is bouncing. Anyone who has ever shipped a marketing migration only to have campaigns silently fail SPF should bookmark this.
How to use the tool
Enter the domain you want to check (e.g., example.com — no protocol or path needed)
Click 'Check SPF' to fetch the live TXT record and walk the include chain
Read the headline result: PASS / WARNING / FAIL with the reason
Review the parsed mechanism list — each directive is colour-coded by qualifier (+ pass, - fail, ~ softfail, ? neutral)
Watch the DNS-lookup counter: green (0-8) safe, yellow (9-10) at limit, red (11+) the record will permerror
Inspect the include chain visualization to see nested SPF lookups across providers
Fix any flagged issues — most commonly the +all qualifier, deprecated ptr, or include-bloat
Copy the validated record or export the full report as JSON / TXT for documentation
Key Features
Live DNS lookup with full include resolution
Fetches the TXT record from a real recursive resolver and follows every nested include. The number reported matches what receiving mail servers will count against your domain.
10-lookup limit warning with break-down
RFC 7208 caps total DNS lookups at 10; anything past that returns permerror, and your authenticated mail starts failing. The tool counts lookups per mechanism and flags which include is pushing you over.
Per-mechanism qualifier explanation
+all (allow), -all (fail), ~all (softfail), ?all (neutral) — each one's security implications spelled out so non-experts know what their record actually does.
Deprecated-mechanism detection
Flags `ptr` (deprecated since RFC 7208), unsafe `+all`, and obsolete macros so you can clean up before they cause problems.
Multiple-record detection
RFC 7208 allows only one SPF record per domain; multiple records cause permerror. The tool catches this — a surprisingly common error after migration.
Include chain visualization
Tree view of all include references so you can see exactly which third-party senders (SendGrid, Mailgun, Google Workspace, etc.) you've authorized.
Export validated record + report
Copy the raw record to clipboard, or export the full validation report as JSON or TXT to attach to runbooks, change tickets, or post-mortems.
Common Use Cases
Pre-migration validation when adding a new ESP
Scenario: You're moving transactional mail from your own SMTP to SendGrid (or Postmark, Mailgun, etc.). You added the include but want to verify it's correct before flipping production traffic.
✓ Run the check, confirm the new include is parsed, see your DNS-lookup count is still under 10. Catches the case where adding the new include pushed you over the limit and would silently break ALL mail.
Auditing domains after acquisition or team handoff
Scenario: You inherited a domain with no documentation and need to know what mail providers it's authenticated to send through.
✓ The include chain shows every authorized sender. Red flags (e.g., ancient SendGrid include for an account that's no longer paid) jump out for cleanup.
Debugging 'why is my mail going to spam?'
Scenario: Your transactional mail started landing in Gmail spam folders. SPF is the first thing to check.
✓ If the record is missing, malformed, or permerror'ing from too many lookups, you'll see it instantly. Fix and recheck in seconds.
Pre-DMARC implementation audit
Scenario: You're about to enable DMARC enforcement (p=quarantine or p=reject) and need every legitimate sender authenticated first.
✓ Walk the include chain, identify any senders that aren't covered, add them to SPF before you flip DMARC. Avoids the classic mistake of nuking your own marketing campaigns the day you turn on DMARC.
Security audit / compliance check
Scenario: Compliance review needs evidence that your email-sending domain has SPF properly configured.
✓ Generate a JSON report showing the validated record, mechanism breakdown, lookup count, and pass/fail status — attach to the audit artifact.
Validation follows RFC 7208 exactly: matches what receiving mail servers (Gmail, Outlook, etc.) will compute when they evaluate your record.
The DNS lookup runs server-side through our edge proxy. Domain is queried but not stored. No cookies, no analytics on input content.
Globally distributed edge infrastructure for low-latency queries.
Frequently Asked Questions
What does the 10-DNS-lookup limit mean?
RFC 7208 caps the total number of DNS lookups an SPF check can perform at 10. Each `include`, `a`, `mx`, `exists`, and `ptr` mechanism counts. If a check exceeds 10 lookups, the receiving server returns 'permerror' and the SPF check fails — meaning all your authenticated mail starts looking unauthenticated. This is the #1 silent SPF failure in production. The tool tracks lookups across nested includes.
Why is +all dangerous?
The qualifier `+` means 'allow' — so `+all` means 'allow ANY server to send mail as this domain.' That's a wide-open spoofing invitation. Always use `-all` (hard fail) or `~all` (softfail) as the final mechanism. The tool flags `+all` as a critical error.
What's the difference between -all and ~all?
`-all` (hard fail) tells receivers to reject mail from unauthenticated senders. `~all` (softfail) tells them to accept but mark as suspicious. Modern best practice with DMARC enforcement is `-all`, but if you're not 100% sure all your senders are in the SPF, `~all` gives you a safer rollout window. Don't ship `+all` or `?all` — they're effectively no policy.
Why are multiple SPF records bad?
RFC 7208 explicitly says a domain can have only ONE SPF record. If receivers see two `v=spf1 ...` TXT records on the same name, they return permerror — and all your mail starts failing. This commonly happens after a migration when someone adds a new record instead of merging the existing one. The tool detects multiple records and flags it.
Why is ptr deprecated?
The `ptr` mechanism does a reverse DNS lookup on the sender IP — it's slow, unreliable, and creates infinite-recursion attack vectors. RFC 7208 explicitly deprecates it. Replace with `a`, `mx`, or `ip4`/`ip6` mechanisms. The tool flags `ptr` usage.
How do I add an ESP include without exceeding the 10-lookup limit?
Each ESP include typically counts 1-3 lookups. The fix when you're at the limit: (1) drop unused includes (old SendGrid account that's deactivated), (2) replace `a:server.example.com` with `ip4:1.2.3.4` (saves a lookup), (3) for very large ESPs, ask their support for the consolidated SPF — most have one. As a last resort, use 'SPF flattening' tools that resolve includes to IPs (with caveats around IP changes).
Does this tool send my domain anywhere?
The DNS lookup runs server-side through our edge proxy, which queries the public DNS resolvers. Your domain appears in the proxy's request log briefly but is not stored or analyzed beyond returning the result.
How does SPF interact with DMARC?
DMARC requires SPF (or DKIM) to align with the From: header domain. So SPF must be correctly configured AND aligned for DMARC enforcement to pass. If you're enabling DMARC (p=quarantine or p=reject), validate SPF first with this tool, then validate DKIM separately, then enable DMARC reporting (p=none) before tightening the policy.
Technical Specifications
Supported Formats
- ✓RFC 7208 SPF v1
- ✓All mechanisms: all, ip4, ip6, a, mx, ptr (deprecated), exists, include
- ✓All qualifiers: + (pass), - (fail), ~ (softfail), ? (neutral)
- ✓Modifiers: redirect=, exp=
- ✓Macros: %{s}, %{l}, %{o}, %{d}, %{i}, %{p}, %{v}, %{h}
- ✓DNS-lookup limit enforcement (10 max per RFC)
- ✓Multiple-record detection
- ✓Deprecated-mechanism flagging (ptr)
Limits & Performance
- •File Size: Single domain per check
- •Validations: Live syntax + DNS resolution
- •Response Time: Typically 200-1500ms depending on include chain depth
- •Browsers: All modern browsers (Chrome, Firefox, Safari, Edge)
Pro Tips
- Always end with `-all` or `~all` (never `+all` or `?all`). `-all` is the goal; `~all` is a transitional setting while you confirm all legitimate senders are covered.
- Aim for 8 or fewer DNS lookups, not 10. The buffer protects you when an ESP changes their includes (which they do).
- After any SPF change, wait for TTL to expire (or temporarily lower TTL before changing) before re-checking. DNS propagation can show stale results otherwise.
- SaaS providers list their `include:` mechanism in their docs. Examples: `include:_spf.google.com` (Google Workspace), `include:sendgrid.net` (SendGrid), `include:mailgun.org` (Mailgun). Always use the documented include rather than hardcoding IPs.
- If your domain doesn't send email at all, publish `v=spf1 -all` to explicitly say 'no one can send mail as this domain' — it's more secure than no SPF.
- Subdomains do NOT inherit the parent domain's SPF. Each subdomain that sends mail needs its own SPF record (or you need to make sure mail isn't sent from those subdomains).
- When debugging deliverability, check SPF first, DKIM second, DMARC third — that's the order receivers evaluate them and the order errors compound.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.