How to check an SPF record (and what to actually look at)

dig +short TXT example.com

nslookup -type=TXT example.com

v=spf1 include:_spf.google.com ip4:203.0.113.0/24 -all

Step 3: counting the DNS lookups

This is the most often neglected check. Each include, a, mx, ptr, exists and redirect costs at least one DNS resolution, and the total must not exceed ten. Past that, it's PermError, and the SPF is no longer evaluated. The trap: provider includes unfold into several resolutions each, so the "visible" count misleads.

This calculation can't be done by eye on a complex record — the tree has to be unfolded. That's exactly what our free analyzer does: it recursively resolves each include and surfaces the real count. For a record near or over ten, the 10-lookup limit covers the fix.

Step 4: examining the terminal qualifier

What follows the final all is the tell:

• -all (hardfail) — the goal: what isn't listed isn't legitimate.
• ~all (softfail) — a transition compromise, acceptable but not a target.
• ?all (neutral) — asserts nothing; to be replaced.
• +all (pass) — danger: authorizes everyone. To fix immediately.

A +all is the absolute emergency: the domain declares itself spoofable. The breakdown of qualifiers is in the -all and ~all mechanisms.

Step 5: checking for a duplicate record

A domain must have only one v=spf1 record. Where two turn up (say, one added by marketing and another by IT), many receivers consider the configuration invalid and ignore both — leaving the domain with no effective SPF while its owner believes it's covered. The fix is to merge the two into a single record, combining their mechanisms (and watching the ten-lookup limit along the way).

Step 6: confirming alignment, not just passing

This is the subtlest check, and the most important for DMARC. An SPF that technically "passes" is useless if it doesn't align with the From: domain. Most third-party providers use their own envelope domain; their SPF then passes for them, not for the sender, and DMARC ignores it. Real alignment can only be read from the receiver's side: that's exactly what the aggregate reports reveal, showing source by source whether SPF aligned. If "alignment" feels fuzzy, how the three protocols work together covers it.

An end-to-end check, in practice

Let's run a full check on a fictional domain, shop.com. A dig +short TXT shop.com returns:

"v=spf1 include:_spf.google.com include:shopify.com include:sendgrid.net include:_spf.mailjet.com ~all"

First reflex: only one v=spf1? Yes, good. Syntax? Correct. Qualifier? ~all — acceptable, but note we aim for -all. Now the critical point, the count: these four includes unfold. Google ≈ 4 resolutions, Shopify ≈ 2, SendGrid ≈ 1-2, Mailjet ≈ 2. Total: around ten, at the edge. A fifth provider would tip it into PermError. Verdict: the record "works" today but is fragile, and any new source will have to go through a subdomain.

Last step, alignment: the aggregate reports show that Shopify mail passes SPF but doesn't align (Shopify uses its own envelope domain). Concrete conclusion: for order notifications to count for DMARC, aligned DKIM signing has to be enabled on the Shopify side — SPF alone won't do it.

This five-minute check surfaced three things a plain "the SPF exists" would have hidden: the record is brushing the ten-lookup limit, the qualifier is held back, and one key source doesn't align. That's exactly the difference between noting a presence and judging a quality — and it's that difference that decides whether the mail arrives.

DNS caching, not to be forgotten at fix time

One last trap, usually discovered at the worst moment: DNS is cached. Once the SPF record is corrected, receiving servers can keep evaluating the old version until the TTL expires — sometimes several hours. Two practical consequences. First, a fix that "isn't working" shouldn't be written off too quickly: the zone's authoritative server (the one at the DNS host) always serves the fresh version and is worth querying first, before testing from a public resolver that may still serve the old one. Second, ahead of a sensitive change — a provider migration, a move to -all — lowering the record's TTL a few days beforehand pays off: if something goes wrong, the fix or the rollback propagates that much faster, and the exposure window stays short.

Sender-side vs receiver-side: why both matter

There's a distinction worth making explicit, because it explains why two people can "check the same SPF" and disagree. Sender-side checks read what's published in DNS: syntax, lookup count, qualifier, duplicates. They're fast and entirely under the domain owner's control. Receiver-side checks read what actually happened when a real message arrived: did SPF pass, and did it align? Only the receiver's view, surfaced through the aggregate reports, can answer that — because alignment depends on the envelope domain a provider used, which no amount of DNS inspection reveals on its own.

Most "SPF checkers" only do the sender side. They'll happily pronounce a record valid while a key source silently fails alignment at the receiving end. A complete check uses both lenses: publish-side validation for the record's correctness, report-side observation for its real-world effect. Skipping the second amounts to grading the homework without ever seeing the exam.

A checklist to keep on hand

For a healthy SPF, the checks are:

• there's only one v=spf1 record;
• the syntax is valid (no mistakes, no dead include);
• the resolution count is ten or below;
• the terminal qualifier is -all (or ~all in deliberate transition);
• there's no +all and no ptr;
• the legitimate sources align in the reports.

If all six boxes are ticked, the SPF is doing its job. Otherwise, the fix list is already written.

Frequently asked questions

How often should I check my SPF? At least whenever a sending provider is added or removed, and ideally during a quarterly review. Sending estates drift, and a record that's healthy today can overflow the ten-lookup limit tomorrow.

Is an SPF that passes in a tester enough? Not necessarily. Many testers confirm the syntax is valid, but check neither the real resolution count (by unfolding cascades) nor alignment with the From:. Those two points are exactly what make the difference in production.

Why does my mail fail when my SPF "exists"? Three common causes: a PermError from exceeding ten resolutions, a legitimate source not listed, or an SPF pass that doesn't align (the provider signs on its domain, not the sender's). The aggregate reports settle it.

Can another domain's SPF be checked? Yes — SPF is public. It's useful for auditing a vendor or benchmarking a posture against a competitor's. An analyzer accepts any domain.

What if there's no SPF at all? Publishing one is the answer, listing the real sending sources and ending in -all (or ~all while the inventory runs). It's the first building block of authentication, before DKIM and DMARC.

Should I check my subdomains' SPF separately? Yes. A sending subdomain (news., notif.) has its own SPF record, independent of the root. Any subdomain that really sends gets checked like the main domain — and it has its own ten-resolution budget, which is often an advantage to exploit.

Does a passing SPF guarantee inbox placement? No. SPF is one input among many. Reputation, complaint rates, content and DKIM/DMARC all weigh in. A valid SPF removes one common reason for failure; it doesn't promise the inbox on its own.

Is dig or an online tool better? Both read the same public DNS. dig/nslookup are precise and scriptable; an online analyzer adds the unfolding of includes, the lookup count and the alignment context that raw DNS queries leave out. The command line peeks, an analyzer judges — and the DMARC reports confirm the record actually works where it counts, at the receiving server.

Thomas watches it continuously

Checking an SPF once is good; keeping it healthy over time is better. Thomas, the virtual CISO, continuously checks the record — syntax, resolution count, qualifier, duplicate record — and verifies on the reports that the sources actually align. He raises a flag when something drifts, before the mail suffers for it.

Free DMARC analysis or account signup for a permanently monitored SPF.