Pull and parse any domain's SPF record + policy in one lookup.
Look up your domain's SPF record and parse the policy. SPF authorises which servers may send mail using your domain in the envelope-from — mailbox providers downrank or reject messages whose sending IP isn't covered.
SPF (Sender Policy Framework) is a single TXT record at the root of your domain that lists every server allowed to send mail using your domain in the envelope (Return-Path) address. When a receiver gets a message, it reads that record and checks whether the connecting IP is authorised. A pass is one of the three pillars — SPF, DKIM, DMARC — that decide whether your mail is trusted or treated as a likely spoof.
SPF lives at the very start of the email lifecycle: you set it up before your first send, then re-verify it every time you add a new sending service (a new ESP, a transactional provider, a CRM that sends on your behalf). Two failure modes are common and both are silent. The first is forgetting to include a provider, so its mail fails SPF. The second is the "too many DNS lookups" limit — SPF allows a maximum of 10 nested DNS lookups, and once you chain enough include: mechanisms you blow past it and the whole record returns permerror, which most receivers treat as a fail.
The policy qualifier at the end of the record is what actually carries teeth. -all (hard fail) tells receivers to reject anything not listed; ~all (soft fail) asks them to accept-but-mark; ?all (neutral) says do nothing. This checker reads the record live, tells you whether it is present, valid, and which qualifier you are publishing, and flags the multiple-record condition that silently breaks SPF entirely (RFC only permits one).
It queries the TXT records at your domain root, finds the one beginning v=spf1, and parses it — reporting whether SPF is present, valid, missing, or duplicated, plus the trailing policy qualifier (-all, ~all, or ?all).
-all is a hard fail (reject unauthorised senders), ~all is a soft fail (accept but mark suspicious), and ?all is neutral (no opinion). Most domains should run ~all while ramping and tighten to -all once they're confident every legitimate sender is listed.
The two usual causes are publishing more than one v=spf1 TXT record (RFC 7208 permits exactly one — multiple records is an automatic permerror) and exceeding the 10-DNS-lookup limit by chaining too many include: mechanisms. Either condition fails the whole record.
Partly. SPF authenticates the envelope-from domain, but it breaks on forwarding and doesn't cover the visible From: header on its own. You need DKIM and DMARC alignment on top of SPF for a complete, forwarding-resilient setup.
Build one with the free SPF generator, publish it as a TXT record at your domain root, wait for DNS to propagate, then re-run this checker to confirm it resolves and the policy is what you intended.
Any time you add or remove a sending service, and as part of routine pre-send QA before a big campaign. SPF is set-and-forget until someone changes your stack — and that change is exactly when it silently breaks.
SieveGuard's Domain Health add-on re-runs this SPF check continuously across every sending domain you onboard, alerts you when a record changes or breaks the 10-lookup limit, and surfaces the result as a per-record badge.