{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Resolver{{ resolverLabel }} SPF records{{ resultsReady ? computation.values.record_count : '—' }} Lookup terms{{ resultsReady ? `${computation.values.expanded_lookup_terms}/10` : '—' }}
Enter one public domain, such as google.com. The lookup runs only when you select Validate SPF.

{{ runStatus }}

Change provider to compare public cache views. The selected resolver can observe the queried domain names.
Use 1 to 15 levels. The neutral default is 8.
levels
Use 5 to 80 domains. The neutral default is 30.
domains
Validation report

Point-in-time public DNS evidence; not a sender-IP authorization result.

{{ overallStatusLabel }}
{{ row.label }}{{ row.value }}
{{ section.title }}

{{ section.body }}

Check evidence
{{ evidenceSummary }}
{{ overallStatusLabel }}
  • {{ row.label }}{{ row.observed }}{{ row.statusLabel }}
QualifierTypeTermValueLookup termsCopy
{{ row.qualifier }}{{ row.kind }}{{ row.name }}{{ row.value || '—' }}{{ row.lookupTerms }}
StepDepthViaDomainTermsCumulativeStateCopy
{{ row.step }}{{ row.depth }}{{ row.via }}{{ row.domain }}{{ row.lookupTerms }}{{ row.cumulative }}{{ row.stateLabel }}

The chart renderer is unavailable. The same cumulative term counts remain available in the expansion trace and CSV handoff.

DKIM Validation Report Check a DKIM selector in public DNS and review its record count, key strength and policy tags with clear testing and resolver evidence.
DMARC Validation Report Validate a domain's DMARC policy and check syntax, alignment and external report receivers before making stricter mail enforcement changes.
MX Record Lookup Inspect a domain's MX route and compare public DNS answers while catching Null MX conflicts, unresolved exchanges, and alias targets.
DKIM DNS Record Generator Build a DKIM TXT record from a selector and public key with validation and DNS string splitting, plus rollout checks before publishing.

Sender Policy Framework (SPF) publishes which systems may send mail for a domain. A receiving mail server evaluates the connecting IP address against the SPF policy associated with the envelope sender or HELO identity. The result can support later anti-spoofing decisions, but it does not authenticate message content or guarantee inbox delivery.

An SPF policy is stored in a DNS TXT record beginning with v=spf1. Terms are processed from left to right. Mechanisms such as ip4, ip6, a, mx, and include describe possible matches; a qualifier sets the result returned when a mechanism matches.

+ Pass
The matching source is authorized. A missing qualifier means +.
- Fail
The matching source is not authorized.
~ Softfail
The source is probably not authorized, commonly used during a cautious rollout.
? Neutral
The domain makes no positive or negative assertion for that match.

DNS work is a practical limit. The SPF specification allows no more than 10 evaluation terms that trigger DNS queries across the complete recursive evaluation. Long include chains can therefore turn a policy that looks short at the domain apex into a permanent error. Providers can also change their included policies without changing the root record.

A publication audit cannot decide whether a particular message would pass SPF because it has no SMTP client IP, envelope sender, HELO identity, or macro values. It also cannot establish Domain-based Message Authentication, Reporting, and Conformance (DMARC) alignment. Its value is narrower: find publication mistakes and expose likely lookup pressure before a live receiver reaches them.

How to Use This Tool:

Run an explicit public-DNS observation for one domain, then inspect the first incomplete or risky dependency.

  1. Enter the public domain that owns the SPF record and select Validate SPF.
  2. Choose Cloudflare DNS or Google Public DNS when you need a second public cache view. The selected resolver can observe the root domain and dependency names queried during the trace.
  3. Keep Trace depth at 8 and Trace nodes at 30 for an ordinary first pass. Raise the bounds only to investigate a known deep policy; depth accepts 1 to 15 and nodes accept 5 to 80.
  4. Read the SPF validation report before the lookup chart. Duplicate records, a DNS error, or an incomplete trace can make the displayed term total unsafe to treat as complete.
  5. Use the Expansion trace to locate the include or redirect that stopped, then rerun after correcting DNS or deliberately changing the trace bounds.

Interpreting Results:

Attention means at least one of the eight publication checks found a condition that can invalidate or seriously undermine the audit, such as multiple SPF records, more than 10 traced lookup terms, or a blocked dependency trace. Review means no attention item exists but at least one policy choice or incomplete observation needs judgment. Healthy means all eight checks passed this bounded publication profile.

The term total is a potential count from the observed policy graph, not the number of DNS packets a receiver will send for every message. A count below 10 still does not prove that per-mechanism address-query or void-lookup limits are safe. A count at exactly 10 stays within the RFC ceiling but receives Review because no operating headroom remains.

Technical Details:

SPF evaluation distinguishes mechanisms from modifiers. The DNS-triggering terms counted here are include, a, mx, ptr, exists, and redirect. Terms such as all, ip4, ip6, and exp do not consume that 10-term limit during ordinary evaluation.

Lookup Core

The root TXT answer set is filtered for records whose first token is v=spf1, case-insensitively. Exactly one such record is required. The dependency walk follows only explicit include mechanisms and redirect modifiers, caches repeated names during the run, and records each observed policy up to the selected depth and node caps.

At every traced node, each of the six DNS-triggering term types contributes one to the cumulative total. Macro-bearing or unsupported dependency targets are recorded but not expanded. Cycles, DNS errors, depth caps, and node caps stop the affected path. The result is therefore a bounded static expansion, not a full check_host evaluation.

Trace stateMeaningReport effect
CompleteAn SPF record was read and its supported dependencies stayed inside the selected bounds.No trace-coverage finding by itself.
No record or macroA dependency has no SPF record, or its target needs values unavailable to a static audit.Review because the count may be incomplete.
DNS error, cycle, depth, or node capThe walk could not complete that path.Attention because the displayed count must not be treated as complete.

Rule Core

CheckHealthyReview or Attention
DNS responseThe selected resolver returns NOERROR.Any other response is Attention.
Record countExactly one SPF v1 record exists.Zero or multiple records is Attention.
Version markerThe selected policy begins with v=spf1.A missing selectable policy is Attention.
Lookup budgetFewer than 10 traced terms.Exactly 10 is Review; more than 10 is Attention.
Terminal policyThe last observed all qualifier is - or ~.+all, ?all, or no all is Review.
all placementOne all is the final mechanism.No all is Review; duplicates or a later mechanism is Attention.
ptrThe root policy does not use the discouraged mechanism.Presence is Review.
Trace coverageNo incomplete or blocking trace state exists.No record or macro is Review; a blocking state is Attention.

The overall label follows severity, not an average: any Attention check makes the whole report Attention; otherwise any Review check makes it Review; only eight Healthy checks produce Healthy. This ordered rule is more faithful than a percentage formula, so no Formula Core is used.

The audit deliberately omits macro expansion, sender-IP matching, the recommended two-void-lookup limit, and the separate address-query limits applied within mx and ptr processing. Receivers may also impose elapsed-time limits or local policy beyond the RFC rules.

Privacy and Accuracy Notes:

DNS queries go directly to the selected public resolver, which can observe the root domain and every include or redirect name reached by the bounded trace. Answers represent one resolver's cache at one moment and may differ during propagation. No email address, message content, SMTP client IP, or mail-server credential is sent.

Worked Examples:

Ten terms with a complete trace

A single valid policy graph with 10 counted terms receives Review for lookup budget, even when every dependency resolves. The RFC limit has not been exceeded, but one added include, a, mx, ptr, exists, or redirect term would push the evaluation over the ceiling.

A low count stopped by the depth cap

A displayed total of 6 is not reassuring if the expansion trace ends at the selected depth. Trace coverage becomes Attention because unvisited policies may add more terms. Raising the bound can complete the audit, but a needlessly deep chain is also a reason to simplify the policy.

References: