SPF include vs redirect: When to Use Each

SPF's include and redirect mechanisms both reference another domain's SPF record, but they behave differently. include adds another record's mechanisms to your own. redirect replaces your entire SPF evaluation with another domain's record. Using the wrong one can break your email authentication or waste precious DNS lookups.

The Comparison

How include Works

The include mechanism tells the receiving server: "Also check this other domain's SPF record. If it returns a pass, count that as a pass for my record too."

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.5 ~all

In this example, the receiver checks three things in order:

1. Does the sending IP match Google's SPF record?
2. Does the sending IP match SendGrid's SPF record?
3. Does the sending IP match 203.0.113.5?

If none match, the ~all at the end applies. The include mechanism only imports a "pass" result — if the included record returns fail, the evaluation moves to the next mechanism in your record rather than returning fail.

include and DNS Lookups

Each include costs at least one DNS lookup. The included record may contain its own includes, and each of those costs another lookup. You have a hard limit of 10 DNS lookups per SPF evaluation. This is the most common reason SPF records break as organizations add more sending services.

For example:

• include:_spf.google.com = 1 lookup (plus Google's internal lookups, typically 3-4)
• include:sendgrid.net = 1 lookup (plus SendGrid's internal lookups)
• include:spf.protection.outlook.com = 1 lookup (plus Microsoft's internal lookups)

Three includes can easily consume 7-8 of your 10 allowed lookups.

How redirect Works

The redirect modifier tells the receiving server: "If no other mechanisms in this record have matched, use that other domain's SPF record instead of mine for the final evaluation."

v=spf1 redirect=_spf.otherdomain.com

This is fundamentally different from include. With redirect, the other domain's SPF record completely takes over. Its all mechanism becomes your all mechanism. Your own record is effectively replaced.

redirect Rules

• Only one redirect per record. Multiple redirects are not allowed.
• redirect is a modifier, not a mechanism. It does not have a qualifier (+, -, ~, ?) in front of it. It uses = instead of :.
• It is evaluated last. If any mechanism in your record matches first, the redirect is never reached.
• Your all mechanism is ignored. The target record's all applies instead. If you include both redirect= and -all in the same record, the -all takes precedence and the redirect is never evaluated.

When to Use include

Use include in most cases. It is the standard way to authorize third-party senders:

• Adding email service providers. Google Workspace, Microsoft 365, SendGrid, Mailgun, Amazon SES — all provide include values for their SPF records.
• Multiple sending sources. When you have several authorized senders, include lets you list them all alongside your own IP addresses.
• Keeping control of your policy. With include, your all mechanism still applies. You decide what happens with unmatched senders.

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:amazonses.com ~all

When to Use redirect

Use redirect when you want to delegate your SPF policy entirely to another domain:

• Subdomains pointing to the parent. If mail.example.com should use the same SPF policy as example.com, redirect is cleaner than duplicating the record.
• Managed DNS with a centralized SPF. Some organizations maintain a single SPF record on a dedicated subdomain (like _spf.example.com) and point all their domains to it with redirect.
• Domain aliases. If you own multiple domains that all send from the same infrastructure, each alias domain can redirect to a single authoritative SPF record.

v=spf1 redirect=_spf.example.com

Common Mistakes

Mixing redirect with other mechanisms

v=spf1 include:_spf.google.com redirect=_spf.example.com ~all

This is problematic. The ~all at the end will match before the redirect is evaluated, making the redirect useless. If you want to use redirect, it should be the only directive in your record (besides v=spf1).

Using redirect when you mean include

v=spf1 redirect=_spf.google.com

This makes Google's entire SPF policy yours, including their all mechanism. If Google changes their SPF record, your policy changes too — including the fail behavior. For most domains, include:_spf.google.com ~all is what you actually want.

Multiple redirects

v=spf1 redirect=_spf.google.com redirect=sendgrid.net

Only one redirect is allowed. The second one is undefined behavior — some receivers may ignore the record entirely. Use include when you need to reference multiple domains.

Lookup Cost Comparison

Both include and redirect cost DNS lookups, but the accounting is slightly different:

• include: 1 lookup for the include itself, plus any lookups within the included record. Multiple includes multiply this cost.
• redirect: 1 lookup for the redirect target, plus any lookups within the target record. But since you can only have one redirect and no other lookup-generating mechanisms, the total is usually lower.

If you are bumping up against the 10-lookup limit, redirect can be more efficient for consolidation. But the real solution is usually to flatten your includes or reduce the number of authorized senders. Don't forget to pair your SPF record with DKIM and DMARC for complete email authentication.

Bottom Line

Use include when adding third-party senders to your existing SPF record. It is the standard approach and gives you full control over your policy. Use redirect only when delegating your entire SPF policy to another domain — subdomains pointing to a parent, or alias domains sharing infrastructure. Never mix redirect with other mechanisms or an all qualifier in the same record. Once your record is published, verify it with SPF Record Check to confirm your includes resolve correctly.

Monitor Your New SPF Record

You've created your SPF record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.