Free SPF record check: see if your record actually works

How to check an SPF record

Enter the domain in the box above and select Validate. The check reads the TXT record published at the domain root and reports whether the SPF policy is strict. To read the record text yourself, run dig TXT example.com on macOS or Linux, or nslookup -type=TXT example.com on Windows.

DNS answers are cached, so a record you changed this morning can still return the old value for hours. If the result looks stale, query a public resolver directly with dig TXT example.com @1.1.1.1 and compare.

What an SPF record looks like

An SPF record is a single TXT record on the domain root that starts with v=spf1. Everything after it is a list of mechanisms, read left to right, ending in a rule for every sender the list did not cover.

A typical record for a company using Google Workspace, a transactional sender and one static mail server:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.7 -all

A receiving server walks that list in order. The first mechanism that matches the sending address decides the result, and all catches everything left over.

What each mechanism means

Eight mechanisms do all the work. Each one either matches the sending server or hands the decision to the next in line.

• v=spf1 is the version tag. It must come first, and a record without it is not an SPF record.
• ip4: and ip6: match a literal address or a CIDR range, such as ip4:198.51.100.0/24.
• a matches the addresses in the domain's own A or AAAA records.
• mx matches the servers listed in the domain's MX records, which is useful when the same hosts send and receive.
• include: hands the check to another domain's SPF record. This is how you authorize Google, Microsoft or a sending platform.
• exists: passes when a lookup on the named domain returns any address. It is used for per-sender rules and is rare outside large senders.
• redirect= replaces your record with another domain's entirely. It only applies when no mechanism matched, and it should be the only thing in the record.
• all matches every sender the earlier mechanisms did not. It always goes last, and the qualifier in front of it decides what happens.

-all, ~all and ?all, and what each one changes

The qualifier in front of all tells receiving servers what to do with mail from a server your record does not list. It is the single most consequential character in the record.

• -all is a hard fail. Receiving servers are told to reject unlisted senders outright. This is the only setting that stops spoofing.
• ~all is a soft fail. Unlisted mail is accepted and usually filed as spam. Most domains sit here, which is why spoofed mail still arrives.
• ?all is neutral. It carries no opinion, so the record protects nothing and you may as well have published no record at all.
• +all passes everything. It authorizes the entire internet to send as your domain. If a check returns this, treat it as an incident.

The check above reports a strict policy when the record ends in -all. Anything softer means an attacker can still send mail that passes your domain's own authentication.

The 10 DNS lookup limit, and why records break

SPF allows 10 DNS lookups per evaluation. Cross it and receiving servers return permerror and ignore your record completely, no matter which qualifier you set. This is the most common reason a record that looks correct does nothing.

include:, a, mx, exists: and redirect= each cost a lookup, and every include can trigger more inside the record it points to. ip4:, ip6: and all cost nothing.

One include for Google Workspace already resolves to three or four lookups on its own. Add a CRM, a help desk and a marketing platform and a normal company sits at eight or nine without noticing. Nothing warns you when the tenth arrives.

Flattening, which means replacing an include with the addresses it currently resolves to, buys headroom and costs maintenance. The moment a provider changes an IP range your mail starts failing, and nothing tells you. Use it only for providers that publish static addresses and commit to them.

What else makes a record fail

• Two SPF records on the same domain. The specification allows one. Two produces permerror, and every sender fails.
• A single string over 255 characters. Split the record into several quoted strings inside the same TXT record, which resolvers join back together.
• A subdomain with no record of its own. SPF does not inherit, so mail from notify.example.com is unprotected unless you publish a record there too.
• An include for a service you stopped using. It still spends a lookup, and it still authorizes whoever holds that account now.

How to fix a record that is failing

The DNS edit takes a minute. The work is knowing what sends mail as you, and that list is always longer than anyone expects.

• Write down every service that sends on your behalf: billing, support, marketing, CRM, monitoring, recruiting and anything your finance team signed up for.
• Count the lookups your current record resolves to, including the ones nested inside each include.
• Remove includes for services you no longer use, which is usually enough to get back under 10.
• Replace an include with ip4: ranges only when the provider publishes static addresses and commits to them in writing.
• Move to -all once the list is complete, and check the DMARC reports for a few weeks before you stop watching.

SPF is one of two ways mail passes DMARC, and DMARC is what tells receiving servers to act on a failure. Run a DMARC check on the same domain once your SPF record is clean, because a strict SPF record with no DMARC policy still leaves forged mail delivered as normal.

Checking SPF in your own code

If you screen sending domains at signup or before a send, the Email Reputation API returns the SPF policy alongside domain and mailbox checks in a single request, so you do not need to run DNS queries yourself.