Summary
Setting up SPF records when utilizing multiple email sending services for a single domain requires careful consolidation. The fundamental principle is that a domain should only have one SPF record (a single TXT record starting with v=spf1). Having multiple SPF records can lead to an SPF PermError, which can negatively impact email deliverability. Instead, all legitimate sending sources must be combined into this single record using mechanisms like include to reference the SPF records of each service.
Key findings
- Single SPF record: A domain should only have one SPF record (one TXT record beginning with v=spf1). Multiple records will result in a PermError, causing emails to fail SPF authentication.
- Consolidate services: All email sending services (ESPs) must be included in this single SPF record. This is typically done using the include mechanism for each service, such as include:spf.protection.outlook.com.
- Envelope from domain: SPF authenticates the domain found in the MAIL FROM (or Return-Path) address, not the From header that users see. Ensure your SPF record covers the domain used in the MAIL FROM.
- Subdomain SPF: If a service uses a subdomain for sending (e.g., custom bounce domains), the SPF record should be published for that specific subdomain. Learn more about whether a subdomain needs its own SPF record.
Key considerations
- DNS lookup limit: SPF records have a 10-DNS-lookup limit. Exceeding this limit will cause authentication failures. Combining include mechanisms into a single record helps manage this. Review Mailgun's detailed guide on implementing SPF, DKIM, and DMARC.
- Verify MAIL FROM: To determine the correct domain for SPF, inspect the Return-Path header in emails sent by each service. This domain is what needs to be authorized.
- Avoid unnecessary mechanisms: If you're primarily using third-party ESPs, mechanisms like mx and a might not be required and can consume lookups if not strictly sending from your own mail server or A record IP.
- Testing is crucial: After updating your SPF record, send test emails through all services and use tools to check SPF authentication and overall deliverability. This will help you troubleshoot SPF authentication issues.
What email marketers say
Email marketers often navigate the complexities of SPF records with multiple sending services by focusing on practical outcomes and troubleshooting. Many encounter initial confusion regarding SPF record syntax and the specific domains that need to be authorized. Their experiences highlight the importance of testing and understanding the Return-Path to ensure proper configuration for all sending sources.
Key opinions
- Initial confusion: Marketers often find SPF records confusing, especially when managing multiple email service providers. The nuances of mx and a mechanisms can add to this complexity.
- Focus on results: Despite the technical challenges, many marketers prioritize achieving a good deliverability score using online testers, which often indicates correct SPF setup even if the understanding isn't deep.
- Importance of Return-Path: Identifying the correct domain for SPF authentication often comes down to inspecting the Return-Path header in sent emails.
- Service-specific guidance: Marketers often rely on specific instructions from their ESPs, such as Google Workspace, Amazon SES, or Helpscout, for their particular include values.
Key considerations
- Domain ownership: It's crucial to understand that SPF records validate the IP addresses authorized to send email on behalf of a specific domain where the record is set.
- Testing each service: To accurately determine the necessary SPF entries, marketers should send test emails from each platform and analyze the email headers to find the Return-Path domain.
- Custom bounce domains: If using custom bounce domains with services like Amazon SES, a separate SPF record might be needed for that specific subdomain, pointing only to the relevant ESP.
- Consolidating include statements: For a single domain, all include mechanisms from different services (e.g., Google, Amazon SES, Helpscout) must be part of one consolidated SPF record to comply with standards. WP Mail SMTP provides a useful guide on merging multiple SPF records.
Marketer view
Email marketer from Email Geeks highlights a common point of confusion for those starting out with SPF records, specifically asking whether their own domain needs to be explicitly added to the record when using external services like Google, Amazon SES, and Helpscout. They also inquire about the necessity of including IP addresses if those services are already referenced by include statements.
Marketer view
Email marketer from Spiceworks Community shares that their company utilizes a hybrid email environment, combining on-premises Exchange with Office 365, and they want to ensure their SPF record correctly authorizes both sending sources. They are seeking best practices to avoid deliverability issues when consolidating these different email systems under one domain.
What the experts say
Experts emphasize the critical distinction between the MAIL FROM (envelope sender or Return-Path) address and the From header (display address) when configuring SPF. They strongly advise inspecting email headers to determine which domain SPF authentication truly applies to. Furthermore, they highlight that traditional mx and a mechanisms might be unnecessary or even detrimental if not directly sending from your own mail server.
Key opinions
- SPF scope: SPF records apply to the envelope from address (also known as return-path, envelope From, or MAIL FROM), not the display From address in the mail client.
- Conditional mx and a: The mx mechanism permits the IP addresses of your MX servers to send email, while a permits the IP address of your domain's A record. They should only be included if those specific IPs are actually sending email for the MAIL FROM domain.
- Identify envelope from: It is essential to identify the precise envelope from domain used by each sending service to ensure the correct SPF records are published.
- Custom bounce domains for ESPs: For services like Amazon SES or Helpscout, if a custom bounce domain is configured, the SPF record should be published for that specific custom bounce domain, not necessarily your primary sending domain, to ensure proper authentication.
Key considerations
- Header analysis: To verify SPF authentication, check email headers for lines like Authentication-Results and Return-Path. This helps confirm which domain is being checked by SPF.
- Optimizing SPF records: While including mx and a isn't technically wrong in all cases, it's often unnecessary when using third-party ESPs for all sending, and removing them can reduce the number of DNS lookups, which is crucial for staying within the SPF DNS lookup limit.
- Impact on DMARC: Properly configured SPF is a prerequisite for DMARC. Ensuring SPF passes for all sending services, particularly for the MAIL FROM domain, is vital for achieving SPF alignment required by DMARC. Learn how to set up DMARC with multiple email senders.
- Comprehensive authentication: While SPF is crucial, experts recommend implementing DKIM and DMARC alongside SPF for a robust email authentication strategy. Autospf.com explains the importance of multiple SPF records in email authentication.
Expert view
Expert from Email Geeks clarified that SPF records primarily validate the IP address associated with the domain specified in the envelope from address, not the visible From header. They further explained that mx and a mechanisms in an SPF record permit the IPs of the domain's MX and A records, respectively.
Expert view
Expert from Word to the Wise (Laura) advises that SPF should be published for the domain found in the Return-Path line of an email's headers. This is the crucial domain for SPF authentication, and understanding its source for each sending service is key to proper configuration.
What the documentation says
Official documentation and RFCs clearly stipulate the rules for SPF record creation, especially concerning multiple sending services. They emphasize the singular nature of an SPF record per domain and the proper use of the include mechanism to consolidate all authorized senders. These sources also highlight the importance of the DNS lookup limit and the specific role of the MAIL FROM domain in SPF validation.
Key findings
- One SPF record per domain: RFC 7208, the Sender Policy Framework (SPF) specification, mandates that a domain must not have multiple SPF records. If multiple records are found, the SPF check results in a PermError.
- Use the include mechanism: To authorize multiple sending services, their respective SPF policies should be referenced within a single SPF record using the include mechanism (e.g., include:spf.example.com). This allows the SPF check to recurse and validate the included domains.
- SPF validation point: SPF authenticates the domain found in the MAIL FROM command during the SMTP transaction, not the From header that end-users typically see in their email clients.
- DNS lookup limit: SPF records are limited to 10 DNS lookups per validation. Each include, a, mx, ptr, and exists mechanism that causes a DNS query counts towards this limit.
Key considerations
- SPF record structure: A typical SPF record starts with v=spf1 and ends with a qualifier like ~all (softfail) or -all (fail).
- Prioritize direct includes: When using multiple ESPs, it's generally best practice to include their provided SPF domains directly, rather than relying on a or mx unless those mechanisms directly correspond to the actual sending IPs.
- Subdomain delegation: If different services send from distinct subdomains (e.g., marketing.example.com, transactional.example.com), each subdomain can have its own SPF record tailored to the service sending from it. This helps manage the DNS lookup limit for the main domain.
- Record publishing: SPF records are published as TXT records in your domain's DNS. After making changes, allow for DNS propagation time before testing.
Technical article
RFC 7208 states that a domain name must not have more than one SPF record. If a domain name has multiple SPF records, SPF validation results in a PermError. This fundamental rule prevents ambiguity and ensures consistent policy evaluation.
Technical article
Microsoft Learn documentation indicates that SPF authentication relies on the MAIL FROM address, also known as the P1 sender or envelope sender. It advises that the SPF record must include all IP addresses that send email on behalf of your domain to prevent messages from being marked as spam or rejected.
Related resources
6 resources
Related pages
Does a subdomain used for sending emails need its own SPF record?
How to set up email authentication for multiple ESPs on the same sending domain?
How to troubleshoot SPF authentication issues with multiple ESPs, subdomains, and CNAMEs?
How to set up DMARC with multiple email senders for the same domain?
Why your emails fail at Microsoft: the hidden SPF DNS timeout
A simple guide to DMARC, SPF, and DKIM
How to fix the 'SPF unauthorized mail is prohibited' error
Demystifying the SPF TempError in your DMARC reports
Solving the SPF alignment puzzle for google workspace alias domains
How to Run an Email Deliverability Test: A Proven Checklist
