The Sender Policy Framework (SPF) has several components, and the redirect= modifier is a powerful, yet sometimes misunderstood, part of the specification. In essence, the redirect= modifier allows you to point a domain's SPF check to another domain's SPF record entirely. Instead of listing out all your approved sending IPs and services in one record, you can simply tell receiving mail servers to use the SPF record of a different domain instead.
This means the receiving server stops processing the current SPF record and starts a new evaluation on the record of the domain specified in the redirect. It's a complete delegation of the SPF policy.
How redirect works
When a mail server evaluates the SPF record for your domain and encounters a redirect= modifier, it abandons the current record. It then performs a new SPF lookup on the domain specified in the redirect. The result of that new lookup becomes the final result of the original SPF check.
For example, if the SPF record for example.net is v=spf1 redirect=example.com, the mail server will immediately stop looking at example.net's record and will instead look up and evaluate the SPF record for example.com. Whatever policy is defined there will be applied.
Important Syntax Rules:
- A redirect= must be the absolute last part of an SPF record. Any mechanisms or modifiers that appear after it are ignored.
- A single SPF record can only have one redirect= modifier.
- If a redirect= is present, any all mechanism is ignored, as the policy is determined by the redirected record.
How is redirect= different from include:?
This is the most common point of confusion. While both redirect= and the include: mechanism involve looking up another SPF record, they function very differently.
include: is like a function call. The receiving server pauses processing the current record, evaluates the included record, and if the IP address matches something in the included record, the process stops and returns a Pass. If it doesn't match, the server returns to the original record and continues processing the next mechanism. You can have multiple include: statements for different third-party services.
redirect= is a final destination. As mentioned, it tells the server to completely abandon the current record and use another one instead. The original record is never returned to. Correct syntax is crucial for ensuring this process works as intended.
When should you use redirect=?
The redirect= modifier is most useful for domain management and consolidation. A primary use case is when you manage multiple domains that all send email using the exact same infrastructure. Instead of maintaining identical, complex SPF records on all domains, you can create one master record on a primary domain and simply redirect all your other domains to it. If you ever need to add a new email service, you only have to update one record.
Another scenario is during a company rebrand or acquisition. If oldcompany.com becomes newbrand.com, you can place v=spf1 redirect=newbrand.com on oldcompany.com. This ensures that any lingering email being sent from the old domain is still properly authenticated under the new policy, without having to maintain two separate records.
Potential issues
The main thing to remember is the SPF 10 DNS lookup limit. A redirect= uses one of your 10 lookups. If the record you redirect to is complex and contains many include: mechanisms, you could easily exceed this limit, which results in a PermError and authentication failure. Always be mindful of the complexity of the record you are redirecting to.
What is the purpose of the 'adkim=s' tag in DMARC?
What is the purpose of the 'ptr' SPF mechanism?
What is the significance of the 'v=spf1' tag?
Does the 'redirect' mechanism in SPF count towards the lookup limit?
What is the purpose of the SPF 'a' mechanism?
Does the 'exp' modifier in SPF notify the sender of failures?
