SPF Redirect vs Include: When to Use the Redirect Modifier

If you have looked at SPF records, you have probably seen the include mechanism many times. But there is another directive that looks similar and causes a lot of confusion: the redirect modifier. Both reference another domain's SPF record, but they work very differently. Using the wrong one — or combining them incorrectly — can break your email authentication.

This guide explains what the redirect modifier does, how it differs from include, and when each one is the right choice. For a comprehensive overview of SPF syntax, see our complete SPF guide.

What the Redirect Modifier Does

The redirect modifier tells receiving mail servers: "Do not use this domain's SPF record. Instead, use the SPF record published at this other domain."

Here is the syntax:

v=spf1 redirect=_spf.parentcompany.com

When a receiving server evaluates this record, it completely replaces the current SPF evaluation with the record found at _spf.parentcompany.com. Whatever result that record returns — pass, fail, softfail, neutral — becomes the result for the original domain.

Think of it like a forwarding address. Instead of having its own list of authorized senders, the domain says, "Go check over there instead."

How Redirect Differs from Include

This is the critical distinction that trips people up. Both redirect and include reference another domain's SPF record, but they behave very differently:

Include checks the referenced domain's SPF record as part of the evaluation. If it returns "pass," the overall result is "pass." If it does not match, the evaluation continues with the next mechanism in the record. Include is one check among many.

Redirect replaces the entire evaluation. There is no "continuing with the next mechanism." The referenced domain's SPF record becomes the authoritative record, period.

The Most Important Rule About Redirect

Here is the rule that catches most people off guard: if any mechanism in the SPF record matches before the redirect, the redirect is never evaluated.

The SPF specification (RFC 7208) says that the redirect modifier is only used if no other mechanism in the record produces a match. This means you cannot effectively combine redirect with include or other mechanisms that might match.

For example, this record is problematic:

v=spf1 include:_spf.google.com redirect=_spf.parentcompany.com

If the sending IP matches something in Google's SPF record, the result is "pass" and the redirect is never checked. If Google's record does not match, the redirect takes over. This creates unpredictable behavior — some emails follow Google's rules, others follow the parent company's rules.

When to Use Redirect

The redirect modifier is useful in one specific scenario: centralizing SPF management across multiple domains.

Imagine a parent company that owns several brands, all using the same email infrastructure. Instead of maintaining separate SPF records for each domain (and updating all of them whenever the infrastructure changes), the company can publish one master SPF record and point all domains to it.

The master record (published at _spf.parentcompany.com):

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.mtasv.net ~all

Brand domain 1 (brand-one.com):

v=spf1 redirect=_spf.parentcompany.com

Brand domain 2 (brand-two.com):

v=spf1 redirect=_spf.parentcompany.com

Brand domain 3 (brand-three.com):

v=spf1 redirect=_spf.parentcompany.com

Now, when the company adds a new email service or changes providers, they only update the master record at _spf.parentcompany.com. All brand domains automatically pick up the change. This is cleaner and less error-prone than maintaining identical SPF records across a dozen domains.

If you manage SPF for multiple domains, our guide on SPF for multiple ESPs covers additional strategies.

When to Use Include Instead

For the vast majority of businesses, include is the right choice. Use include when:

• You are adding a third-party email service (Google Workspace, Mailchimp, SendGrid, etc.)
• You need to authorize multiple independent services
• You want to combine several sources in one SPF record
• You are following setup instructions from an email service provider

In fact, if you are reading this because an email provider told you to add their SPF information, they almost certainly mean you should use include, not redirect. Setup guides from services like Postmark, SendGrid, and Mailchimp all use include.

Redirect Syntax Details

The redirect modifier has a few syntax rules to keep in mind:

Correct syntax:

v=spf1 redirect=_spf.example.com

Note that redirect uses = (equals sign), not : (colon). This is different from mechanisms like include:domain.com which use a colon.

The redirect must point to a domain that has an SPF record. If the target domain does not publish an SPF record, the result is a PermError, which is treated as an authentication failure.

Only one redirect per record. Having multiple redirects is invalid.

Redirect and the all mechanism. If your record has a redirect, you should not include an all mechanism. The all mechanism always matches, which means it would match before the redirect is evaluated, making the redirect pointless. A redirect record should look like:

v=spf1 redirect=_spf.example.com

Not:

v=spf1 redirect=_spf.example.com ~all

Common Redirect Mistakes

Mixing redirect with include

As discussed above, combining redirect with mechanisms that might match creates unpredictable behavior. If you need both your own authorized sources and a reference to another domain, use include for everything.

Pointing redirect to a domain without an SPF record

If the target domain does not publish an SPF record, the result is a PermError. Always verify that the redirect target has a valid SPF record.

Using redirect when include is needed

If an email service provider tells you to "add their SPF record," they mean use include. Redirect is for centralized management, not for adding a service to your existing authentication.

Forgetting that redirect replaces everything

If you switch from include to redirect, you are replacing your entire SPF policy with another domain's. Make sure the target record authorizes all the services you need, not just some of them.

Checking Your SPF Record

Whether you use include, redirect, or both across different domains, regularly checking your SPF records helps catch issues before they affect deliverability. If you manage SPF for multiple domains, consider periodic SPF audits. Use the lookup tool above to verify your record is valid, check your DKIM configuration, and make sure you have a DMARC record in place.

For ongoing monitoring across all your domains, the Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.

References

• RFC 7208: Sender Policy Framework (SPF) — The current SPF specification, including redirect modifier behavior