When should I use redirect= instead of include=?

You should use redirect= when you want one domain's SPF policy to completely defer to and replicate another domain's policy. Use include= when you want to add authorized sending sources from another domain to the current domain's existing SPF policy, without replacing it entirely.

Does redirect= count as a DNS lookup?

Yes, using redirect= consumes one DNS lookup. Crucially, the SPF record of the redirected domain is then evaluated, and any mechanisms within that record that require DNS lookups (like a , mx , or include ) will also count towards the overall 10-DNS-lookup limit. This is why SPF flattening can be helpful.

What happens if the redirected domain's SPF record changes?

If the SPF record of the domain specified in redirect= changes, it will immediately affect all domains that redirect to it. This is both a benefit (centralized management) and a potential pitfall if changes are made without proper awareness. Continuous DMARC monitoring can help you detect any negative impacts quickly.

What is the purpose of the 'redirect=' modifier in SPF? - SPF - Email authentication - Knowledge base

An illustration showing an email being redirected from one envelope to another, representing the SPF redirect modifier.

Email authentication protocols like SPF are critical for protecting your domain from spoofing and ensuring your messages reach their intended recipients. When properly configured, an SPF record helps recipient mail servers verify that an incoming email from your domain originates from an authorized server.

Within the SPF specification, various mechanisms and qualifiers define which sending sources are legitimate. Beyond these, SPF also includes modifiers, which provide additional functions. One such modifier that often prompts questions is redirect=.

The core purpose of the redirect= modifier is to instruct a receiving mail server to look up the SPF record of a different domain and use that record for authentication instead of the current one. It essentially hands off the SPF evaluation to another domain's policy.

The primary function of redirect=

When a mail server encounters redirect= in an SPF record, it means that the SPF record of the domain specified after the redirect= modifier should be used for the current domain's SPF check. This is particularly useful when you have multiple domains that need to share the exact same SPF sending policy. Instead of duplicating the entire SPF record for each domain, you can simply redirect them to a central SPF record.

For example, if your primary domain example.com has a complex SPF record, and you want example.net to use the identical policy, you would add a redirect= modifier to the SPF record of example.net. This simplifies management and ensures consistency across your domains. You can learn more about general SPF usage in our guide to SPF, DKIM, and DMARC.

Example SPF record using redirect=dns

example.net. IN TXT "v=spf1 redirect=example.com"

In this example, when a mail server checks the SPF record for example.net, it will be directed to evaluate the SPF record for example.com. The result of example.com's SPF record will then be applied to the email from example.net, effectively delegating the authentication decision. This can be especially helpful if you're managing multiple subdomains or vanity domains.

redirect= vs. include=

It's easy to confuse redirect= with the include= mechanism, but they serve fundamentally different purposes. While both involve referencing another domain's SPF record, their impact on the SPF evaluation process is distinct.

redirect= Modifier

Purpose: Delegates the entire SPF policy to another domain.
Evaluation: The SPF record of the redirected domain completely replaces the current record for evaluation.
Result: The final outcome (pass, fail, softfail) is determined solely by the redirected record.
Placement: redirect= should always be the last term in the SPF record.

include= Mechanism

Purpose: Incorporates authorized sending sources from another domain's SPF record.
Evaluation: The include record's mechanisms are added to the current record's evaluation.
Result: The current domain's SPF record continues to be evaluated, with the include providing an additional set of authorized senders.
Placement: Can appear anywhere before a final mechanism like all.

The key takeaway is that redirect= implies a complete replacement of the SPF policy, while include= is about adding to it. If you use include= with other mechanisms in your SPF record, those mechanisms will still be evaluated. With redirect=, the local record is discarded, and only the redirected record matters. This also means that a redirect= must not appear with other mechanisms or qualifiers, otherwise, it can lead to validation issues and SPF records being ignored.

It's important to note that the SPF specification states that the redirect= modifier should appear as the very last term in an SPF record. If other terms are present after it, they must be ignored by compliant SPF validators, as discussed on Stack Overflow about SPF records. Adhering to this syntax is crucial for reliable email authentication.

Implementing redirect= responsibly

While redirect= offers a powerful way to manage SPF records efficiently, it requires careful implementation to avoid potential issues. A common challenge with SPF is the 10-DNS-lookup limit. Each include=, a, mx, and ptr mechanism in an SPF record consumes a DNS lookup. If a redirected domain's SPF record itself exceeds this limit, or causes the current domain to exceed it, authentication can fail, leading to email delivery problems.

It is important to review the SPF record of the domain you are redirecting to, especially if you want to avoid hitting the 10-DNS-lookup limit. This is where a technique like SPF flattening becomes invaluable, as it can help consolidate multiple lookups into fewer, single IP addresses.

Best practices for redirect=

Verify target record: Always ensure the redirected domain's SPF record is valid and correctly configured.
Monitor DNS lookups: Check the DNS lookup count of the target record. Consider SPF flattening for complex records.
Syntax compliance: Place redirect= as the last term in the SPF record to prevent validation errors.
Review frequently: Any changes to the redirected SPF record will instantly affect all domains using the redirect= modifier. Regular checks are essential for maintaining deliverability.

Google Workspace, for example, highlights the utility of the redirect modifier as a way to use the same SPF content across multiple SPF records for different domains. Always check for specific guidelines related to your email service provider.

Monitoring SPF with DMARC

Even with careful implementation, SPF records can become complex, especially when using modifiers like redirect=. Misconfigurations, or changes to the redirected domain's SPF record, can lead to SPF authentication failures. These failures can then trigger DMARC (Domain-based Message Authentication, Reporting & Conformance) policy actions, potentially causing your legitimate emails to be quarantined or rejected.

This is why DMARC monitoring is not just a best practice but a necessity. DMARC reports provide invaluable insights into your email authentication status, including SPF results. By analyzing these reports, you can identify if your redirect= setup is working as intended or if it's contributing to authentication failures. Platforms like Suped offer comprehensive DMARC monitoring with AI-powered recommendations.

A dashboard displaying various charts and graphs related to email deliverability and DMARC authentication.

DMARC monitoring allows you to see the real-world impact of your SPF configurations. If you notice a high percentage of SPF failures for emails sent from domains using redirect=, it signals a need to investigate the SPF record of the redirected domain. This proactive approach helps maintain optimal email deliverability and protects your domain's reputation from potential blocklisting (or blacklisting).

Key takeaways for SPF redirect=

The redirect= modifier is a powerful tool in SPF for simplifying the management of email authentication across multiple domains, especially when a unified sending policy is desired. By delegating the SPF check to another domain, it reduces redundancy and potential for error in maintaining individual SPF records. However, its effectiveness hinges on precise configuration and continuous monitoring to ensure that the redirected record is valid, within DNS lookup limits, and correctly reflects your authorized sending sources. Leveraging DMARC monitoring tools is crucial to validate its proper functioning and maintain strong email security.