What is the main difference between 'include' and 'redirect'?

The include mechanism evaluates another domain's SPF record as an addition to your existing policy, while redirect completely replaces your domain's SPF record with that of the referenced domain.

How many 'include' mechanisms can I have in an SPF record?

You can have as many include mechanisms as you need, but the total number of DNS lookups triggered by your SPF record, including a , mx , ptr , and exists mechanisms, must not exceed 10.

What happens if an 'include' mechanism points to a non-existent or invalid SPF record?

If an include mechanism points to an invalid SPF record or one that causes a DNS lookup error, it will typically result in an SPF PermError for your domain, which can cause legitimate emails to fail authentication.

Does using 'include' or 'redirect' affect DMARC alignment?

Yes, both can affect DMARC alignment. For SPF to align with DMARC, the domain used in the Return-Path (Mail From) header must match the organizational domain of the From header. When using include or redirect , this must still hold true for the SPF check to pass and align.

How can I ensure my SPF record with 'include' mechanisms is correctly configured?

You should use a DMARC monitoring tool like Suped to regularly check your DMARC reports. These reports will show you SPF authentication and alignment results, helping you identify any misconfigurations or issues.

What SPF mechanism refers to another domain's SPF record? - SPF - Email authentication - Knowledge base

Illustration of an email icon with a magnifying glass examining connected servers, representing SPF authentication across domains.

Sender Policy Framework (SPF) is crucial for ensuring legitimate emails reach their intended recipients. It allows domain owners to publish a list of authorized sending servers in their domain's DNS records, helping to prevent email spoofing.

Many organizations rely on third-party services like marketing platforms, CRMs, or transactional email providers to send emails on their behalf. To ensure these services are recognized as legitimate, your domain's SPF record needs a way to refer to their own authorized sending infrastructure.

This is where specific SPF mechanisms come into play, primarily the include mechanism and, in certain situations, the redirect modifier.

The 'include' mechanism

The include mechanism is the most common way to authorize a third-party sender in your SPF record. It tells receiving mail servers to evaluate the SPF record of another domain as part of your domain's policy. For example, if you use Google Workspace for email, you would likely have an include for Google's SPF record.

When an email receiver performs an SPF check, if it encounters an include mechanism, it will temporarily pause evaluating your current record and fetch the SPF record of the included domain. The result of that lookup (pass, fail, softfail, neutral) then contributes to the overall SPF evaluation for your domain.

It is critical to remember the DNS lookup limit for SPF records, which is 10. Each include mechanism (and a, mx, ptr, exists mechanisms) counts towards this limit. Exceeding this limit results in an SPF PermError, causing your emails to potentially fail authentication. Tools like SPF flattening can help manage this by reducing the number of DNS lookups required.

Example SPF record with 'include'txt

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Be mindful of the 10 DNS lookup limit. Each include mechanism consumes one lookup. Exceeding this limit leads to an SPF PermError, which can cause email delivery failures.

The 'redirect' modifier

Less frequently used than include, the redirect modifier functions differently. Instead of adding to your current SPF policy, redirect tells receiving servers to effectively replace your domain's SPF record with the SPF record of another domain. Your own SPF mechanisms are not evaluated at all.

This is typically used in scenarios where a domain completely delegates all its email sending to a single external service. For instance, if example.com sends all its email through a specific email service provider and no other internal servers, it might use a redirect statement.

The key distinction is that redirect passes the entire SPF evaluation responsibility to the target domain, meaning your primary domain's SPF policy is entirely superseded. If you send email from any source other than the redirected domain, those emails will likely fail SPF checks.

Example SPF record with 'redirect'txt

v=spf1 redirect=thirdpartysender.com

When to use 'include' versus 'redirect'

Choosing between include and redirect depends entirely on your email sending setup. Most organizations use multiple email sending services (e.g., one for marketing, one for transactional, one for internal email). In these common scenarios, the include mechanism is the correct choice, allowing you to explicitly authorize each third-party sender.

The redirect modifier is best reserved for highly specific cases where you have truly delegated all email sending for your domain to a single third party. If you maintain any on-premises mail servers, or use multiple SaaS providers, using redirect would be inappropriate and lead to significant email deliverability issues.

Best for multiple senders

Use when you send email through your own servers and/or multiple third-party services.

Policy: Appends to your existing SPF policy.
Evaluation: Receiver evaluates your domain's SPF record, including the referenced domain's.
DNS Lookups: Each include counts towards the 10-lookup limit.

Best for single delegated sender

Use when all email sending for your domain is handled by one specific external service.

Policy: Replaces your entire SPF policy.
Evaluation: Receiver only evaluates the referenced domain's SPF record.
DNS Lookups: Only one DNS lookup for the redirected domain.

Illustration comparing SPF 'include' and 'redirect' mechanisms. One person examines multiple servers (include), another points to a single server (redirect).

Monitoring and managing your SPF record

Maintaining an effective SPF record isn't a set-it-and-forget-it task. Third-party services occasionally change their SPF records, or you might add new sending platforms. Regularly reviewing your SPF configuration is crucial to prevent authentication failures and ensure optimal email deliverability rates.

Robust DMARC monitoring is the best way to keep an eye on your SPF performance. DMARC relies on SPF (and DKIM) authentication to verify legitimate senders and detect spoofing attempts. By analyzing DMARC reports, you can quickly identify if your SPF record, including its include mechanisms, is working as intended.

Suped, we provide a powerful DMARC monitoring platform designed to simplify this process. Our AI-Powered Recommendations tell you exactly how to fix issues and strengthen your policy. You'll receive Real-Time Alerts about any SPF or DMARC failures. Our Unified Platform brings together DMARC, SPF, and DKIM monitoring with blocklist and deliverability insights, making it easy to manage all aspects of your email security. We also offer SPF Flattening to help you avoid the 10-lookup limit. With a generous free plan, Suped makes DMARC accessible and actionable for businesses of all sizes, including MSPs.

Key takeaways

The include mechanism and redirect modifier are powerful tools within SPF that allow domains to authorize external services to send emails on their behalf. Understanding their differences and correct application is fundamental for maintaining a secure and reliable email infrastructure.

Careful configuration and continuous monitoring are key. An accurately configured SPF record, especially one that properly handles third-party senders, significantly boosts your email domain reputation and helps ensure your messages land in the inbox.