What's the difference between SPF include and redirect?

include: adds another SPF record's authorizations to yours while keeping your own qualifier (the ~all or -all at the end). redirect= replaces your entire SPF policy with the target's, including their qualifier. Multiple include: mechanisms are allowed; only one redirect= per record.

When should I use SPF redirect?

When a third party fully manages your email sending and you want to delegate SPF policy to them entirely. Example: a brand parked at a fully managed mail host might use `v=spf1 redirect=hostingprovider.com`. Rare in practice — most senders want some control and use include: instead.

Does SPF redirect count toward the 10-lookup limit?

Yes. redirect= counts as one lookup just like include:. If the redirected record itself contains include:, those add to the total. Redirect doesn't save lookups; it changes the semantic relationship between your policy and the target's.

Can I use both include and redirect in the same SPF record?

Yes, but the redirect only applies if no other mechanism matches first. The order is: evaluate all mechanisms (a, mx, ip4, ip6, exists, include) in order, then if none matched and a redirect= modifier exists, follow it. Mixing them is uncommon and usually a sign of misunderstanding.

Why do most senders use include instead of redirect?

Because senders want to authorize multiple sources and keep their own policy qualifier (~all or -all). include: adds a source. redirect= replaces the entire policy. If you use multiple ESPs (Google + SendGrid + Mailchimp), you need multiple includes — you can't redirect to all three.

SPF include vs redirect: Which to Use

SPF has two mechanisms that reference other records: include: and the redirect= modifier. Most senders only need include:. Redirect is a less common pattern for setups where someone else fully manages your email. This guide covers the difference, when each is appropriate, and how they interact with the 10-lookup limit.

If you're confused which to use, the answer is almost certainly include:.

What include does

include: adds another domain's SPF authorizations to your own. The qualifier (~all or -all) at the end of your record still controls your overall policy. The included record's qualifier is ignored.

acme.com.  TXT  "v=spf1 include:sendgrid.net include:_spf.google.com ~all"

When SPF evaluates this for an inbound message:

Look up sendgrid.net SPF record, check if sending IP matches its authorizations
If yes, treat as match (continue to your qualifier)
If no, look up _spf.google.com, check if sending IP matches
If yes, treat as match
If no match anywhere, apply your ~all qualifier (softfail)

What redirect does

redirect= replaces your entire SPF policy with another domain's. Your qualifier is ignored; the target's qualifier applies.

acme.com.  TXT  "v=spf1 redirect=hostingprovider.com"

hostingprovider.com.  TXT  "v=spf1 ip4:192.0.2.0/24 -all"

When SPF evaluates this:

See no other matching mechanisms in acme.com's record
Follow redirect to hostingprovider.com
Apply hostingprovider.com's full policy, including its -all qualifier

Functionally, your domain's SPF behaves identically to hostingprovider.com's.

When include is right

Almost every modern sender. Specifically:

Multiple ESPs — Google Workspace + SendGrid + Mailchimp
Self-hosted plus ESP — your Postfix relay plus a marketing ESP
Wanting your own qualifier — you want -all or ~all to be your decision
Wanting to retain visibility — your SPF record clearly lists your authorized sources

For the multi-provider pattern, see SPF multiple providers.

When redirect is right

Niche scenarios:

Fully managed hosting where a third party handles all your mail and you have no other senders
Brand-protection domains that should follow a centralized SPF policy across your brand portfolio
Subsidiaries inheriting parent company policy in a large org
Failover or migration during a brief transition period

For most senders, redirect is unnecessary complexity.

Lookup counting

Both include: and redirect= consume DNS lookups against the 10-lookup limit.

Mechanism	Direct lookups	Nested
`include:provider.com`	1	Plus any in provider.com's record
`redirect=target.com`	1	Plus any in target.com's record
`mx`	1	Plus 1 per MX host
`a`	1	Plus 1 if specified hostname needs A lookup
`ip4:`, `ip6:`	0	N/A
`exists:`	1	N/A

Redirect doesn't reduce lookup cost compared to include. It changes semantic meaning, not efficiency.

Practitioner note: I've seen senders try to use redirect to "save lookups" when they're approaching the 10-lookup limit. It doesn't work — the redirected record's lookups still count. The right fix at the lookup limit is SPF flattening or splitting senders across subdomains. See SPF multiple providers for the flattening pattern.

Common include patterns

The canonical includes for major providers:

; Single ESP
v=spf1 include:sendgrid.net ~all

; Multiple ESPs
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ~all

; Self-hosted + ESP
v=spf1 mx include:sendgrid.net ~all

; Self-hosted only
v=spf1 mx ~all

; Strict policy for parked domain
v=spf1 -all

For the foundational SPF concepts, see the SPF setup guide.

Common redirect mistakes

Using redirect with other mechanisms when you actually want include. If you have v=spf1 include:sendgrid.net redirect=other.com ~all, the redirect is ignored because other mechanisms exist (and ~all further makes redirect moot). Use one or the other.
Redirecting to a domain that disappears. If the target domain loses its SPF record, your SPF returns permerror. Include is no better here, but the failure is more visible because include is named for each provider.
Redirect chain. A redirects to B which redirects to C. Each adds a lookup. Easy to exceed 10.
Forgetting your qualifier doesn't apply. Setting ~all on a record that redirects is meaningless — the target's qualifier controls.

Syntax notes

include: and redirect= are syntactically different. Include is a mechanism; redirect is a modifier. Modifiers don't have qualifiers and come at the end of the record.

; Correct
v=spf1 include:provider.com ~all

; Correct
v=spf1 redirect=target.com

; Incorrect (redirect is a modifier, doesn't take a qualifier)
v=spf1 -redirect=target.com

When to use exists or ptr

Two other rare mechanisms:

exists: — useful for dynamic policies based on DNS resolution. Niche.
ptr: — deprecated by RFC 7208. Don't use it. Many receivers refuse to evaluate it.

For a typical sender, the mechanisms you'll use are include:, mx, a, ip4:, and ip6:. Skip everything else.

A decision tree

Do I use one or more cloud ESPs? → include: each
Do I self-host and use ESPs? → mx + include:
Does a third party fully manage all my mail and I want no own policy? → redirect=
Does my domain send no mail? → v=spf1 -all and DMARC reject

For DMARC on no-mail domains, see DMARC for parked domains.

If you're sorting out SPF mechanics for a multi-provider setup or trying to choose between include and redirect for a hosted-mail situation, book a consultation. I do SPF audits for senders combining self-hosted and cloud providers.

Sources

RFC 7208 — SPF — IETF
MXToolbox SPF mechanism reference — MXToolbox
Cloudflare SPF record reference — Cloudflare
Google Workspace SPF documentation — Google
Microsoft 365 SPF setup — Microsoft

v1.0 · May 2026