SPF include vs redirect: choose composition or policy delegation

Define the decision

The two terms are not interchangeable text shortcuts. An include participates in the current policy’s evaluation; redirect delegates when the current mechanisms do not match. An all mechanism can make a redirect ineffective.

Work through the procedure

1. Write the intended outcome in plain language before changing DNS.
2. Determine whether you are adding a vendor or delegating the whole remaining policy.
3. Evaluate a known authorized IP and a known unauthorized IP against the proposed record.
4. Check nested DNS lookups and the target policy’s ownership.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Intent A: authorize an additional vendor → evaluate an include-based policy
Intent B: keep this domain’s policy controlled by a central domain → evaluate redirect
Review trap: an all mechanism already matches before redirect can apply

Read the result

The correct choice follows the policy ownership model. If a vendor changes its policy, determine which of your sending domains will inherit the effect. Document that dependency instead of treating DNS as a one-time setup.

Check before moving on

1. Test authorized and unauthorized cases.
2. Review whether an earlier mechanism prevents the intended delegation.

Limits and next action

The example is conceptual, not a production record. Use a standards-aware evaluator and the actual provider requirements before publishing.

Source: RFC 7208: include and redirect semantics