Current SPF target
{{ summaryPrimary }}
{{ summarySecondaryLine }}
{{ summaryBadge }} {{ lookupBudgetBadge }} {{ terminalPolicyBadge }} {{ traceBadge }}
DOM TXT INC all 10
Enter one domain such as example.com; pasted http(s) URLs are reduced to the hostname.
Choose Cloudflare DNS or Google Public DNS for the TXT lookup and expansion trace.
Use 1 to 15 levels; start with 8 unless a policy is unusually nested.
levels
Use 5 to 80 domains; higher values reveal more trace rows but cost more DNS lookups.
domains
Qualifier Term Value Lookup cost Copy
{{ row.qualifier }} {{ row.term }} {{ row.value }} {{ row.lookupCost }}
Check Status Notes Copy
{{ row.label }} {{ row.status }} {{ row.note }}
Depth Via Domain Lookups Notes Copy
{{ row.depth }} {{ row.via }} {{ row.domain }} {{ row.totalLookups }} {{ row.note }}

            
Customize
Advanced
:

Introduction:

Sender Policy Framework, or SPF, is the DNS policy that names which mail sources are allowed to send for a domain. Receiving mail systems use that policy during authentication, and a crowded or contradictory SPF record can turn a routine sender change into delivery failures.

The most common SPF problems are structural. A domain may publish no SPF record, publish more than one record, point to too many nested include or redirect policies, or finish with a weak terminal policy. Those issues are easy to miss when the record is one long TXT value copied between DNS panels.

The report keeps the DNS route visible while you work. The topology surface, directive table, expansion trace, lookup-budget chart, JSON view, and export buttons all describe the same lookup so the policy can be reviewed without switching between separate diagnostics.

Domain example.com TXT record v=spf1 terms Lookup budget include redirect Notes healthy review One record, lookup count at or below 10, and safe ending policy

SPF validation should be read as policy inspection, not as proof that a specific message will pass. Real message authentication also depends on the sending IP, envelope identity, forwarding path, and DMARC alignment. A record can be tidy and still fail for a message sent from an unauthorized server.

The useful first question is whether the published SPF policy is coherent enough to reason about before another mail provider, include, or redirect is added.

How to Use This Tool:

Start with the domain apex, then compare the directive breakdown, validation notes, and expansion trace.

  1. Enter one domain in Domain, such as example.com. A pasted web address is reduced to its hostname, but a clean domain is easier to verify.
  2. Choose Validate SPF after editing the domain or resolver. If the alert says Enter a valid domain such as example.com., correct the field before trying another lookup.
  3. Open Advanced only when you need to compare resolvers or cap a large trace. Resolver can use Cloudflare DNS, Google Public DNS, or Quad9, Expansion depth accepts 1 to 15 levels, and Expansion nodes accepts 5 to 80 domains.
  4. Read the summary badges. They show the domain, the lookup budget count, the detected terminal policy, and the number of trace rows returned.
  5. Use Directive Breakdown to inspect qualifier, term, value, and lookup cost for each SPF term in the selected record.
  6. Use Validation Notes to repair structural issues first, especially missing records, duplicate records, lookup budget overrun, weak terminal policy, PTR use, or redirect review.
  7. Use Expansion Trace when the lookup budget is high or when include and redirect chains need to be explained in a ticket or DNS change note.
  8. Use Lookup Budget Map to compare the root policy and followed child policies against the SPF limit, then export the chart or CSV when the review needs an attachment.

Run the same domain again after DNS edits, preferably with the same resolver choice, so the lookup budget and terminal policy can be compared on the same basis.

Interpreting Results:

The validation label is a structural signal. SPF record is coherent means the visible checks are healthy. SPF has review notes means the record is usable enough to parse but has policy choices that deserve attention. SPF needs attention means at least one issue can break or seriously weaken SPF evaluation.

How to interpret SPF validation outcomes
Output cue Meaning What to check next
Record count Exactly one SPF record is the healthy publication shape. Remove duplicate v=spf1 TXT records before tuning mechanisms.
Lookup budget The expanded policy is counted against the SPF limit of 10 DNS-triggering terms. Flatten, remove, or consolidate includes when the count is near or above 10.
Terminal policy -all and ~all are treated as healthy endings; ?all, +all, or no all ask for review. Choose the ending that matches the domain's rollout stage and mail risk tolerance.
PTR mechanism ptr is detected in the policy. Replace PTR-based matching with explicit sources where possible.
Expansion Trace Include and redirect child domains were followed until limits, cycles, macros, or missing records stopped traversal. Treat skipped macro, cycle, or limit rows as reduced confidence in the budget estimate.
Lookup Budget Map Followed SPF records are plotted against the 10-lookup limit. Use the chart to see whether one child policy dominates the budget before flattening or removing includes.

A low lookup count does not rescue a duplicate SPF publication or an allow-all policy. Fix structural problems before treating the record as ready for another sender.

Technical Details:

SPF records are published as DNS TXT values beginning with v=spf1. The remaining terms are mechanisms and modifiers. Some terms match senders without more DNS work, such as ip4, ip6, and all. Others can trigger DNS queries during evaluation, and SPF limits those DNS-triggering terms to 10.

