Free diagnostic
Inspect the SPF TXT record, terminal policy, duplicate-record risk, and direct DNS lookup mechanisms without storing the submitted domain.
A domain should publish one SPF record. This diagnostic exposes the record, its terminal all mechanism, and the mechanisms that directly trigger DNS lookups.
This free check is deliberately bounded. Use DMARC monitoring and domain monitoring to track recursive includes, record drift, DKIM, DMARC, MX, transport security, and provider evidence together.
Diagnostic bridge
Use the checker when the question is publication. Use monitoring when the question is whether real senders align, whether unknown sources remain, and whether enforcement can safely change.
Label sources, inspect SPF/DKIM alignment over time, and plan enforcement.
Understand RUA ingestion, source attribution, alerts, and rollout evidence.
See why raw SPF/DKIM passes can still fail DMARC alignment.
Fundamentals
SPF (Sender Policy Framework), defined by RFC 7208, lets a domain publish which servers may send email on its behalf. The policy lives in a single TXT record at the domain itself, starting with v=spf1. When a receiving server gets a connection from a sending IP, it fetches that record and walks the policy to decide whether the connecting IP is authorized. Because the answer is public DNS data, anyone can inspect it, which is exactly what this checker does. An SPF record is a list of terms, evaluated left to right. Mechanisms such as ip4, ip6, a, mx, include, and exists each describe a set of authorized senders; the first one that matches the connecting IP decides the result. Each mechanism can carry a qualifier: + for pass (the default when none is written), - for fail, ~ for softfail, and ? for neutral. Records normally end with an all mechanism that catches whatever the earlier terms did not match, so the qualifier on all is the policy's final word on unauthorized senders. One detail matters more than any other: SPF evaluates the envelope sender, the address in the SMTP MAIL FROM command that later appears as the Return-Path header, not the visible From address your recipients see. A message can pass SPF on its Return-Path domain while the visible From domain is something else entirely. DMARC closes that gap by requiring an authenticated domain to align with the From domain; see DMARC alignment explained.
Reading the output
This tool runs live DNS queries against the domain you submit and reports exactly what is published. It is anonymous, rate limited, and does not retain the submitted domain. No SMTP connection is opened and no mailbox is probed. Every result has a status, an evidence block, a limitations list, and a link to RFC 7208.
Troubleshooting
Most SPF problems come from a small set of patterns, several visible directly in this tool's output. The SPF cheat sheet covers mechanisms and limits in compact form.
Providers
SPF is one standard, but the large mailbox providers weigh it differently and publish their own sender requirements on top of it.
Comparison
All three can tell you something about an SPF record, but they are built around different jobs. MXToolbox offers free ad-supported one-off DNS lookups, with paid monitoring from $129 per month. dmarcian is a DMARC-focused suite built around deployment and reporting rather than standalone SPF checks. WillItInbox runs free SPF checks with no login and no retention of the submitted domain, with optional DMARC monitoring (see the monitoring documentation) when you need the recursive picture and drift detection.
| Capability | WillItInbox | MXToolbox | dmarcian |
|---|---|---|---|
| SPF lookup | Free, one-off, live DNS | Free, one-off, ad-supported | DMARC-suite oriented |
| Duplicate-record and terminal-policy readout | Yes, in free check | Yes, as separate detail | Within DMARC tooling |
| Login required | No for free checks | No for free lookups | Account-oriented platform |
| Submitted-domain retention | None for public checks | Varies by product | Varies by product |
| Monitoring beyond one-off checks | Optional DMARC/domain monitoring | Paid plans from $129/mo | DMARC reporting platform |
Live diagnostic
This anonymous tool is rate limited and does not retain submitted input. It reports observable evidence without promising delivery, authentication alignment, or inbox placement.
No SMTP mailbox probing, account lookup, or tenant data is used.
Related
Review mechanisms and limits.
Inspect policy and reporting publication.
See why pass and alignment differ.
Connect SPF publication to sender-level alignment and enforcement decisions.
Read the supporting guide for practical context around dmarc monitoring and sender authentication.
Connect aggregate reports, source attribution, policy status, and alerts to the sender authentication dashboard.
Track DNS, TLS-RPT, provider reputation, and placement signals for the domains that carry production mail.
Compare validation volume, monitoring, API access, reporting, and workspace limits by plan.
FAQ
No. A domain must publish exactly one TXT record starting with v=spf1. When two exist, receivers cannot determine which to evaluate and the result is a permanent error under RFC 7208. To authorize several senders, merge their mechanisms into a single record.
RFC 7208 limits evaluation to 10 mechanisms and modifiers that trigger DNS lookups, counted recursively across every include, a, mx, ptr, exists, and redirect in the tree. Exceeding the limit produces a PermError, which receivers treat like a failed check and which can sink DMARC for that message. Shrink the tree: remove unused vendors, prefer ip4/ip6 terms for your own infrastructure, keep nesting shallow.
No. DMARC requires SPF or DKIM to pass with a domain that aligns with the visible From domain. SPF passes on the Return-Path domain, so if that differs from the From domain, DMARC still fails on the SPF side. See the worked pass-but-not-aligned case at /examples/spf-dkim-dmarc-diagnosis.
Use ~all (softfail) while you are still discovering every legitimate sender, because unauthorized mail is marked but usually still accepted. Move to -all (fail) once the record is stable and DMARC reports show your real streams passing. Avoid +all and ?all entirely: +all authorizes everyone, and ?all tells receivers you have no policy.
Yes. Flattening replaces includes with the IP ranges they currently resolve to, so the record stops doing DNS lookups but also stops tracking the provider. When the provider moves sending IPs, the flattened record is wrong until someone edits it, and legitimate mail starts failing. Flatten only stable ranges and monitor for changes, or keep the include and spend the lookups.
SPF evaluates the IP of the server that connects to the receiver. A forwarder resends your message from its own IP, which your record does not authorize, so SPF fails even though nothing is wrong with your setup. This is inherent to the protocol and the reason DKIM, which survives forwarding, carries most of the weight for DMARC on forwarded paths.
No. The tool runs live DNS queries and shows the published answer with its limitations and a link to RFC 7208. It requires no login, opens no SMTP connection, probes no mailbox, and does not retain the domain you submit. It reports DNS evidence only; it does not promise delivery, alignment, or inbox placement.
