SPF include vs redirect - What's the Practical Difference?

If you're comparing SPF include: vs redirect= to decide which mechanism to use in your SPF record, the practical difference is straightforward: include: adds another domain's rules to yours. redirect= replaces your record entirely with another domain's rules.

Most explanations treat them as interchangeable. They aren't and the difference matters more than the documentation suggests. Getting it wrong means your mail passes SPF when it shouldn't, or fails when you expect it to pass. DMARCFlow's DNS health checks catch both failure modes regularly, which tells you how often even experienced admins mix them up.

This guide explains what each mechanism actually does, when to use which, and how to detect the misconfiguration before it breaks your mail.

What include: Does

include: looks up the target domain's SPF record and treats those rules as part of your own. If the target has no SPF record, include: returns a permanent error (permerror) and your SPF check fails mail fails authentication.

It counts toward your 10-DNS-lookup SPF limit. Every include: is one lookup.

A typical use case: you're adding a third-party sender, Salesforce, SendGrid, Mailchimp and you want their sending IPs covered. You add include:sendgrid.net and their rules apply as if written directly in your record:

v=spf1 include:sendgrid.net ~all

If SendGrid removes their SPF record tomorrow, your include:sendgrid.net returns permerror. Your SPF check fails. Your mail doesn't pass SPF and DMARCFlow would flag this in its DNS health checks before you notice the failure in your mail logs.

What redirect= Does

redirect= replaces your record's logic entirely with the target domain's rules. Your record becomes whatever the target record is, at the moment of the check. Your other mechanisms don't apply, the redirect supersedes them.

If the target has no SPF record, redirect= also returns permerror. The difference is in how it handles success:

v=spf1 redirect=_spf.example.com

When this check runs, your record is effectively whatever _spf.example.com says it is. If _spf.example.com is v=spf1 include:_spf.google.com ~all, your SPF check runs those Google rules. Your original mechanisms are discarded.

One important nuance: redirect= itself does not count toward your 10-lookup limit, it's a redirect, not a lookup. But the target record's own include: mechanisms still count. So redirecting to a domain with four includes means four lookups are run against your limit. DMARCFlow's SPF analyzer shows you exactly how many lookups a redirect target will consume.

The Core Difference: Additive vs. Substitutive

Most explanations stop here. Here's the part that actually matters for operational decisions:

• include: is additive. Your record's other mechanisms still apply alongside the included rules.
• redirect= is substitutive. Your entire record is replaced. Nothing else applies unless the target record says otherwise.

# Example 1 — additive (include) v=spf1 include:example.com include:_spf.google.com ~all # Both includes are evaluated. Your ~all still applies as fallback. # Example 2 — substitutive (redirect) v=spf1 redirect=_spf.example.com # The _spf.example.com record IS your SPF record. Anything else in your record is ignored.

This distinction determines which mechanism to use during vendor migrations. When you're adding a vendor without touching your existing rules, include: is the right tool. When you're consolidating multiple domains' SPF into one, redirect= keeps things in sync automatically.

When to Use include:

include: is the right choice when:

• You want to add a third-party sender to your SPF without replacing your existing rules
• You want failure to be visible and loud, if the vendor removes their SPF, your mail fails SPF and you get alerted
• You're extending an existing record rather than consolidating

For most email operators adding SendGrid, Mailgun, or Google Workspace, include: is exactly what you want. It fails safely: the problem becomes obvious immediately. DMARCFlow's DNS health monitoring catches this class of failure automatically, alerting you when a vendor's SPF record disappears and your include: starts returning permerror.

When to Use redirect=

redirect= makes sense when you own the target domain and want a single source of truth:

• You're consolidating example.com and mail.example.com under one SPF policy
• You're migrating legacy domains and want the old record to automatically track the new one
• You want changes to one domain to propagate immediately to all records pointing to it

The tradeoff: redirect= requires discipline. When you change the target record, you change your effective SPF policy immediately. There's no local fallback if the target breaks. DMARCFlow's DNS diagnostics show you the full redirect chain so you can see exactly what your effective SPF policy actually is at any given moment.

How DMARCFlow Detects These Misconfigurations

Both mechanisms fail the same way when the target is missing, permerror and SPF failure. But the operational impact is different, and that's where monitoring matters.

The most common real-world mistakes:

Wrong mechanism in multi-domain setups. During vendor migrations, admins use redirect= where they meant include:, or vice versa. This silently changes which SPF rules apply and can cause unexpected SPF pass or fail results.

Redirecting to non-existent subdomains. Setting redirect=_spf.newdomain.com before _spf.newdomain.com has an SPF record produces an immediate permerror and breaks SPF for the redirecting domain.

Exceeding the 10-lookup limit through chained includes. This is where include: and redirect= interact differently, a redirect doesn't add to your count, but the target's includes still count toward it. DMARCFlow's DNS health checks flag both the mechanism and the lookup count so you can see exactly which mechanism is causing the problem.

DMARCFlow's SPF analyzer catches these issues automatically. Even when you think your SPF record is correct, the subtle difference between include: and redirect= means misconfigurations often go unnoticed until mail starts failing. The analyzer surfaces which mechanism is active, what the target resolves to, and whether your record is approaching the lookup limit, giving you a complete picture of your effective SPF policy before a migration breaks.

FAQ

Does redirect= count toward the 10 SPF lookup limit?
No. A redirect replaces your record, it doesn't add a lookup of its own. But the target record's own include: mechanisms still count. So if you redirect to a domain with four includes, those four lookups apply to your check.

What happens if the target of an include: has no SPF record?
permerror. Your SPF check fails. Mail does not pass SPF authentication.

What happens if the target of a redirect= has no SPF record?
Same result, permerror and SPF failure. Both mechanisms fail hard when the target is absent.

Can I use include: and redirect= in the same record?
You can, but the interaction is tricky. When redirect= is present, it typically replaces the entire record, which means any include: mechanisms in the same record are ignored. The RFC treats redirect= as a terminal action that supersedes other mechanisms.

Which mechanism is better for adding a vendor like SendGrid?
include:. You want to add the vendor's rules to your existing policy, not replace it. Use include:sendgrid.net alongside your existing mechanisms.