SPF redirect delegates the remaining authorisation decision to another policy. It is designed for situations where several domains should share centrally managed authorisation and policy, often within one administrative organisation.
It is not an alias for include and is not a backup after -all. Understanding when redirect runs is essential before consolidating records. RFC 7208 section 6.1 defines its behaviour.
Establish the delegation condition
When no mechanism matches, no earlier error has terminated evaluation, and redirect is present, SPF evaluates the redirect target. The connecting IP and sender stay the same, while the domain under evaluation becomes the target. The resulting evaluation supplies the result, with missing SPF at the target becoming permerror rather than none.
If any all mechanism is present in the outer record, redirect is ignored. The placement of redirect before all does not rescue it. Write redirect at the end for clarity, but remember that it is a modifier rather than a left-to-right matching mechanism.
A local mechanism can precede delegation. For example, an explicit ip4 permission can match before the shared policy is consulted. Decide whether such exceptions are intended; otherwise a supposedly central policy may not be the whole authorisation story.
Worked example: two domains, one managed policy
Assuming valid syntax, one selected SPF record per name and successful DNS retrieval, in this synthetic fixture, east.example.com and west.example.com each publish v=spf1 redirect=policy.example.com. The shared target publishes v=spf1 ip4:192.0.2.30 -all.
For 192.0.2.30, each outer policy delegates, the target ip4 matches and the result is pass. For 192.0.2.31, the target reaches -all and the delegated result is fail. If the target TXT record disappears, evaluations requiring the redirect produce permerror.
Now change the east policy to v=spf1 ip4:198.51.100.8 redirect=policy.example.com. That additional address passes locally, even though the shared target does not authorise it. A central-policy audit must therefore read every delegating record rather than reviewing only the target.
Compare the same target under include
If the outer policy instead contains v=spf1 include:policy.example.com ~all, a child pass matches the include. A child fail does not supply the final result; processing resumes and the outer ~all produces softfail.
Redirect carries the target policy outcome when invoked. Include asks whether the target passes and then continues under the outer policy when it does not. Choose the construction that matches the ownership model instead of translating between them mechanically.
Audit context-sensitive rules
Redirect changes the current evaluation domain while retaining the sender input. Macros and domain-relative mechanisms can therefore depend on which domain or sender value they use. A policy that works for one domain is not automatically safe for another.
For a third-party sending service, use the integration mechanism its current documentation supports. RFC 7208 cautions that redirect across administrative boundaries may not behave reliably, especially when target policy depends on local parts. Do not replace a documented include with redirect merely to shorten the visible record.
Operate the shared policy safely
Inventory all dependent domains and local exceptions. Assign one accountable owner to the shared target. Before changing it, test a permitted and an unpermitted sender for each distinct policy context, including IPv6 where used. Retain the original delegating and shared records together.
Under RFC 7208 §4.1 and RFC 7208 §4.6.4, redirect and reached nested terms consume the SPF DNS term budget. Detect loops and dependency growth through evaluation rather than relying on the short length of each local record. After a change, inspect authoritative and recursive answers and test representative received mail.
The practical takeaway
Redirect is useful centralisation when you truly want shared policy. Keep all out of the delegating record, audit local exceptions and test the sender context that survives the delegation.
Keep the decision reproducible
For east.example.com, the local 198.51.100.8 exception passes without invoking the shared target; a shared-target outage therefore need not affect that exact path. A different source requiring redirect can encounter the target error. Record the outer record, sender input, reached target and expected result together before approving centralization. No shared-policy change or outage test was performed.