SPF Record Parser & Explainer

Paste any SPF record and get a term-by-term breakdown in plain English: what each mechanism means, its qualifier (pass/fail/softfail/neutral), and how many DNS lookups it consumes. The tool flags the common issues that cause deliverability problems — exceeding the 10-lookup limit, using +all, a missing all mechanism, and the deprecated ptr mechanism.

How to use the SPF Record Parser & Explainer

Paste the raw TXT record value (the string that starts with v=spf1) into the input and click Parse. You can get this value by running:

  • dig TXT example.com in a terminal
  • nslookup -type=TXT example.com on Windows
  • Any DNS lookup tool — paste only the TXT value, not the surrounding quotes

The parser breaks the record into individual terms and explains each one:

  • Version — confirms v=spf1 is present and valid.
  • Mechanisms — mx, a, include:, ip4:, ip6:, ptr:, exists:, all — each with its qualifier and plain-English meaning.
  • Modifiers — redirect=, exp= — shown with their purpose.
  • DNS lookup count — the running total toward the 10-lookup limit.

After the table, the tool shows an overall verdict: pass (record is valid), warning (issues that hurt deliverability but don't break evaluation), or error (record will cause permerror or is invalid).

About SPF Parsing

An SPF record is a sequence of whitespace-separated tokens. Each token is a term, which is either a mechanism (describing an allowed or denied sender) or a modifier (changing evaluation behaviour). Every mechanism can be prefixed with a qualifier: + (pass, default if omitted), - (fail), ~ (softfail), or ? (neutral). Understanding each term is necessary to debug deliverability issues — a misconfigured SPF record can silently drop legitimate mail or fail to block spoofed senders.

The RFC 7208 evaluation algorithm walks the terms left to right and stops at the first matching mechanism. The all mechanism at the end acts as a catch-all. If no mechanism matches before all, the result is whichever qualifier all carries. A missing all mechanism results in a neutral outcome by default — receivers treat unlisted senders as neutral, not as failures. This is rarely the intended behaviour in production. You may also find the SPF Record Generator useful for building or rebuilding your record.

Common pitfalls caught by this parser: too many DNS lookups (RFC 7208 caps the total at 10 during a single evaluation; exceeding this causes a permerror result, which many receivers treat identically to a hard fail); +all (explicitly passes mail from any sender, making SPF useless as an anti-spoofing measure — often left in accidentally); ptr: (performs a PTR lookup on the connecting IP then verifies the forward DNS — it is slow, unreliable, and officially deprecated in RFC 7208 section 5.5); and multiple SPF records (RFC 7208 section 3.2 prohibits more than one v=spf1 TXT record per domain).

Common use cases

  • Deliverability debugging — a specific sending IP is failing SPF; trace which mechanism it would match (or miss) and why.
  • Lookup-limit audit — count DNS-lookup mechanisms before adding another include: and exceeding the 10-lookup limit.
  • Vendor onboarding review — verify that a new email provider's suggested SPF snippet won't push your record over the limit or introduce a +all.
  • Security posture check — confirm that your record ends with -all (hard fail) rather than ~all or no all, to actively block spoofed mail.
  • Post-migration validation — after switching mail providers, confirm the old sender's include: was removed and no dangling mechanisms remain.

Frequently asked questions

Why does my SPF record fail even though the IP is in an ip4: range?
SPF checks the envelope sender domain (MAIL FROM), not the From: header. If a service uses a different domain in MAIL FROM, your SPF record doesn't apply to that connection. Also check that the ip4: range actually contains the sending IP — a CIDR miscalculation is common.

What does "softfail (~all)" mean in practice?
Softfail tells receivers to accept the message but mark it as suspicious — typically by adding an X-Spam-Status header. It does not cause outright rejection. Many organizations use ~all during SPF rollout to avoid blocking legitimate mail, then switch to -all once the record is validated.

Does parsing an SPF record here make a DNS lookup?
No — this tool parses only the TXT record string you paste. It does not resolve the domains referenced by include: or mx mechanisms. It counts those mechanisms toward the lookup limit, but the actual DNS resolution happens server-side during live email delivery.

What is the redirect= modifier and when is it used?
The redirect= modifier replaces the entire evaluation with the SPF record of the target domain. It is most useful when you manage multiple domains and want them all to share one authoritative SPF record. Note: redirect= counts as one DNS lookup and is mutually exclusive with the all mechanism.

Can I have include: inside my SPF record and also have the included domain have its own include: chains?
Yes, and this is exactly what consumes the 10-lookup budget. Each include: hop that itself contains include:, mx, or a mechanisms adds to the total lookup count for the outer domain's evaluation. The limit is cumulative across all hops, not per level.