Last updated: July 2026

In short: The redirect modifier transfers policy evaluation from your domain to a shared target record. It is designed specifically for consolidating authorizations and policies across multiple domains within a single organization.

If your organization operates numerous domains—such as international country-code domains, brand aliases, or parked domains—maintaining separate, identical SPF (Sender Policy Framework) lists across every DNS zone is inefficient and prone to errors. The redirect modifier solves this problem by centralizing your policy.

How the redirect modifier works

An SPF record using the redirect modifier points evaluation entirely to another domain name:

v=spf1 redirect=_spf.example.com

When a receiving mail server checks your domain and encounters the redirect modifier, it stops checking your current record and evaluates the SPF record published at _spf.example.com. The final outcome produced by that target record—whether pass, fail, softfail, or neutral—is returned directly as the authentication result for your queried domain.

When to use redirect

According to RFC 7208, the redirect modifier is intended for consolidating both authorizations and policy into a common set to be shared within a single administrative domain (ADMD). It makes it possible to control both authorized hosts and policy for an arbitrary number of domains from a single record.

Typical use cases include:

  • Corporate domain portfolios: Directing all secondary brand or regional domains (.de, .fr, .co.uk) to a single centralized SPF record managed under your primary domain (_spf.example.com).
  • Parked domain management: Pointing hundreds of non-sending domains to a single shared policy that rejects all email (v=spf1 -all).

The difference between redirect and include

While redirect and include appear similar, they serve distinct architectural purposes and handle evaluation differently:

Propertyincluderedirect
Primary purposeAuthorizing third-party senders across administrative boundariesConsolidating internal domains within a single organization
Result handlingOnly imports pass; if the target fails, evaluation continues in your recordTransfers evaluation entirely; imports the exact final result including fail or softfail
Record placementCombined with other mechanisms and followed by an all qualifierTypically stands alone and replaces the all qualifier

In summary, include asks, “Does this external record permit this server?” whereas redirect declares, “My domain’s policy is exactly the policy published by that target domain.”

The 10-lookup limit and permerror

Even when using the redirect modifier, you must carefully monitor your DNS lookup budget. Under RFC 7208, the redirect modifier causes a DNS query at evaluation time, just like the include, a, mx, ptr, and exists mechanisms.

Because SPF implementations must limit the total number of those terms to 10 lookups during evaluation, every redirection counts against the limit. If nested redirections or complex target records cause evaluation to exceed 10 lookups, the receiving server immediately returns permerror (permanent error). Furthermore, a domain must not publish multiple separate SPF records, as doing so also triggers an immediate permerror.

Verifying your configuration

To ensure your redirected domains evaluate cleanly without exceeding lookup limits or creating loops, test your configuration using the free MXAudit scanner. It traces the complete redirection chain and flags syntax errors instantly.

For deeper technical documentation and practical walkthroughs across major providers, explore the SPF hub and setup guides like IONOS SPF setup.

Further reading