SPF include vs redirect — the Practical Difference

Title: SPF include vs redirect — the Practical Difference

When you set up SPF for a domain that sends email through a third-party provider, you usually add an include: mechanism to your TXT record. Sometimes someone suggests redirect= instead. The names sound similar. The behavior is not.

Here is the practical difference in one sentence.

include: performs a DNS lookup and adopts whatever result the target domain's SPF record returns. redirect= replaces your record's logic entirely with the target domain's SPF record, but only under a specific condition.

That condition matters more than most guides admit.

What include does

include:someservice.com tells receiving mail servers: look up the SPF record for someservice.com, and treat whatever result you get as if it came from your own record. If someservice.com passes SPF, your message passes SPF. If it fails, your message fails. The lookup counts against your own record's 10-lookup limit.

If the target domain has no SPF record at all, the result is none — meaning the check neither passes nor fails. This is one reason include: is considered the safer default. A missing target does not break your record.

What redirect does

redirect=someservice.com says: replace my record's logic entirely with whatever someservice.com's SPF record says. When this activates, your record behaves exactly as if someservice.com's SPF text appeared in your own TXT record.

The critical condition: redirect= only activates when every mechanism in your own record returns none, pass, or softfail. If any mechanism in your record returns hardfail or fail, the redirect is ignored. Your explicit mechanisms stand.

This has a practical consequence many people miss. You cannot safely append redirect= to a record that also contains fail mechanisms and expect it to act as a general-purpose consolidation tool. The redirect will silently do nothing in the cases you probably most want it to work.

Why the difference matters for DNS lookups

include: always performs a DNS lookup — it has to, to retrieve the target domain's result. Each include: in your record counts as one lookup against the RFC-mandated 10-lookup ceiling.

redirect= does not perform a lookup at the point of activation. But what it points to will. If someservice.com's SPF record itself contains 7 lookups, your record effectively has 7 lookups via the redirect.

This means redirect= can help you stay under the 10-lookup limit, but only if the target domain's record is more lookup-efficient than your own. If you are redirecting to a domain that is itself near the limit, your record inherits that problem.

When to use include

Use include: in virtually every normal case. Third-party email services give you an include: mechanism to add. It is the de facto standard for SPF delegation. It works predictably when the target exists and degrades harmlessly when it does not.

When to use redirect

Use redirect= when you control the target domain and are intentionally consolidating multiple services under one domain's SPF record. For example, if you have three third-party services each with their own include:, you can consolidate by setting one domain as your SPF apex and using redirect= from the others to point to it.

Be cautious about redirecting to a domain you do not control. Their SPF changes become your SPF changes without any action on your side. If their record changes unexpectedly, your email authentication changes too.

Common misconfiguration: redirect and fail mechanisms

The most frequent mistake with redirect= is adding it to a record that also contains ~all or -all and expecting it to work as a general override. It will not activate when the ~all or -all is triggered, because those return softfail or fail — and redirect= requires all prior mechanisms to return none, pass, or softfail.

A cleaner pattern: use include: for individual services and keep your ~all or -all as the final mechanism. Use redirect= only when you genuinely want to replace the entire record logic, not just append to it.

How DMARCFlow helps

SPF misconfiguration — whether it is the wrong mechanism, too many lookups, or unexpected redirect behavior — is a direct cause of email authentication failures. When include and redirect behave differently than expected, you need to know before your mail starts bouncing.

DMARCFlow's DNS health check monitors your SPF record for the kinds of problems that cause silent email delivery failures: records approaching the 10-lookup limit, malformed mechanisms, and domains that are about to expire. These are the exact problems that make include and redirect behave differently than expected. Running a DMARCFlow DNS health check before changing your SPF setup tells you whether your current record is clean before you add a new mechanism.

Bottom line

Use include: as your default. It is predictable, degrades safely, and is what third-party services expect you to use. Use redirect= only when you are consolidating multiple services under one domain you control and you understand the trigger condition. In most email setups, you will never need redirect=.

FAQ

Does redirect count as a DNS lookup?
redirect= itself does not add a lookup at activation time. But the record it points to does. If the target domain's SPF record contains 5 lookups, your record via redirect effectively has 5 lookups.

Can I use redirect if my record already has -all?
Only if every mechanism that comes before the redirect returns none, pass, or softfail. If your -all is in the same record, it will trigger first and the redirect will be ignored. In practice, if you are using -all, you should use include: for each service and keep -all as your final mechanism.

What happens if the redirect target does not exist?
A permanent error. Unlike include:, which returns none when the target is missing, redirect= requires a valid SPF record to exist at the target domain. If it does not, the result is a permanent error, which receivers may treat as a failure.

Can include and redirect be used in the same record?
Yes, but the order matters. If redirect= is present, it only activates after all mechanisms above it have returned none, pass, or softfail. Mechanisms below it are irrelevant when redirect activates.