Why One SPF Record Can Have Different Lookup Counts

SPF's lookup count depends on the path evaluated for a message. A sender that matches early can use fewer lookup-causing terms than one that reaches nested includes. Counting every reference in a policy measures something different. That is why a provider's SPF cost is not always one fixed number.

Two tools can report different counts for the same SPF record without counting the same thing. A policy's complete dependency map is not the path every message will evaluate.

What the SPF limit counts

SPF allows at most ten DNS-lookup-causing terms during evaluation, including nested references. Literal ip4 and ip6 mechanisms do not add to that term count. The limit is not simply the number of network queries a DNS resolver sends.

Evaluation can stop when a mechanism matches. The order of terms and the sending IP therefore matter.

One record, four sending IPs

Here is a fictional policy set using documentation domains and addresses. Assume each name returns exactly the policy shown, with no DNS errors or other terms.

For mail using example.com as the envelope-sender domain:

These are calculations from the displayed policies, not measurements of real providers. They exclude the initial retrieval of the root policy, which is not one of the counted terms.

The root contains two includes. The whole structure contains four. The first sender evaluates one. Each number describes a different observation.

Provider comparisons need a configuration

A provider's include can lead to nested policies, and those policies can change. A meaningful lookup comparison needs the observed records, a date and the sender being evaluated.

It also needs the right domain. Amazon SES supports default and custom MAIL FROM configurations, so a business using SES does not necessarily add its SPF policy to the root domain. Adding together numbers for product names can describe a configuration the business does not use.

A lower count is not the only objective

Removing a legitimate sender to get a smaller count breaks the purpose of the policy. Flattening can reduce counted terms but creates an address-maintenance question; Microsoft advises against flattening its Microsoft 365 include.

The useful question is whether the intended sending paths can pass within SPF's limits. Our lookup-limit explanation covers that boundary. A whole-policy inspection can flag complexity, but it should not claim to be an exact result for every sender.