A valid record, a low lookup count and an SPF pass answer different questions. The test behind the result determines what it can tell you.
One SPF checker says your record is valid. Another warns about too many lookups. Both results can be correct: the tools may be testing different things.
Does the result describe the record’s format, its lookup requirements or whether a particular sender passes?
“Valid” and “pass” mean different things
A syntax check examines how the record is written. It can identify an invalid instruction without testing whether your email services are authorised.
A sender-specific evaluation needs the sending IP address and the identity being checked. Its result describes whether the policy authorises that particular sender. Changing the IP address can change the answer.
A DNS inspection tool answers another question: what does this record refer to, and how many lookup steps might those references require? Emailmetry’s public checker performs this kind of inspection. It does not test a message from a particular sending IP address.
A lookup total needs context
SPF checks rules in order and stops at a match or an error. The ten-lookup limit applies to DNS-querying terms reached during that evaluation. SPF evaluation rules
A tool that explores every referenced record can report a larger total than a test for one sending IP. That sender might match an earlier rule before the rest of the record is needed.
A high total across all references does not prove every message will receive an SPF error. Equally, a pass for one sender does not establish that every other sender can pass.
Apply three tests to one example
Use the Alpha and Beta example, where Alpha has one include and Beta has two more references behind its own include.
| Test | Result for the example | What it establishes |
|---|---|---|
| Syntax inspection | The records are syntactically valid. | The rules can be parsed. |
| Inspect every include | Four includes in the reference tree. | How many includes the example can reach. |
| Evaluate Alpha's address, 192.0.2.10 | SPF pass after one include. | Alpha matches before Beta needs checking. |
| Evaluate an unlisted address, 192.0.2.200 | SPF fail after four includes. | No listed sender matched before the final -all. |
These are worked results from reserved example records, not measurements from live vendors. The records are printed in the linked article so you can follow each step. The example names are not live SPF test targets.
The checkers may be seeing different records
DNS servers cache answers for a limited time. After a record changes, two checkers using different DNS servers can temporarily see different versions. DNS caching
Use the DNS propagation checker to compare TXT answers from 24 countries. If you have just changed your SPF record, add the expected values to see which locations return them. This compares published records; it does not test whether a particular sender passes SPF.
The record text and check time help explain that difference. Comparing badges without comparing the records behind them can make an ordinary update look like a contradiction.
This matters after flattening too
SPF flattening replaces supported references with explicit IP addresses or ranges, which do not count towards the ten-lookup limit. SPF lookup rules
A lower count helps show that flattening reduced the lookup requirements. A syntax check helps show that the result is written correctly. Neither establishes that every intended sender is still authorised.
Fewer lookups and preserved sender authorisation are separate things to verify. A useful checker makes clear which one it has actually tested.