SPF redirect modifier

What is the SPF redirect modifier?

redirect= is an SPF modifier, not a mechanism. It tells a receiving mail server to stop evaluating the current SPF record and instead use the SPF record published by the domain named in the modifier — but only if no mechanism in the current record has already matched the sending IP.

A redirect modifier looks like this:

redirect=_spf.example.com

This tells receivers: if the current record has no matching mechanism for this sending IP, evaluate _spf.example.com's SPF record and use its result as the outcome for the original domain.

redirect= is distinct from include:. An include mechanism evaluates another domain's SPF record as one check within your existing record and moves on if it does not match. redirect= replaces the entire result of your record when no mechanism has already matched — it does not add a check, it delegates the full decision.

How redirect= works in SPF

SPF evaluation processes mechanisms in the order they appear in the record. If a mechanism matches the sending IP, evaluation stops and the qualifier for that mechanism determines the result.

redirect= is only evaluated when no mechanism in the current SPF record has matched the sending IP. At that point, the receiver evaluates the SPF record of the domain specified by redirect=. The result of that evaluation — Pass, Fail, SoftFail, Neutral, PermError, or TempError — becomes the result for the original domain.

There can only be one redirect= modifier in an SPF record. If a record contains a redirect= modifier and also an all mechanism, the all mechanism matches every sending IP and prevents redirect= from ever being reached. When both are present, the all mechanism governs the result and redirect= is ignored.

redirect= should appear at the end of the SPF record, or as the only term after v=spf1. Any mechanisms listed before it are still evaluated normally.

When to use redirect=

redirect= is most useful when you want to centralise SPF policy across multiple domains. For example, if you own example.com, example.net, and example.org, and all three send mail from the same servers, you can publish one authoritative SPF record at _spf.example.com and redirect the other domains to it:

example.net: v=spf1 redirect=_spf.example.com
example.org: v=spf1 redirect=_spf.example.com

This means you only maintain one SPF record. Any change to the central record applies automatically to every domain that redirects to it.

redirect= is not appropriate for authorising a single third-party sender alongside your existing policy. Use include: for that. redirect= is for full policy delegation when no domain-specific mechanisms are needed.

SPF redirect vs include

redirect= and include: are often confused but behave very differently.

include: evaluates another domain's SPF record as one mechanism within your record. If the sending IP matches a rule in the included domain's record, the include passes. If it does not match, evaluation moves on to the next mechanism in your record. You can have multiple include: mechanisms in a single SPF record.

redirect= replaces the outcome of your record with the result of another domain's SPF evaluation, but only when no mechanism in the current record has matched. There can only be one redirect= per SPF record, and it is a modifier, not a mechanism.

Use include: when you want to add a third-party sender to your existing policy. Use redirect= when you want to delegate the entire SPF policy for a domain to a central record, with no domain-specific overrides needed.

What happens when the redirected SPF record passes or fails

When redirect= is evaluated, the receiver looks up the SPF record of the domain named in the modifier and evaluates it against the sending IP.

If the redirected domain's SPF record results in a Pass for the sending IP, the overall SPF result for the original domain is Pass.

If the redirected domain's SPF record does not match the sending IP, the result returned by the redirected record — including whatever its all mechanism returns — becomes the result for the original domain.

If the redirected domain has no SPF record at all, or if that record has a syntax error or cannot be retrieved, the result is PermError for the original domain. Receivers that treat PermError as a hard failure will reject or quarantine the message.

Common SPF redirect mistakes

Redirecting to a domain with no SPF record. If the target domain does not publish a valid SPF record, redirect= causes PermError. Always verify the target domain has a working SPF record before publishing a redirect= modifier.

Using redirect= and all in the same record. An all mechanism matches every sending IP. If redirect= and an all mechanism both appear in the same record, the all mechanism is always reached first, and redirect= is never evaluated.

Using redirect= instead of include: for third-party senders. redirect= is not the right tool for adding a single third-party sender. It delegates the entire SPF decision. Use include: for individual third-party services.

Adding more than one redirect= modifier. Only one redirect= is permitted per SPF record. Multiple redirect= modifiers result in SPF PermError.

Expecting redirect= to override mechanisms. redirect= is only reached when no mechanism has matched. Any mechanism earlier in the record that matches the sending IP will produce its result and prevent redirect= from being evaluated.

How redirect affects SPF errors and DNS lookups

The redirected domain's SPF record is evaluated in full, and all DNS lookups it requires count toward the 10-lookup limit that applies to SPF evaluation.

If the redirected domain's SPF record contains multiple include mechanisms, those lookups accumulate as part of the evaluation for the original domain. If the redirected record exceeds the 10-lookup limit on its own, the result is PermError for the original domain.

If the redirected domain's SPF record produces PermError for any reason — a missing included domain, a syntax error, or exceeding the lookup limit — that PermError propagates as the result for the original domain.

Keeping the redirected domain's SPF record healthy and within the lookup limit is critical for every domain that uses redirect= to delegate to it.

How to fix SPF redirect problems

Verify the target domain has a valid SPF record. Before publishing a redirect= modifier, confirm the named domain publishes a valid SPF record. Use the MXFend SPF Checker to evaluate it.

Remove any all mechanism from the redirecting record. If the record contains both redirect= and an all mechanism, the all mechanism will prevent redirect= from being evaluated. Remove the all mechanism or reconsider the design.

Ensure only one redirect= modifier is present. Check for duplicate redirect= modifiers and remove any extras.

Monitor the redirected domain's SPF record. Because SPF evaluation is fully delegated, changes to the target record affect every domain redirecting to it. Monitor it and verify it remains valid.

Test after every change. Use an SPF checker to confirm the redirecting domain resolves correctly and that the target domain's record is valid and within the DNS lookup limit.

How MXFend can help

SPF Checker — evaluates your SPF record, follows redirect= modifiers, counts DNS lookups, and flags PermError conditions, missing or broken redirected records, and lookup limit violations.

Email Security Score — provides a combined audit of SPF, DKIM, DMARC, blacklist, SMTP TLS, MTA-STS, TLS-RPT, MX, and BIMI in a single weighted report.

DMARC Checker — checks whether your DMARC policy is published and correctly aligned with your SPF and DKIM setup.

DKIM Checker — validates DKIM selectors and public key records for the domain. DKIM alignment alongside SPF is required for DMARC to pass.