How to check your SPF record

By the zmam.ai team ·

On this page

Your SPF record is not a secret. It is a public TXT record in your domain’s DNS, which means you can read it from any computer in seconds — and so can anyone sizing up your domain for impersonation. Reading it yourself, and knowing what “good” looks like, is the cheapest security check you will ever run.

The thirty-second version

Any tool that displays DNS TXT records will show your SPF. Search for an “SPF record checker,” enter your domain, and find the line beginning with v=spf1. That is it. If you never touch a command line, stop here.

With dig (macOS, Linux)

dig +short TXT example.com

Look for the value starting with v=spf1. To cut the noise:

dig TXT example.com | grep spf1

With nslookup (Windows)

nslookup -type=txt example.com

The SPF record is the string beginning v=spf1.

Reading the result like a defender

A healthy record names every legitimate sender and ends with a hard fail:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

Four problems account for almost every real-world SPF failure:

  1. No record at all. Receivers have nothing to check you against, and your domain is trivial to spoof.
  2. A soft ending. ~all or ?all tells receivers not to take unauthorized mail seriously. You almost always want -all.
  3. Too many lookups. SPF allows a maximum of ten DNS lookups as it expands include: chains. Cross that line and the record returns a permanent error that receivers read as failure — a self-inflicted outage hiding in a record that looks fine.
  4. A dangling include:. An include: pointing at a domain that has expired is not just dead weight; it is the takeover vector behind the SubdoMailing campaign . Every domain you include: is a domain you are trusting to still belong to who you think.

A fifth, rarer mistake is fatal: two SPF records on one domain. The standard allows exactly one; two is an error.

How zmam.ai helps

zmam.ai resolves your SPF record the way a receiving server would — expanding the includes, counting the lookups, and checking whether each included domain still exists — then reports a missing record, a weak ending, an over-limit lookup count, or a dangling include, alongside your DKIM and DMARC so you see the whole picture at once.