redirect is a lesser known feature of SPF that may cause some confusion about its intended use.
In this article we'll dive into SPF
redirect, when (not) to use it and how to avoid common pitfalls with it.
redirect is often confused with
include, due to its similar name and functionality.
But there are some essential differences which can cause hard to trace down deliverability issues if used incorrectly.
A redirect is a pointer to another domain name that hosts an SPF policy, it allows for multiple domains to share the same SPF policy. It is useful when working with a large amount of domains that share the same email infrastructure.
domain_a.com has an SPF record like this:
This means that the SPF record for
domain_b.com should be used instead for
redirectis not a mechanism
The various matching rules in an SPF record are created with mechanisms.
Common mechanisms are
redirect is not an SPF mechanism, it is known as a modifier.
Modifiers differ in syntax from mechanisms.
A modifier must always contain a value, as opposed to mechanisms where values are often optional.
Modifiers also have a different key/value separator: the equal sign (
=), where mechanisms use a colon (
Modifiers also do not use a prefix (
|modifier||required||no||equal sign (
v=spf1 include:_spf.mailhardener.com -all
The example above is correct, if we read it from left to right:
vis a modifier, its value
spf1is separated with an equal sign (
includeis a mechanism, its value
_spf.mailhardener.comis separated with a colon (
-allis also a mechanism, without a value, but with an explicit prefix (
The mechanisms in an SPF record are evaluated from left to right.
redirect is not a mechanism, it is always evaluated after the mechanisms, regardless of where you place it.
It is therefore recommended, but not required to place the
redirect at the very end of the SPF record, to clarify that it is only used if the preceding mechanisms didn't match.
redirect modifier is only used if no other mechanism matches.
All mechanisms are evaluated first (from left to right), and only if none of the mechanisms match the email sender is the redirect used.
It is important to realise that the
all mechanism always matches.
So if there is an
all mechanism anywhere in the record, the
redirect is completely ignored.
An SPF record with a
redirect should not contain the
The following example shows a common made mistake with redirects:
mailhardener.com "v=spf1 redirect=_spf.mailprovider.com -all" _spf.mailprovider.com "v=spf1 ip4:126.96.36.199/16 ~all
When the example above is evaluated, it will always result in
-all, the redirect is completely ignored.
This means that in this example, no senders will pass SPF validation, even from
redirectchanges the domain name.
ptr the value is optional.
If no value is set it defaults to the current domain.
But when a
redirect is used, the
ptr mechanism will point to the redirected domain.
mailhardener.com "v=spf1 a -all"
a mechanism has no value, so it points to the DNS
A record of
mailhardener.com, because that's where the SPF record is hosted.
But now consider the following situation:
mailhardener.com "v=spf1 redirect=_spf.mailhardener.com" _spf.mailhardener.com "v=spf1 a -all"
In this example the
a mechanism points to the DNS
A record of
_spf.mailhardener.com, even though it was redirected to by the
mailhardener.com root domain.
This is a common cause of SPF validation issues, and hard to debug.
If you use SPF
redirect, be aware that if the redirected SPF record has an
ptr mechanism without an explicitly set domain name, it will point to the redirected domain.
Unlike with the
include mechanism, the
redirect modifier will cause the
all mechanism of the redirected domain to be used.
That is, of course, because when working with the
redirect modifier, the root domain is not supposed to have the
all modifier set.
A common use-case with an
include is this:
mailhardener.com "v=spf1 include:_spf.mailprovider.com -all" _spf.mailprovider.com "v=spf1 ip4:188.8.131.52/16 ~all
For the example above, there are 2
all mechanisms. Because the
include does not affect the
all mechanism the
-all rule of the root domain is used and not the
~all rule of the included record.
redirect modifier does influence the
all mechanism, consider the following scenario:
mailhardener.com "v=spf1 redirect=_spf.mailprovider.com" _spf.mailprovider.com "v=spf1 ip4:184.108.40.206/16 ~all
When the example above is evaluated, the redirect is followed resulting in the
~all modifier being used for the root domain.
One interesting observation is the following (notice the use of
mailhardener.com "v=spf1 include:_spf.mailprovider.com" _spf.mailprovider.com "v=spf1 ip4:220.127.116.11/16 ~all
This will actually result in a
?all (neutral) mechanism being assumed, effectively disabling SPF for the domain.
That is because the root domain does not have a
all mechanism set, and the
include mechanism will not influence this.
In this last example, the
redirect should have been used instead of the
redirectretains error state
Normally, if a domain has no SPF record, the SPF evaluation will return a
none error, meaning that the receiver will take a neutral stance in examining the email.
redirect to a domain that does not have an SPF policy, or the SPF policy contains a syntax error, the SPF validation will fail with a
This usually results in the email failing SPF validation.
include mechanism if the included policy does not exist or contains a syntax error, the evaluation continues.
softerror may be reported with DMARC, but a sender can still pass SPF validation if it matches any other mechanism.
redirectcounts as a DNS query
The SPF RFC7208 limits the number of additional DNS queries required to fully evaluate an SPF record to 10. The initial fetch of the SPF record does not count towards that total.
redict also increases this count. So be careful when using a
redirect, as you may exceed the limit of 10 DNS queries.
This may cause receivers to ignore your SPF policy.
You can use our SPF validator tool to test the number of required DNS queries to evaluate your SPF record.
redirect modifier can be used to consolidate a common SPF policy amongst a group of domains.
It is useful when working with a large amount of domains that share the same email infrastructure.
However, there are many caveats that you should be aware of before implementing
Unless you have a good reason to use the
redirect modifier, you are probably better off using the
In RFC7208 section 5.2 the authors conclude that in hindsight the names for
redirect were poorly chosen.
redirect modifier should have been called
include, and it would have been better if
include was called something like
redirectmodifier, see of you can use the
redirectmodifier, regardless of position.
allmechanism if you use a
redirectlast in the SPF record.
redirectalways counts as an additional query, so may cause exceeding the 10 lookup limit.
Regardless on whether you use a
redirect or not, it is always a good idea to validate your SPF record.