SPF Record Validator

When this is useful

• Before publishing: see the lookup count before a receiving mail server does.
• When adding a sending service: find out whether one more include still fits in the remaining budget.
• When reviewing work: validate what a contractor or a vendor guide proposes.
• When studying someone else's setup: see what a competitor's or partner's record is actually made of.

What to paste

Just the TXT value: the string that starts with v=spf1. There is no need to copy the record name, type or TTL from your DNS panel. Surrounding quotes are stripped automatically if they come along with the text.

What gets checked

Parsing follows RFC 7208 rather than a list of common typos, so the rarer cases surface too:

• Version. The record has to open with v=spf1, and a domain must publish exactly one of them. Two records are a permerror, and then the check fails for every sender.
• Lookup budget. The include, a, mx, ptr and exists mechanisms and the redirect modifier all spend the ten-lookup limit, and they do it recursively, so nested includes inside third-party services count as well.
• The final mechanism. -all, ~all or ?all at the end: without one the record forbids nothing, and anything placed after all is never evaluated.
• Address syntax. Masks such as ip4:192.0.2.0/33, an IPv6 address inside an ip4 mechanism, stray whitespace in the value.

The failures we see most

First, blowing the lookup budget after connecting one more service: an ESP, a CRM and a helpdesk bring two or three nested includes each. Second, ptr, which has been deprecated for years and which some providers ignore outright. Third, listing every sender by hand instead of using include, which bloats the record until a single TXT string runs past 255 characters.

A separate case is a record copied out of documentation together with the example domain. It is syntactically valid and the validator will pass it, but it authorises somebody else's infrastructure. Check that every include names a service of yours.

How this differs from checking a domain

The SPF checker goes to DNS and parses what is published there. The validator works on text you paste in, and the record may not exist yet. Different questions: one answers "what does this domain have right now", the other "will the thing I am about to publish fly".

Expanding include still involves real DNS queries: counting the budget requires knowing what sits inside other people's records today. So the counter reflects the current picture rather than a theoretical one.

How to read the lookup counter

The validator shows more than the total: it attributes lookups to each mechanism. That breakdown matters more than the sum: a line like include:_spf.example.com may cost one lookup or eight, depending on the chain hidden inside it.

Two or three lookups of headroom is the safe zone. A count of eight or nine technically passes while meaning the record will break the moment any connected service expands its infrastructure. That happens without warning and presents as delivery mysteriously going wrong.

What the validator cannot check

A syntactically correct record can still be substantively wrong. The validator has no idea which services you use, so it will not flag a leftover include from something you abandoned, nor a missing one for something you just connected.

Only DMARC reports settle that: they list the actual sources sending as your domain, with the SPF outcome for each. The gap between that list and the contents of your record is the real configuration error.

Where include values come from

Every service publishes its own in their documentation, and that is where to take it from rather than from an article somewhere, because the values change. A typo in an include target means a domain with no SPF record, and that mechanism breaks the entire evaluation: the record stops working altogether rather than merely losing one service.

A related trap is copying an example along with somebody else's domain. A line like include:_spf.example.com, pasted verbatim, is syntactically flawless, passes validation, and authorises infrastructure you have nothing to do with.