SPF `redirect` vs `include`, and common SPF mistakes (multiple SPF TXT records, wrong `all`, bad mechanisms)

include and redirect look similar in SPF records, but they do different jobs.

If you treat them as interchangeable, you can end up with SPF permerror, unexpected results at receivers, or a record that "looks right" while still failing real mail.

This guide explains the practical difference, when to use each one, and the SPF mistakes that break production domains most often.

Quick mental model

Use this short rule:

• include = "also trust this external sender definition"
• redirect = "hand off final SPF evaluation to this other policy"

That sounds subtle, but operationally it is a big difference.

Per RFC 7208, include is a mechanism that recursively evaluates another domain and only matches when that recursive result is pass (section 5.2). By contrast, redirect is a modifier that is only used after mechanisms in the current record do not match, and then the redirected evaluation result becomes the current result (section 6.1).

What include actually does (and does not do)

include does not copy and paste another SPF record into yours.

It asks: "if this host were checked against that other domain's SPF, would it pass?"

If yes, your include mechanism matches. If not, SPF continues evaluating your own record according to your own remaining terms and final policy.

That behavior is exactly why this works:

example.com. IN TXT "v=spf1 include:_spf.provider-a.net include:_spf.provider-b.net -all"

In this pattern, either provider can satisfy SPF for example.com; if neither matches, -all determines the outcome.

Important detail most people miss

The RFC is explicit that include is based on recursive result mapping, not literal inclusion of text. A -all in the included domain does not automatically terminate your parent record. It only contributes to whether the include mechanism matched.

That is a common source of "I thought this should fail earlier" confusion.

What redirect does differently

redirect is for centralizing policy, usually inside one administrative domain.

If your current mechanisms do not match, SPF jumps to the redirect= target and uses that result as if it were your own, with edge-case handling defined by RFC 7208 section 6.1.

Typical pattern:

tx.example.com. IN TXT "v=spf1 redirect=_spf.example.com"
mktg.example.com. IN TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. IN TXT "v=spf1 ip4:198.51.100.10 ip4:198.51.100.11 -all"

This is cleaner than duplicating the same policy in many subdomains.

include vs redirect: when each is right

Use include when:

• authorizing third-party or external sender infrastructure
• combining multiple independent sender ecosystems
• keeping your domain policy control while referencing providers

Use redirect when:

• many domains or subdomains in your organization share one policy
• you want centralized maintenance inside one administrative boundary
• you want one canonical SPF source of truth

RFC 7208 also warns that redirecting to domains you do not administratively control is generally unreliable; for external authorization, include is usually more appropriate.

Common SPF mistakes that cause real failures

1) Publishing multiple SPF records on one domain

This is still one of the most frequent SPF breakages.

SPF selection rules in RFC 7208 section 4.5 say that if more than one v=spf1 record is found, the result is permerror.

That means patterns like this are invalid:

example.com. IN TXT "v=spf1 include:_spf.provider-a.net -all"
example.com. IN TXT "v=spf1 include:_spf.provider-b.net -all"

Correct approach: combine into one SPF TXT record.

2) Mixing all and redirect in the same record

RFC 7208 is explicit here too: if an all mechanism exists, any redirect modifier MUST be ignored.

So this is misleading and effectively not doing what admins expect:

example.com. IN TXT "v=spf1 include:_spf.sender.net -all redirect=_spf.example.com"

The redirect is dead code.

3) Using redirect where include is needed

Admins sometimes redirect a customer domain to an ESP domain. That often creates unpredictable behavior because the redirected domain policy was not built for your sender identity model.

For third-party senders, use include and keep your own terminal policy.

4) Wrong assumptions about ~all vs -all

~all (softfail) and -all (fail) both indicate non-authorized sources in SPF semantics, but receivers can handle them differently operationally.

For modern authenticated mail programs, -all is usually the clearer end state once legitimate senders are fully inventoried. If you are still validating inventory, ~all can be a temporary rollout step.

Either way, remember DMARC success still depends on alignment, not only an SPF pass. See DMARC alignment: From vs Return-Path for the alignment side.

5) Trying to solve architecture problems with one giant SPF record

When one apex-domain SPF record includes every vendor, teams often hit the lookup budget and lose maintainability.

SPF has strict evaluation limits, including the well-known 10 DNS-lookup-causing terms rule. If you are near that edge, review SPF 10 DNS lookup limit explained.

In many cases, subdomain segmentation is cleaner than forcing everything through one top-level record, especially for marketing, support, and platform-generated mail.

Practical safe patterns

Pattern A: Core domain + external providers

example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com include:spf.protection.outlook.com -all"

Why this is safe:

• one SPF record
• clear terminal policy
• external sources authorized via include

Pattern B: Shared internal policy via redirect

alerts.example.com. IN TXT "v=spf1 redirect=_spf.example.com"
billing.example.com. IN TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. IN TXT "v=spf1 ip4:198.51.100.20 ip4:198.51.100.21 -all"

Why this is safe:

• centralized administration
• easy rotation and updates
• consistent policy across subdomains

Pattern C: Hybrid model (common in mature environments)

Use redirect to centralize organization-controlled policy per stream, then include only where third-party infrastructure is truly required.

This usually stays cleaner over time than aggressive flattening. If you are deciding between these approaches, SPF flattening vs includes covers the tradeoffs.

Debug checklist before publishing

Before changing SPF in DNS, validate these points:

1. Exactly one v=spf1 record exists per domain.
2. redirect is not combined with all in the same effective path.
3. Every third-party sender authorization uses the right mechanism (include in most cases).
4. DNS-lookup budget remains within limits after recursive evaluation.
5. DMARC alignment is confirmed for each live sender stream.

Bottom line

include and redirect are not interchangeable SPF syntax options.

Use include to authorize external sender ecosystems. Use redirect to consolidate policy you control. Keep one SPF record per domain, avoid dead combinations like -all plus redirect, and design records around sender architecture rather than quick fixes.

Do that, and most "mysterious SPF failures" stop being mysterious.