Overview

The SPF redirect explained

The SPF redirect modifier (not to be confused with the include mechanism) is a lesser known feature of SPF that often causes 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.

The 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.

What the redirect does

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.

Example: if domain_a.com has an SPF record like this:

v=spf1 redirect=domain_b.com

This means that the SPF record for domain_b.com should be used instead for domain_a.

Caveat 1: The redirect is not a mechanism

The various matching terms in an SPF record are created with mechanisms. Common mechanisms are a, mx, ip4, ip6 and include.

But 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: modifiers use the equal sign (=), whereas mechanisms use a colon (:).

Modifiers also do not use a prefix (+, -, ~ or ?).

Type Value Prefix Separator
mechanism optional yes colon (:)
modifier required no equal sign ( =)

Example:

v=spf1 include:_spf.mailhardener.com ~all

The example above is correct, if we read it from left to right:

The mechanisms in an SPF record are evaluated from left to right. Since 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.

Caveat 2: mechanisms overrule a redirect

The 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 realize 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 all mechanism.

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:123.123.123.123/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 123.123.123.123/16.

Caveat 3: redirect changes the domain name.

For mechanisms a, mx and ptr the value is optional. If no value is set it defaults to the current domain. But when a redirect is used, the a, mx or ptr mechanism will point to the redirected domain.

Example:

mailhardener.com   "v=spf1 a ~all"

Here, the 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 origin 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 mx, a or ptr mechanism without an explicitly set domain name, it will point to the redirected domain.

Caveat 4: redirect affects the all mechanism

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 origin 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:123.123.123.123/16 ~all

For the example above, there are 2 terms using the all mechanisms. Because the include does not affect the all mechanism the -all term of the origin domain is used and not the ~all term of the included record.

But the 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:123.123.123.123/16 ~all

When the example above is evaluated, the redirect is followed resulting in the ~all modifier being used for the domain.

One interesting observation is the following (notice the use of include):

mailhardener.com      "v=spf1 include:_spf.mailprovider.com"
_spf.mailprovider.com "v=spf1 ip4:123.123.123.123/16 ~all

This will actually result in a ?all (neutral) mechanism being assumed, effectively disabling SPF for the domain. That is because the origin 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 include.

Caveat 5: redirect retains 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.

If you 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 permerror error. This usually results in the email failing SPF validation.

With the include mechanism if the included policy does not exist or contains a syntax error, the evaluation continues. A softerror may be reported with DMARC, but a sender can still pass SPF validation if it matches any other mechanism.

Caveat 6: redirect counts 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.

A 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 record validator tool to test the number of required DNS queries to evaluate your SPF record.

Conclusion

The SPF 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 redirect.

Unless you have a good reason to use the redirect modifier, you are probably better off using the include mechanism.

In RFC7208 section 5.2 the authors conclude that in hindsight the names for include and redirect were poorly chosen. The redirect modifier should have been called include, and it would have been better if include was called something like on-match.

To summarize:

Regardless on whether you use a redirect or not, it is always a good idea to validate your SPF record.

Further reading

Mailhardener is an email hardening platform. It helps you to monitor your domain and email traffic to take full advantage of the email security standards. This helps prevent fraud and improve deliverability.
Sign up now