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

"We do have SPF." That sentence reassures you wrongly: the presence of an SPF record says nothing about its quality. An SPF can exist and yet overflow the lookup limit, contain a syntax error, authorize the whole world, or align none of your sources. Checking your SPF is therefore much more than confirming it's there. This guide shows you, step by step, how to find your record, read it correctly, and spot the problems that quietly undermine your deliverability.

Step 1: find your record

Your SPF is a TXT record published at your domain's root. To see it, you can query DNS directly. On the command line:

dig +short TXT your-domain.com

or, on Windows:

nslookup -type=TXT your-domain.com

Among the TXT records returned, the SPF is the one that starts with v=spf1. If there's one, note it; if there are two starting with v=spf1, you already have a problem (see below). If there's none, your domain has no SPF at all — that's the first thing to fix.

Step 2: read the syntax

An SPF record reads left to right, mechanism by mechanism. Example:

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

• v=spf1 — the version, mandatory at the front.
• include:_spf.google.com — authorizes the servers Google lists.
• ip4:203.0.113.0/24 — authorizes a hard-coded address range.
• -all — the terminal qualifier: everything else is refused.

Each mechanism can be preceded by a qualifier (+, -, ~, ?). Check there are no common mistakes: a missing space, a forgotten colon, an include pointing to a non-existent domain. A single mistake can tip the whole record into error.

Step 3: count 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 your SPF is no longer evaluated. The trap: provider includes unfold into several resolutions each, so the "visible" count misleads.

You can't do this calculation by eye on a complex record — you have to unfold the tree. That's exactly what our free analyzer does: it recursively resolves each include and shows you the real count. If you're near or over ten, see the 10-lookup limit to fix it.

Step 4: examine the terminal qualifier

Look at what follows the final all:

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

If you find +all, it's the absolute emergency: your domain declares itself spoofable. The breakdown of qualifiers is in the -all and ~all mechanisms.

Step 5: check for a duplicate record

A domain must have only one v=spf1 record. If you find two (say, one added by marketing and another by IT), many receivers consider the configuration invalid and ignore both — leaving you with no effective SPF while you believe you're 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: confirm alignment, not just passing

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

An end-to-end check, in practice

Let's run a full check on a fictional domain, shop.com. You run dig +short TXT shop.com and get:

"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: you open your aggregate reports and find that Shopify mail passes SPF but doesn't align (Shopify uses its own envelope domain). Concrete conclusion: for order notifications to count for DMARC, you need to enable aligned DKIM signing on the Shopify side — SPF alone won't do it.

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

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 you publish in DNS: syntax, lookup count, qualifier, duplicates. They're fast and you control them entirely. 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 your aggregate reports, can tell you that — because alignment depends on the envelope domain a provider used, which you can't see from your own DNS alone.

Most "SPF checkers" only do the sender side. They'll happily tell you your record is 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. Skip the second, and you're grading your homework without ever seeing the exam.

A checklist to keep on hand

For a healthy SPF, check that:

• 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;
• your legitimate sources align in the reports.

If all six boxes are ticked, your SPF is doing its job. Otherwise, you know exactly what to fix.

Frequently asked questions

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

My SPF passes in a tester, is that enough? Not necessarily. Many testers confirm the syntax is valid, but check neither the real resolution count (by unfolding cascades) nor alignment with your 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 yours). Your aggregate reports settle it.

Can I check another domain's SPF? Yes — SPF is public. It's useful for auditing a vendor or comparing your posture to a competitor's. An analyzer accepts any domain.

What if I have no SPF at all? Publish one, listing your real sending sources and ending in -all (or ~all while you inventory). 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. If you send from a subdomain, check it like the main domain — and remember 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 don't give you. Use the command line to peek, an analyzer to judge — and your DMARC reports to confirm the record actually works where it counts, at the receiving server.

Let Thomas watch it for you

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

Analyze your domain for free → or create an account for a permanently monitored SPF.