Sender Policy Framework (SPF) Checker and Validator

Introduction:

Sender Policy Framework records state which servers may send mail for a domain and help receivers decide whether to accept a message. Checking this record clarifies who is authorized and highlights configuration risks that can weaken delivery.

Enter one domain and run a quick lookup so you see the published text and a readable breakdown of its parts. A Sender Policy Framework record checker for domains helps you spot issues early and understand the effect of each mechanism on delivery.

Results summarize the record, the time to answer, and the number of lookups it can trigger, followed by a pass or fail view of common pitfalls. You can reuse the parsed parts for audits and change tracking when planning updates with your team.

For a simple example, a domain that ends with a strict rule signals that only listed sources are allowed, while permissive endings may invite unwanted mail. Consistent entries and clear endings tend to reduce surprises for receivers.

Treat results as configuration feedback rather than proof of sender identity. Combine this check with other mail controls for a fuller picture.

Technical Details:

This tool inspects Sender Policy Framework (SPF) data published as Domain Name System (DNS) TXT records for a single domain. It retrieves answers through DNS over HTTPS (DoH), then selects the primary SPF line and parses it into qualifiers and mechanisms for interpretation.

The computation extracts the SPF string that starts with v=spf1, picks the longest such line when multiple are present, and splits it into tokens. From these tokens it estimates the DNS lookup count by tallying mechanisms that can induce lookups and evaluates a checklist of safety and hygiene rules.

Interpretation emphasizes three outcomes: whether a valid SPF line is present, whether the policy terminates cleanly, and whether the estimated lookup count stays within common operational limits. Borderline cases near limits should be reviewed before adding new includes or hosts.

Comparisons are meaningful when the domain and record text are unchanged and the same parsing and lookup rules are applied. Network timing varies with resolver conditions and should not be used as a reliability metric.

Processing Pipeline:

1. Build a DNS-over-HTTPS URL for the queried domain.
2. Request TXT answers with an Accept: application/dns-json header.
3. Collect lines that begin with v=spf1; choose the longest line.
4. Split the line into space‑separated tokens after v=spf1.
5. For each token, capture optional qualifier (+, -, ~, ?), mechanism, and value.
6. Estimate lookup count by counting mechanisms in {include, a, mx, ptr, exists, redirect}.
7. Evaluate checks: presence, header, single record, terminator, order, qualifiers, duplicates, deprecated use, lookup limit, permissive ending, and length.

Symbols & Units:

Worked Example:

Interpretation & Thresholds:

Validation & Bounds (from code):

I/O Formats & Encoding:

Networking & Storage Behavior:

• Performs a GET request to a DNS-over-HTTPS resolver endpoint with application/dns-json.
• No server-side storage by this site; downloads and copies are created in the browser.
• TTL is taken from the first DNS answer; timing is measured client‑side.

Performance & Determinism:

• Parsing is linear in token count.
• Given the same record text, tokenization and checks are deterministic.
• Network time varies with resolver load and proximity.

Security Considerations:

• Do not rely on a passing checklist as proof of sender legitimacy.
• HTML rendering of prettified JSON is injected intentionally; trust only known-safe highlighters.
• Avoid sharing sensitive internal hostnames in public forums when copying results.

Assumptions & Limitations:

• Only the longest v=spf1 line is parsed when multiple lines exist.
• Lookup count is estimated from mechanisms in the current line; includes are not expanded.
• Macro evaluation is not performed.
• Internationalized domains are not converted; use ASCII labels.
• Record length check applies to a single TXT string.
• Order check requires the ending mechanism to be last.
• Deprecated ptr usage is flagged.
• Heads‑up Timing reflects client conditions and resolver behavior.

Edge Cases & Error Sources:

• Trailing dots are stripped; leading/trailing spaces invalidate input.
• Multiple SPF lines may indicate misconfiguration; only one is treated as valid.
• Multi‑string TXT records are not concatenated into one logical line.
• Unknown mechanisms are parsed but not specially validated.
• Permissive endings like +all are flagged.
• Very long lines over 255 characters fail the length check.
• Transient network errors yield a lookup failure message.
• Resolver differences can change TTLs and timing.
• Large token counts increase parsing time slightly.
• Copy and download depend on clipboard and file APIs being available.

Privacy & Compliance:

Requests are sent from the browser to a public DNS over HTTPS resolver; the site does not retain inputs or outputs on a server. Use results responsibly and avoid exposing sensitive internal hostnames.

How‑to · Step‑by‑Step Guide:

Sender Policy Framework inspection produces a parsed record, an estimated lookup count, and a checklist summary.

1. Enter the domain you want to inspect.
2. Select validate to query DNS and collect TXT answers.
3. Review the record text and the list of parsed tokens.
4. Check the lookup estimate and the pass or fail items.
5. Copy the record or export summaries for change reviews.

• Prefer strict endings after testing legitimate senders.
• Keep includes lean and documented.

You now have a concise view to decide whether to adjust sources or qualifiers.

FAQ:

Troubleshooting:

• “Domain is required” — enter a domain and try again.
• “No SPF record found” — publish or correct the TXT record.
• “Lookup failed” — retry later or switch networks.
• Multiple SPF lines — consolidate to a single authoritative line.
• Excess lookups — remove unused includes or switch to CIDR ranges.
• Permissive ending — replace +all with ~all or -all after testing.
• Long record — shorten mechanisms or move data to includes.

Glossary:

Sender Policy Framework (SPF)

A policy that lists permitted mail sources for a domain.

Mechanism

A token in SPF that matches senders, such as a or mx.

Qualifier

A prefix that sets pass or fail behavior for a mechanism.

Time To Live (TTL)

How long a DNS record may be cached by resolvers.

DNS over HTTPS (DoH)

A way to query DNS using HTTPS transport.

Terminator

The ending policy such as ~all or -all that sets the default.