The validator fetches TXT answers for the entered domain through the selected public resolver, joins quoted TXT fragments, and uses the first answer that begins with v=spf1 as the record shown in the summary and directive table. The full number of SPF-looking records is still used in the record-count check.

Lookup Core:

The lookup budget is a count of DNS-triggering SPF terms. The root record and each followed include or redirect child contribute their own counted terms.

L = i=1 n c ( ti ) c (t) = 1 when t { include, a, mx, ptr, exists, redirect } ; otherwise 0
SPF term handling and lookup cost
Term Lookup cost Expansion behavior
include 1 Followed into a child SPF record when the value is a normal domain and trace limits allow it.
redirect 1 Followed as a child SPF record and also shown as a redirect review note.
a, mx, ptr, exists 1 Counted where they appear, but not expanded into address or MX lookup trees by this checker.
ip4, ip6, all 0 Parsed for policy meaning but not counted as DNS-triggering terms.

Expansion follows include and redirect references recursively. The trace stops when it reaches the depth limit, reaches the node limit, sees a cycle, encounters a missing SPF record, or finds a macro-style reference that cannot be followed safely as a plain domain. The root trace row carries the total counted lookups accumulated below it.

SPF validation notes and pass conditions
Check Healthy condition Why it matters
Record count Exactly one v=spf1 TXT record is found. Duplicate SPF publication can make evaluation fail with a permanent error.
Lookup budget The expanded count is 10 or lower. Receivers must stop with a permanent error when the SPF DNS lookup limit is exceeded.
Terminal policy The last all mechanism is -all or ~all. Missing, neutral, or pass-all endings reduce enforcement clarity.
PTR mechanism No ptr mechanism appears. PTR-based SPF matching is discouraged and can be slow or unreliable.
Redirect usage No redirect modifier appears. A redirect can be valid, but it must stay within the global lookup budget.

The directive table exposes qualifiers exactly as parsed: + pass, - fail, ~ softfail, and ? neutral. When a term has no qualifier, SPF treats it as + for that term, so the terminal all policy is especially important.

Limitations and Privacy Notes:

The result is a DNS policy review, not an end-to-end mail authentication test.

  • The lookup sends the queried domain to the selected public DNS-over-HTTPS resolver.
  • The expansion trace follows include and redirect only; a, mx, ptr, and exists increase the count but are not dereferenced into detailed DNS trees.
  • SPF macros are skipped in the trace, so affected branches need manual review.
  • The checker does not test a sender IP, SMTP session, HELO identity, forwarding path, DKIM, or DMARC alignment.

Worked Examples:

One hosted-mail include:

A record such as v=spf1 ip4:198.51.100.0/24 include:_spf.mail.example -all has one DNS-triggering term in the root record. If the included child contains a mx -all, the expansion trace adds two more counted terms. The root trace total becomes 3, and the lookup budget stays below 10.

Duplicate SPF records:

If the apex TXT set returns two values beginning with v=spf1, Record count becomes Needs attention. The directive table can still show one record for inspection, but the duplicate publication must be cleaned up before the policy can be treated as valid.

Trace limit reached:

A policy with many nested includes may show a trace note that the node or depth limit was reached. That does not prove the live policy is safe or unsafe. It means the displayed lookup count is bounded by the chosen trace limits, so the affected branches need a larger trace or manual review.

Weak terminal policy:

A record ending in ?all may have a low lookup count and no PTR mechanism, but Terminal policy still becomes review. Neutral endings can be intentional during rollout, yet they should not be mistaken for a strict SPF policy.

FAQ:

Does a coherent SPF record mean my mail will pass?

No. The result checks the published policy structure. A real message can still fail if the sending IP, envelope identity, forwarding path, or DMARC alignment does not match the domain's mail flow.

Why is the SPF lookup limit 10?

SPF counts terms that trigger DNS work during evaluation. The visible budget follows that limit so a policy near or above 10 can be repaired before receivers return a permanent error.

Why does the trace skip macro references?

Macro references depend on message-time values, so the checker does not turn them into a plain DNS name during a static domain review. Treat skipped macro rows as manual-review cues.

Should every redirect be removed?

No. A redirect can be a valid way to delegate an SPF policy. The review note is there because redirects count against the same global DNS lookup budget and can hide policy changes in another domain.

Why did a URL input become a domain?

The domain field normalizes pasted web addresses to their hostname. SPF is published for a DNS owner name, so paths, protocols, and page URLs are not part of the policy lookup.

Glossary:

SPF
Sender Policy Framework, a DNS-published policy that authorizes mail sources for a domain.
Mechanism
An SPF term such as include, ip4, mx, or all that contributes to policy evaluation.
Qualifier
The optional symbol before a mechanism that sets the result when that mechanism matches.
Redirect
An SPF modifier that sends evaluation to another domain's SPF policy.
Terminal policy
The final all mechanism, such as -all or ~all, that describes what happens after earlier terms do not match.
DNS-over-HTTPS
A DNS transport where DNS questions are sent over HTTPS to a resolver.