The text in your DNS can stay the same while a provider adds nested references behind it. That can change the lookup count for some of your senders.
Your SPF record can stay exactly the same while the records it points to change.
That is how an email provider can authorise new sending infrastructure without asking every customer to edit DNS. But the same arrangement can add lookup steps to your SPF checks.
A provider can add another reference
Suppose your record includes an email provider. That provider lists some sending IP addresses, so the receiver can check them after following one reference.
Later, the provider reorganises its record to point to separate regional records. Your text has not changed, but a receiver may now need to follow those extra references too. SPF includes can lead to further includes; the cost is not limited to the references visible in your own record. SPF include mechanism
SPF allows ten DNS-querying terms during an evaluation, including those reached inside referenced records. If a check needs more than that, it returns a permanent error. A sender that matches early can still pass while another requires too many steps. SPF lookup limit
Your record stays the same while its references grow
Read the diagram as text
- Before: your SPF include points to a provider record that directly lists sending addresses.
- After: your SPF include is unchanged, but the provider record now points to regional records.
- Following those new references can add lookup steps for some senders.
Find the change behind the unchanged record
In the example above, the local include stays the same. The useful comparison is the provider record before and after it started referencing regional records. Without a saved earlier answer, you can establish today's chain but cannot prove exactly when it changed.
The worked lookup example shows why one sender can match before another reaches the extra references. Use the SPF checker to inspect the current chain, then the lookup-limit guide to assess the affected sending path.
Flattening can reduce supported reference chains. Keeping the flattened IP list current is a separate part of that job, explained in the provider address-change example.
An unchanged record does not explain every failure
A lookup-limit error is one possible cause. A service could start sending from an address it has not authorised, or a message could use a different return-address domain from the one you checked.
Two receivers can also temporarily see different record versions because of DNS caching. The specific SPF result and sending address help distinguish these cases.
When the error is too many lookups, inspecting only the text in your own DNS misses part of the explanation. The records behind its references matter too.