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!

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

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 has an SPF record such as:

This indicates that the SPF record for “” 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, TXT “v=spf1” TXT “v=spf1” TXT “v=spf1” TXT “v=spf1 -all”

In this example, any mail from the above three domains will be described by the same record, in this case, “”, 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:             “v=spf1 a -all”

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

Now, consider the following example:             “v=spf1”     “v=spf1 a -all”

In the above example, the “a” mechanism points to the DNS ‘A’ record of “”, even though the “” 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 and by splitting the originally single, long SPF record and include both domains in the TXT record for one of the domains (e.g:
  • 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:            “v=spf1”    “v=spf1 ip4: ~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.


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.

In this article, we will explore how to optimize SPF record easily for your domain. For enterprises as well as small businesses who are in possession of an email domain for sending and receiving messages among their clients, partners and employees, it is highly probable that an SPF record exists by default, which has been set up by your inbox service provider. No matter if you have a pre-existent SPF record or you need to create a new one, you need to optimize your SPF record correctly for your domain in order to ensure that it causes no email delivery issues.

Some email recipients strictly require SPF, which indicates that if you do not have an SPF record published for your domain your emails may be marked as spam in your receiver’s inbox. Moreover, SPF helps in detecting unauthorized sources sending emails on behalf of your domain.

Let us first understand what is SPF and why do you need it?

Sender Policy Framework (SPF)

SPF is essentially a standard email authentication protocol that specifies the IP addresses that are authorized to send emails from your domain. It operates by comparing sender addresses against the list of authorized sending hosts and IP addresses for a specific domain that is published in the DNS for that domain.

SPF, along with DMARC (Domain-based Message Authentication, Reporting and Conformance) is designed to detect forged sender addresses during email delivery and prevent spoofing attacks, phishing, and email scams.

It is important to know that although the default SPF integrated into your domain by your hosting provider ensures that emails sent from your domain are authenticated against SPF if you have multiple third-party vendors to send emails from your domain, this pre-existent SPF record needs to be tailored and modified to suit your requirements. How can you do that? Let’s explore two of the most common ways:

  • Creating a brand new SPF record
  • Optimizing an existing SPF record

Instructions on How to Optimize SPF Record

Create a Brand New SPF Record

Creating an SPF record is simply publishing a TXT record in your domain’s DNS to configure SPF for your domain. This is a mandatory step that comes before you start on how to optimize SPF record. If you are just starting out with authentication and unsure about the syntax, you can use our free online SPF record generator to create an SPF record for your domain.

An SPF record entry with a correct syntax will look something like this:

v=spf1  ip4:38.146.237 -all

v=spf1Specifies the version of SPF being used
ip4/ip6This mechanism specifies the valid IP addresses that are authorized to send emails from your domain.
includeThis mechanism tells the receiving servers to include the values for the SPF record of the specified domain.
-allThis mechanism specifies that emails that are not SPF compliant would be rejected. This is the recommended tag you can use while publishing your SPF record. However it can be replaced with ~ for SPF Soft Fail (non-compliant emails would be marked as soft fail but would still be accepted) Or + which specifies that any and every server would be allowed to send emails on behalf of your domain, which is strongly discouraged.

If you already have SPF configured for your domain, you can also use our free SPF record checker to lookup and validate your SPF record and detect issues.

Common Challenges and Errors while Configuring SPF

1) 10 DNS Lookup limit 

The most common challenge faced by domain owners while configuring and adopting SPF authentication protocol for their domain, is that SPF comes with a limit on the number of DNS lookups, which cannot exceed 10. For domains relying on multiple third-party vendors, the 10 DNS lookup limit exceeds easily which in turn breaks SPF and returns an SPF PermError. The receiving server in such cases automatically invalidates your SPF record and blocks it.

Mechanisms that initiate DNS lookups: MX, A, INCLUDE, REDIRECT modifier

2) SPF Void Lookup 

Void lookups refer to DNS lookups which either return NOERROR response or NXDOMAIN response (void answer). While implementing SPF it is recommended to ensure DNS lookups do not return a void answer in the first place.

3) SPF Recursive loop

This error indicates that the SPF record for your specified domain contains recursive issues with one or more of the INCLUDE mechanisms. This takes place when one of the domains specified in the INCLUDE tag contains a domain whose SPF record contains the INCLUDE tag of the original domain. This leads to a never-ending loop causing email servers to continuously perform DNS lookups for the SPF records. This ultimately leads to exceeding the 10 DNS lookup limit, resulting in emails failing SPF.

4) Syntax Errors 

An SPF record may exist in your domain’s DNS, but it is of no use if it contains syntax errors. If your SPF TXT record contains unnecessary white spaces while typing the domain name or mechanism name, the string preceding the extra space would be completely ignored by the receiving server while performing a lookup, thereby invalidating the SPF record.

5) Multiple SPF records for the same domain

A single domain can have only one SPF TXT entry in the DNS. If your domain contains more than one SPF record, the receiving server invalidates all of them, causing emails to fail SPF.

6) Length of the SPF record 

The maximum length of a SPF record in the DNS is limited to 255 characters. However, this limit can be exceeded and a TXT record for SPF can contain multiple strings concatenated together, but not beyond a limit of 512 characters, to fit the DNS query response (according to RFC 4408). Though this was later revised, recipients relying on older DNS versions would not be able to validate emails sent from domains containing a lengthy SPF record.

Optimizing your SPF Record

In order to promptly modify your SPF record you can use the following SPF best practices:

  • Try typing down your email sources in decreasing order of importance from left to right in your SPF record
  • Remove obsolete email sources from your DNS
  • Use IP4/IP6 mechanisms instead of A and MX
  • Keep your number of INCLUDE mechanisms as low as possible and avoid nested includes
  • Do not publish more than one SPF record for the same domain in your DNS
  • Make sure your SPF record doesn’t contain any redundant white spaces or syntax errors

Note: SPF flattening is not recommended since it isn’t a one-time deal. If your email service provider changes their infrastructure, you’re going to have to change your SPF records accordingly, every single time.

Optimizing Your SPF Record Made Easy with PowerSPF

You can go ahead and try implementing all those above-mentioned modifications to optimize your SPF record manually, or you can forget the hassle and rely on our dynamic PowerSPF to do all that for you automatically! PowerSPF helps you optimize your SPF record with a single click, wherein you can:

  • Add or remove sending sources with ease
  • Update records easily without having to manually make changes to your DNS
  • Get an optimized auto SPF record with the single click of a button
  • Stay under the 10 DNS lookup limit at all time
  • Successfully mitigate PermError
  • Forget about SPF record syntax errors and configuration issues
  • We take away the burden of resolving SPF limitations on your behalf

Sign up with PowerDMARC today to bid adieu to SPF limitations forever!