Summary
The question of whether to add SPF records to both your sender (5322.From) and envelope (Return-Path) domains is a common one, especially when observing authentication reports in tools like Google Postmaster Tools. Fundamentally, SPF checks are performed on the envelope domain. Adding an SPF record to the visible sender domain (the 5322.From domain) might seem like double authenticating but it's generally unnecessary and can lead to confusion. While older systems or specific ESP tools might have looked for or warned about its absence, modern email authentication primarily relies on SPF checking the envelope domain for alignment with DMARC. Understanding this distinction is key to proper configuration and accurate reporting in postmaster tools.
Key findings
- Primary SPF check: SPF authentication is primarily checked against the envelope domain (also known as the Mail From or Return-Path domain), not the 5322.From sender domain.
- Historical context: Some older systems, particularly Microsoft's Sender ID, historically considered SPF at the visible From level, leading to outdated advice to add SPF to the sender domain.
- Google Postmaster Tools behavior: Google Postmaster Tools (GPT) may report 0% SPF for your sender domain if SPF is only passing on a separate envelope subdomain. To see full SPF data in GPT, you might need to add the envelope domain for monitoring.
- Avoiding clutter: Adding unnecessary SPF records to the 5322.From domain can clutter DNS entries without providing significant deliverability benefits for modern authentication processes.
Key considerations
- Focus on the envelope domain: Ensure your SPF record is correctly configured for the envelope domain used for sending. This is where the primary SPF check occurs.
- Monitor Google Postmaster Tools: If you're seeing low SPF rates in GPT for your sender domain, consider adding the envelope domain to GPT to get a complete picture of your authentication status.
- Align domains for DMARC: For DMARC alignment, both SPF and DKIM authentication must align with the 5322.From domain. This means the envelope domain (for SPF) and the d= domain (for DKIM) should be the same as, or a subdomain of, the 5322.From domain.
- Single SPF record: A domain should ideally have only one SPF record. If you have multiple services, you should merge them into a single comprehensive record.
What email marketers say
Email marketers often face confusion regarding SPF authentication, particularly when observing discrepancies in reporting tools like Google Postmaster Tools. The desire for double authentication by adding SPF to both sender and envelope domains stems from a misunderstanding of where SPF checks actually occur and how reporting tools interpret the results. Marketers are keen to ensure their emails pass all necessary authentication to avoid being blocked or sent to spam, leading to exploration of all possible configurations.
Key opinions
- Desire for complete authentication: Marketers seek to authenticate their email setup as thoroughly as possible, sometimes leading to the idea of adding SPF to both sender and envelope domains.
- Google Postmaster Tools confusion: Seeing 0% SPF in Google Postmaster Tools for the sender domain, even when SPF passes on the envelope domain, creates uncertainty.
- Minimizing header elements: Some marketers believe that aligning sender and envelope domains minimizes header elements that spam filters might monitor, potentially improving deliverability.
- Subdomain usage: A common setup involves using a subdomain for the envelope domain, which then passes SPF, but the impact on the primary sender domain's authentication reporting in GPT is often unclear.
Key considerations
- Understanding SPF scope: Marketers should focus on ensuring SPF is correctly configured for the domain specified in the Return-Path domain, as this is what SPF checks.
- Google Postmaster Tools insights: To gain complete visibility into SPF authentication data within Google Postmaster Tools, it is advisable to add the envelope domain (if different) to the tool.
- Alignment for DMARC: For SPF to contribute to DMARC alignment, the envelope domain must be either the same as or a subdomain of the 5322.From domain. This is critical for DMARC pass results.
- DNS best practices: Avoid cluttering your visible sender domain's DNS with unnecessary SPF records, as it doesn't improve authentication and can complicate management.
Marketer view
Marketer from Email Geeks asked if there was any advantage to double authenticating a setup with SPF, specifically by adding the SPF record to both the sender domain and the envelope domain. They were observing that their emails were passing SPF using the envelope domain (a subdomain of the sender domain), but Google Postmaster Tools showed 0% SPF in the authentication section.
Marketer view
Marketer from Email Geeks noted that they had seen setups where the sender and envelope domains align, which they believe also minimizes the number of header elements that spam filters might scrutinize. This approach is seen as a way to potentially improve deliverability by simplifying the email header.
What the experts say
Email deliverability experts consistently emphasize that SPF checks are performed on the envelope domain, not the 5322.From domain. They clarify that historical practices or misleading warnings from some tools might suggest otherwise, but these are generally outdated or misinterpret how modern email authentication works. Experts advise focusing on accurate SPF configuration for the envelope domain and proper DMARC alignment to ensure emails are correctly authenticated and delivered.
Key opinions
- SPF check location: Experts firmly state that SPF is checked at the envelope domain, not the 5322.From domain, dismissing the idea of double authenticating SPF on both.
- Outdated guidance: Old guidance, especially related to Microsoft's historical Sender ID, may suggest adding SPF to the visible from domain, but this is no longer relevant for current email authentication.
- ESP tool warnings: Some email service provider (ESP) tools might still issue warnings about missing SPF records on the From domain, even though these warnings are considered useless from a modern authentication perspective.
- Google Postmaster Tools reporting: GPT's SPF reporting is based on what is actually authenticating, typically the envelope domain. To see SPF results in GPT for a specific domain, that domain must be added to GPT.
Key considerations
- Domain alignment for DMARC: For optimal results, particularly with DMARC, ensure the envelope domain exactly matches or is a subdomain of the 5322.From domain. This ensures SPF alignment.
- Subdomain strategy: Using a subdomain as the envelope domain is a common and effective strategy, but remember that SPF is checked on this subdomain.
- Accurate GPT monitoring: If SPF passes on a subdomain, add that subdomain to Google Postmaster Tools for accurate authentication reporting, as GPT may not automatically reflect SPF passes from an envelope subdomain on the primary sender domain.
- Simplicity in DNS: Avoid adding unnecessary DNS entries to the 5322.From domain if SPF is not checked there, to keep your DNS clean and manageable, and to prevent potential issues with DNS lookup limits.
Expert view
Expert from Email Geeks clarified that SPF is not checked on the 5322.From domain, and therefore, it is unnecessary to clutter that domain with additional DNS entries for SPF. The primary check occurs elsewhere in the email's path.
Expert view
Expert from Email Geeks explained that historically, Microsoft (via Sender ID) might have looked for SPF or Sender ID records at the visible From level. This is the reason why some very old guidance might still suggest adding it there, but it is no longer current best practice.
What the documentation says
Official documentation, particularly RFCs related to SPF (like RFC 7208), specifies that SPF authentication evaluates the Mail From identity, which corresponds to the envelope domain (or Return-Path). The standard does not mandate or even suggest adding SPF records to the 5322.From header domain for authentication purposes. DMARC, however, bridges the gap by requiring alignment between the SPF-authenticated envelope domain and the 5322.From domain, ensuring a cohesive authentication chain.
Key findings
- SPF's primary function: SPF (Sender Policy Framework) is designed to specify which IP addresses are authorized to send mail for a domain that appears in the Mail From address (envelope sender).
- RFC 7208 guidance: The official SPF specification (RFC 7208) details the evaluation process, which is explicitly tied to the domain found in the SMTP MAIL FROM command, not the From header.
- DMARC alignment: DMARC (Domain-based Message Authentication, Reporting, and Conformance) introduces the concept of alignment, where the SPF-authenticated domain must align with the 5322.From domain for DMARC to pass.
- Single SPF record rule: DNS best practices and the SPF specification strongly advise against having multiple SPF TXT records for a single domain, as this can lead to authentication failures.
Key considerations
- Envelope domain configuration: Always ensure your SPF record is correctly published for the envelope domain used by your sending infrastructure.
- DMARC implications: To achieve DMARC compliance, the domain authenticated by SPF (the envelope domain) must match or be a subdomain of the domain in the From header.
- Avoiding redundancy: Adding an SPF record to the 5322.From domain when it is not also the envelope domain is not specified by standards and offers no authentication benefit.
- Consolidate SPF: If using multiple sending services, integrate all authorized IP addresses and mechanisms into a single SPF record for your envelope domain to comply with the standard.
Technical article
RFC 7208 (Sender Policy Framework) states that the SPF authentication process checks the MAIL FROM identity. This is the address provided in the SMTP dialogue, often referred to as the envelope sender or Return-Path, and is distinct from the 5322.From header.
Technical article
RFC 5322 (Internet Message Format) defines the structure of email headers, including the From address that is visible to the end-user. This specification does not mandate any direct authentication mechanism like SPF for this particular header field.
Related resources
8 resources
Related pages
What is the impact of the 'from' domain record on SPF when the ESP uses its own domain for the return-path?
Should SPF records match the 'From:' address or the Return-Path domain when sending from Marketo?
How do I align SPF authentication with my sending domain in Google Postmaster Tools?
Why are there two domains in the 'Mail From' field of an email header, and how does it affect deliverability?
What is the full form of SPF in email?
A simple guide to DMARC, SPF, and DKIM
Demystifying the SPF TempError in your DMARC reports
Ultimate Guide to Google Postmaster Tools V2
How to configure SPF when sending from a subdomain with a different 'from' email domain?
How do I set up an SPF record when using multiple email sending services?
