The SPF trap: why can make useless SPF records often look simple until you start combining mechanisms and modifiers.
One particularly easy mistake is to write a record like this: At first glance, it seems reasonable: authorize Google, reject everything else, and use another SPF policy through .
But the part will never be used.
The reason is an important detail of how SPF evaluation works. is not a fallback after An SPF record is evaluated mechanism by mechanism.
For example: The receiver checks the mechanisms until one matches.
The mechanism is special because it always matches.
That means: effectively says: If nothing before this matched, return SPF Fail.
Now consider this record again: Once SPF reaches , it already has a result.
There is no reason to evaluate .
The modifier is only used when none of the mechanisms in the record produce a match.
Because always matches, a record containing prevents from being used.
What is actually for The modifier is useful when several domains should share one central SPF policy.
Imagine these domains: Instead of maintaining the same SPF configuration independently on every domain, they can redirect to a central policy.
For example: And the central record might contain: Now the sending policy can be maintained in one place.
This is very different from . vs These two are easy to confuse.
Use when you want to authorize senders defined by another SPF record as part of your own policy.
Example: This says: Google is allowed, this IP is allowed, and everything else should fail.
Your domain still owns the final policy.
Use when another domain should provide the entire remaining SPF policy.
Example: A useful mental shortcut is: That distinction matters when debugging SPF records.
A common broken configuration Consider this: Someone may expect the following behavior: allow , if it does not match, check , otherwise fail.
But SPF does not work that way.
The real evaluation is: check , if it does not match, evaluate , matches every sender, return SPF Fail, is never used.
If you really want the provider to define the policy, the record should instead look like: If you want both your own IP address and the provider's authorized senders, is usually the appropriate mechanism: The position of can be misleading Another subtle point is that is a modifier, not a mechanism.
So it should not be read as if SPF simply processes it from left to right like , , , or .
This record: does not mean: Try redirect first, then .
The presence of the mechanism still means SPF can produce a result without using the redirect.
A good mental model is: Evaluate the SPF mechanisms first.
Only if none of them match can provide another SPF record to evaluate.
Why this matters in production A broken SPF redirect can be surprisingly difficult to notice.
The DNS record is syntactically valid.
A DNS lookup succeeds.
The domain has an SPF record.
Yet mail from an expected sender may still fail SPF because the redirected policy was never evaluated.
This becomes especially confusing when organizations centralize SPF records across many domains.
A small mistake in the parent policy can affect multiple domains at once.
When debugging this kind of issue, check: whether the record contains an mechanism, whether is actually reachable, whether you really need or should use , the SPF result returned by the redirected domain, the total number of DNS-querying SPF terms.
A simple rule to remember If your SPF record contains: and also: you should take a closer look.
In most cases, that combination indicates that the redirect is not doing what the author intended.
Use: when another domain should define the SPF policy.
Use: when another SPF policy should be incorporated into your own.
And use: when you are ready to explicitly fail senders that did not match any previous mechanism.
If you are debugging a more complex configuration, I wrote a more detailed guide to the SPF redirect modifier, including vs , DNS lookup behavior, common errors, and practical examples.
You can also inspect an SPF record directly with the MXFend SPF checker.