Sender Policy Framework (SPF) is a fundamental email authentication protocol designed to prevent email spoofing. It allows a domain owner to specify which mail servers are authorized to send email on behalf of their domain. When a receiving mail server gets an email, it performs an SPF check to verify that the email's origin is legitimate.
A common point of confusion arises when determining exactly against which domain this check is performed. Is it the visible 'From' address, or another hidden address in the email header? Understanding this distinction is crucial for effective email authentication and to ensure your legitimate emails reach the inbox.
To fully grasp how SPF checks work, it is important to differentiate between two key email addresses within an email's structure. These are the RFC 5322.From (also known as the 'Header From' address) and the RFC 5321.MailFrom (often called the 'Envelope From' or 'Return-Path' address).
The RFC 5322.From address is what recipients typically see in their email client, representing the sender of the message. This is the friendly 'From' address. Conversely, the RFC 5321.MailFrom address is used during the SMTP (Simple Mail Transfer Protocol) transaction. It is often hidden from the end-user and is primarily used for bounce messages and SPF checks.
Attribute
Description
Role in SPF
RFC 5322.From (Header From)
The visible 'From' address in your email client, e.g., info@yourdomain.com.
Not directly checked by standard SPF. Used for DMARC alignment.
RFC 5321.MailFrom (Envelope From / Return-Path)
The hidden address used for SMTP protocol, where bounce messages are sent, e.g., bounces@yourdomain.com.
This is the primary domain against which SPF is checked.
The SPF check, as defined by RFC 7208, primarily validates the domain found in the RFC 5321.MailFrom address (the Return-Path). When a mail server receives an email, it extracts this domain and then performs a DNS lookup to retrieve the SPF record associated with it. The server then compares the sending IP address against the list of authorized IP addresses or domains specified in that SPF record.
The primary SPF check domain
The reason SPF focuses on the Return-Path domain is its direct involvement in the SMTP envelope. This is the transactional part of the email, where the actual sender's server identifies itself. By checking this domain, SPF aims to prevent unauthorized servers from sending mail using your domain's identity, especially concerning bounces and feedback loops.
Ensuring SPF success with external senders
When using third-party Email Service Providers (ESPs) for sending, they often use their own Return-Path domain for bounce handling. In such cases, your domain's SPF record is not checked directly for SPF authentication. Instead, the SPF record of the ESP's Return-Path domain is checked.
It is crucial to understand the impact of the 'From' domain record when your ESP uses its own Return-Path. Incorrectly adding an ESP's SPF include to your own domain's SPF record when they use their own Return-Path is a common mistake that can lead to exceeding the 10 DNS lookup limit. Mailchimp has been a notable example of this in the past.
This leads many to mistakenly believe that their email is authenticated by their own domain's SPF when using a third-party service, even if that service uses its own Return-Path. It is crucial to verify which domain is indeed being used for the Return-Path by your ESP. If you want to ensure the visible 'From' address is also authenticated, that is where DMARC comes into play, as it relies on alignment between the Header From and either the Return-Path or DKIM domain.
Therefore, if you are wondering whether SPF records should match the 'From' address or the Return-Path, the answer for SPF's direct check is the Return-Path. For your overall sender reputation and DMARC enforcement, alignment with the 'From' address is critical.
Beyond the return-path: HELO/EHLO and DMARC alignment
While the Return-Path is the primary domain for SPF checks, another aspect of the SMTP transaction that can be checked is the HELO/EHLO domain. This is the domain name the sending server identifies itself with at the start of the SMTP conversation. In specific scenarios, particularly when an email has a null Return-Path (often for bounce messages themselves), the receiving server may fall back to checking the SPF record of the HELO/EHLO domain.
Common SPF configuration mistakes
Including ESPs: Adding include statements for ESPs that use their own Return-Path, leading to unnecessary DNS lookups and potential SPF TempErrors.
Missing HELO check: Overlooking the SPF record for the HELO/EHLO domain, which can be critical for some recipients.
Best practices for SPF records
Align with Return-Path: Ensure your SPF record is on the domain used for your RFC 5321.MailFrom (Return-Path) address.
Subdomain management: If sending from a subdomain, ensure it has its own, correctly configured SPF record. For example, configure SPF for your subdomain.
Consider HELO: Publish an SPF record for your HELO/EHLO domain, especially if it differs from your Return-Path domain.
Historically, there have been instances where some mail providers, particularly Microsoft, have been observed to perform SPF checks against the RFC 5322.From (Header From) domain in addition to, or instead of, the RFC 5321.MailFrom. This led many senders to create SPF records for their Header From domain to improve deliverability to Microsoft recipients. While less common now with stronger DMARC adoption, it highlights that some receivers may have their own interpretations or additional checks beyond the core SPF specification.
Ultimately, for an email to achieve DMARC compliance, it must pass either SPF or DKIM authentication, and the authenticated domain must align with the RFC 5322.From domain. This is where the interplay between the Return-Path (for SPF) and the Header From (for DMARC alignment) becomes critical. You can learn more about the relationship between SPF, DKIM, and DMARC in our other guides.
Key takeaways for robust SPF configuration
In summary, SPF predominantly checks against the RFC 5321.MailFrom (Return-Path) domain. In certain edge cases, or for null senders, the HELO/EHLO domain may also be checked. The RFC 5322.From (Header From) domain is primarily relevant for DMARC alignment, which then relies on the SPF pass.
Ensuring your SPF records are correctly configured for the domains actually being checked is crucial for email deliverability. This includes understanding when SPF flattening is necessary and managing your DNS records meticulously to avoid common issues like exceeding the 10 DNS lookup limit or having an SPF record on a subdomain when the root domain is expected.
Proactive monitoring of your email authentication status and deliverability reports can help you identify and resolve issues promptly, preventing your legitimate emails from being flagged as spam or rejected. Regular checks ensure your SPF setup remains robust as your sending infrastructure evolves.
Views from the trenches
Best practices
Always align your SPF record with the Return-Path domain to ensure proper authentication.
If using third-party ESPs, verify which domain they use for the Return-Path and configure SPF accordingly.
Regularly review your SPF records to avoid exceeding the 10 DNS lookup limit, which can cause SPF failures.
Common pitfalls
Mistakenly putting SPF records on the visible 'From' domain when the Return-Path is used by an ESP.
Ignoring subdomains, which often require their own SPF records for proper authentication.
Exceeding the 10 DNS lookup limit in your SPF record, leading to authentication failures.
Expert tips
Use an SPF flattening service if you have many `include` mechanisms to stay within DNS lookup limits.
Monitor your DMARC reports closely to identify any SPF alignment issues or unexpected sending sources.
Test your SPF record using an SPF checker tool after any changes to ensure it's valid and correctly configured.
Expert view
SPF checks are specifically performed against the Return-Path domain. If a third-party platform manages bounce handling using its own Return-Path, including them in your domain's SPF record is unnecessary.
December 3, 2020 - Email Geeks
Expert view
Many third-party authentication guides incorrectly advise users to include their SPF recommendations, often leading to SPF lookup limit issues. Mailchimp previously did this but has since updated their guidelines.
December 3, 2020 - Email Geeks
Strengthening your email authentication
Understanding which domain SPF checks against is a cornerstone of effective email deliverability and security. By correctly configuring your SPF records, particularly focusing on the Return-Path domain and considering the HELO/EHLO domain, you can significantly enhance your email's authenticity and ensure it reaches its intended recipients.
This knowledge empowers you to troubleshoot authentication issues, work effectively with ESPs, and ultimately build a stronger sending reputation. Always prioritize proper DNS configuration for all your sending domains and subdomains to maintain optimal email performance and prevent issues like being placed on a blocklist (or blacklist).
Microsoft, have been observed to perform SPF checks against the RFC 5322.From (Header From) domain in addition to, or instead of, the RFC 5321.MailFrom. This led many senders to create SPF records for their Header From domain to improve deliverability to Microsoft recipients. While less common now with stronger DMARC adoption, it highlights that some receivers may have their own interpretations or additional checks beyond the core SPF specification.
