The SPF (Sender Policy Framework) redirect is a record modifier that points to a separate domain name containing an SPF record. Domain owners can configure multiple domains to make use of a single SPF record hosted on one domain using SPF redirect. While it may seem to be beneficial in some ways, we don’t recommend it. Read more to find out why!

Key Takeaways

SPF redirect allows multiple domains to share a single SPF record but requires careful configuration to avoid validation issues.
The SPF redirect modifier can increase the number of DNS lookups, potentially exceeding the maximum allowed and causing authentication failures.
Utilizing the SPF include mechanism offers greater flexibility and reduces the risk of falling into error states when managing SPF records.
Invalid or missing SPF records in redirected domains can lead to a hard fail result, complicating email verification processes.
To enhance email security, organizations should implement SPF alongside DKIM and DMARC for robust protection against spoofing and phishing attacks.

Introduction to SPF and the Redirect Modifier

SPF is the email-authentication standard that protects your organization against impersonation and spam by maintaining a record of authorized parties.

While the SPF redirect modifier is optional and may only be used once per SPF record. There are certain prerequisites to using SPF redirect. They are as follows:

It only makes sense when an organization works with multiple domains
All of these domains must share the same email infrastructure
The second domain, which is being redirected, must have a valid SPF record in place
To use SPF redirect, control over all domains participating in the redirect chain must lie with the domain owner

Simplify SPF Redirect with PowerDMARC!

Start 15-day trial Book a demo

How does the SPF Redirect modifier work?

To better understand the functionality of the SPF redirect let’s take a look at the following example:

If domain_test.com has an SPF record such as:
v=spf1 redirect=domain_test2.com

This indicates that the SPF record for “domain_test2.com” should be used instead of “domain_test”. The mails from domain_test would then be redirected using “domain_test2”.

When can you use the SPF redirect modifier?

1. When a single record is to be used for multiple domains

For example,

delaware.example.com. TXT “v=spf1 redirect=_spf.example1.com”
austin.example.com TXT “v=spf1 redirect=_spf.example1.com”
washington.example.com TXT “v=spf1 redirect=_spf.example1.com”
_spf.example.com. TXT “v=spf1 mx:example1.com -all”

In this example, any mail from the above three domains will be described by the same record, in this case, “_spf.example1.com”, which provides users with an administrative advantage.

2. When the name of the domain needs to be altered.

For all mechanisms, “a”, “mx” and “ptr” value is optional. If no specific values are provided, they are set to the current domain. However, when a “redirect” is used, the “a”, “mx”, and “ptr” mechanisms point to the redirected domain.

Consider the following example:
powerdmarc.com “v=spf1 a -all”

Here, the mechanism, “a” has no specified value, so it will then point to the DNS ‘A’ record of “powerdmarc.com” as that is where the SPF record is hosted as specified in the example.

Now, consider the following example:
powerdmarc.com “v=spf1 redirect=_spf.powerdmarc.com”
_spf.powerdmarc.com “v=spf1 a -all”

In the above example, the “a” mechanism points to the DNS ‘A’ record of “_spf.powerdmarc.com”, even though the “powerdmarc.com” root domain redirects it.

This is one of the common causes of validation issues of SPF and is tough to debug. If your organization uses an SPF “redirect”, note that if there exists an “a”, “mx”, or “ptr” mechanism without an explicitly defined domain name in your redirected SPF record, it will only point to the redirected domain.

Disadvantages of using SPF Redirect

1. The “redirect” modifier adds to the number of DNS Lookups

When using SPF email authentication, each time an email is sent from a domain to the recipient’s domain, the recipient’s email server performs DNS query requests, also known as DNS lookups, to check for existing authorized IP addresses in your DNS and compare them to the IP address in the return-path header of the received email. SPF RFC7208 limits the maximum number for these lookups to 10.

A “redirect” modifier, when used, also increases this count. So, your organization must be careful when using a “redirect” modifier, as the 10 DNS lookup limit may be exceeded. This can cause SPF to break and lead to authentication failures.

At PowerDMARC, our users configure PowerSPF which is an effective SPF flattening tool to limit the number of lookups and enjoy error-free SPF.

2. Permerror result is returned for no SPF policy defined in domains using “redirect”

In case you are including a domain that doesn’t contain an SPF record or has an invalid one, a softfail (none) result is returned which doesn’t affect the verification process.

However, while using the SPF redirect modifier if the redirected domain contains an invalid or missing record for SPF, an SPF Permerror result is returned which is a hard fail and can cause SPF to break.

Using the SPF include mechanism instead of the SPF redirect modifier

We recommend using the SPF include mechanism instead of the redirect modifier to evade some common complications, They are as follows:

When a redirect mechanism is used, it denotes the end of the record and no further modifications can be made. On the other hand, if you use an SPF include, you can make modifications to your record and add more includes, a or mx records as per your will, thereby offering more in terms of flexibility.
The include mechanism can help shorten your SPF record so it is under the SPF character length limit. You can create a SPF TXT record each on spfrecord1.xyz.com and spfrecord2.abc.com by splitting the originally single, long SPF record and include both domains in the TXT record for one of the domains (e.g: xyz.com).
In case there is no SPF record found in a redirected domain, the retainment of error state (permerror value) for redirect as mentioned above can also be evaded by using the include mechanism which will return a softfail result instead with your emails still getting delivered.
Unlike SPF include which has no effect on the all mechanism, the SPF redirect modifier intructs the server to render the SPF ~all for the root domain using redirect like in the following case:

domain1.com “v=spf1 redirect=_spf.domain2.com”
_spf.domain2.com “v=spf1 ip4:164.100.226.127 ~all

This is because for any record using redirect, the “all” mechanism is absent in the first place, which may coexist during the usage of include mechanisms. Hence the “~all” set for the redirected subdomain is levied on the root domain as well.

Conclusion

There are many things to be cautious about when using a “redirect” modifier like the 10 DNS Lookup limit, thus, your organization must be careful when setting up your SPF Record. Your organization must optimize the SPF records from time to time ensuring that the DNS lookups are within the limit. For all your organization’s SPF-related queries, check out PowerSPF. It carries out automatic flattening and auto-updates the netblocks to ensure the authorized IPs are always up-to-date and secure. Additionally, you don’t have to worry about permerror or exceeding DNS lookup limits.

The best way to secure your emails with SPF is to implement it with DKIM and free DMARC. This will help in protecting your organization against spam mail and possible spear-phishing attempts. Check out PowerDMARC and ensure your organization is using an active anti-spoofing DMARC technology service provider.

About
Latest Posts

Yunes Tarada

Domain & Email Security Expert at PowerDMARC

Yunes is an Operations Team Lead at PowerDMARC with expert knowledge in email authentication and security. Yunes is a Microsoft-certified Azure Administrator Associate with certifications in CompTIA A+ and many more.

SPF Redirect