tool4.dev

Networking / LOCAL TOOL

SPF & DMARC Record Explainer

Explain an SPF or DMARC record term by term and flag what will not work.

Runs locally — input is never uploaded
An SPF record (v=spf1 ...) or a DMARC record (v=DMARC1; ...)
ResultReady when you are

WHAT IT DOES

What your SPF or DMARC record actually tells receivers to do.

Paste an SPF or DMARC record to inspect its terms, policy, and local-text warnings. SPF lookup-causing terms are counted directly, without resolving nested includes. Review unreachable mechanisms, an ignored redirect, or a monitoring-only DMARC policy without an aggregate-report destination. The page explains the supplied text; it does not query DNS or predict a receiver's delivery decision.

Why use it?

Use it to review the text of an SPF or DMARC record before publishing or troubleshooting it, without querying your domain.

How to use this tool

  1. Paste the record value and explain it. Keep the complete policy rather than an isolated mechanism.
  2. Read SPF terms in evaluation order, or review DMARC tags and warnings. For example, an include after an SPF all mechanism is unreachable.
  3. Treat the SPF lookup count as a local-text estimate: nested includes are not fetched. Confirm the published DNS record and mail-provider requirements outside this tool.

Details and limitations

  • SPF mechanisms are evaluated left to right and the first match decides the result. The all mechanism matches everything, so any term after it is dead text and is reported as such.
  • The qualifier on all supplies the SPF result for remaining senders: -all means fail, ~all softfail, ?all neutral, and +all pass. The receiving system decides how to handle the message; these results are not guaranteed delivery or rejection actions.
  • RFC 7208 limits evaluated lookup-causing terms to ten, including those reached through nested records. The displayed direct count cannot establish the complete evaluation cost; some mechanisms also have their own DNS-response limits.
  • A record whose policy comes from a redirect modifier needs no all term, and a redirect beside an all is never consulted, because all always matches first.
  • DMARC p=none requests no DMARC-specific delivery action. Without rua it also supplies no aggregate-report destination. Receivers may still apply their own filtering, and other reporting mechanisms are separate.
  • This tool never queries DNS. It explains the record text you paste, which is the half that is usually wrong, and means no domain of yours is looked up by tool4.dev.

COMMON QUESTIONS

SPF & DMARC Explainer questions

What does the 10 DNS lookup limit mean?
The SPF limit applies to evaluated terms that cause lookups, including include, a, mx, ptr, exists, and redirect, with nested evaluations counted too. Exceeding it produces permerror, not an absent SPF result. This offline tool counts direct terms only; do not replace a provider's include with a static address list without considering how that provider updates its senders.
Should my record end with -all or ~all?
-all yields SPF fail for remaining senders, while ~all yields softfail. Neither forces every receiver to take the same delivery action. Choose a policy only after checking the domain's legitimate sending paths; this text inspector cannot discover them or confirm that an enforcement change is safe.
Why is DMARC p=none not enough?
A monitoring policy does not request quarantine or rejection for DMARC failures. It can support investigation when reporting is configured, but this tool does not collect those reports or establish that stricter enforcement is safe for the domain. Receiver-specific filtering can still act on messages.
Does this check my domain's real records?
No, and deliberately so. It explains the record text you paste, which is where the mistakes are, and it means nothing about your mail infrastructure is sent anywhere. Use dig TXT yourdomain.com or dig TXT _dmarc.yourdomain.com to fetch the record, then paste it here.