The SPF record everybody can read in five seconds is the one with two includes and a -all. The SPF record nobody can read without counting on their fingers is the one a client built up over four years — include:_spf.google.com, an old include:_spf.mailgun.org from a campaign nobody remembers, two a and mx mechanisms inherited from a self-hosted era, and a wildcard include from a marketing vendor that itself includes three more. SPF Lookup & Parser exists for the second case.
What the tool does
It fetches the v=spf1 TXT record for a domain, splits it into individual mechanisms, recursively resolves every include and redirect so you can see the full sender set, and counts DNS lookups against RFC 7208’s hard limit of ten. The catch-all policy (-all, ~all, ?all, +all) is called out separately because misreading the catch-all is the single most common SPF mistake.
The lookup count matters more than the readability. Once SPF evaluation crosses ten DNS lookups, receivers must return permerror, and a permerror SPF is treated by most receivers as the domain having no SPF at all. A domain that was perfectly compliant on Monday can fall off the limit on Tuesday when a single SaaS vendor adds a sender to their own include chain — and you find out via the deliverability complaint, not via the change.
How to use it
Open portjar.com/tools/spf-lookup and enter the apex domain (SPF is published at the apex, not on subdomains except in carefully-designed setups). The parser returns a breakdown that names each mechanism, its source, and its contribution to the lookup count. The catch-all is at the bottom and is the field you read first.
When you make a change to flatten or restructure the record, re-run the lookup immediately after publishing. The TXT record is small and TTLs are typically short; the answer should reflect the change within a couple of minutes.
When you’d reach for it
- A deliverability complaint where the mail is being rejected with
SPF permerrorortoo many DNS lookups. PortJar’s “SPF PermError” troubleshooting guide walks through the count-and-flatten process, and the parser is the tool that does the counting for you. - A new sender (a marketing platform, a help desk that sends from the domain, a billing service) is being added to SPF and you need to confirm the include did not push the record over the limit.
- Onboarding a domain where you don’t have the registrar credentials yet — the parser tells you exactly what is published without needing access.
- A migration from one mail provider to another, where you need to confirm the old include was removed and the new one took its place. Forgetting to remove the old include is the typical cause of a
+allaccidentally becoming permissive. - A domain audit during a takeover, where you want a single document showing every entity authorized to send as the domain. The parsed include tree gives you that list.
What to make of the output
A clean SPF record under ten lookups, with -all as the catch-all, and an include list that matches what the client believes they send from is the goal. That is the only state you should leave a managed domain in.
A ~all (softfail) is acceptable during rollout — it tells receivers to accept-but-mark-as-suspicious unauthorized sources. Treat ~all as a staging state, not a destination. Once you have confirmed every sender is in the record and DMARC has been clean for a week, move to -all.
A +all is almost always a misconfiguration. It tells receivers any IP may send for the domain, which is the opposite of what SPF is for. The most common cause is a typo — somebody pasted ?all and meant -all, or pasted +all while testing and never reverted. Fix immediately.
A lookup count over ten means SPF evaluation will return permerror and the record is effectively non-existent for receivers. The fix is to flatten — remove includes that are not actually sending, replace high-cost includes with explicit IP ranges, or use a hosted SPF service that flattens for you. Flattening trades human-readability for survival of the lookup budget.
Multiple v=spf1 records on the same domain is also a permerror shape. Only one SPF record is allowed; receivers will reject the lot if they find two. This typically happens when a vendor’s onboarding wizard publishes a second record alongside the existing one. The parser flags this case so you spot it before the receiver does.
Stack Harbor manages SPF, DKIM, and DMARC on every domain we operate as part of Environment Management as a Service.