Summary
Managing SPF records, especially when integrating an email service provider (ESP) like SendinBlue, can be a complex task for email senders. A common challenge arises when organizations use multiple sending services, potentially leading to the creation of more than one SPF record for a single domain. This situation can cause authentication failures and negatively impact email deliverability. The key to successful email authentication lies in understanding how to correctly combine SPF records and select the appropriate domain for sending emails through an ESP.
Key findings
- Single SPF record: A domain or subdomain should only have one SPF TXT record published in its DNS. Having multiple records can lead to evaluation errors.
- Merging mechanisms: To accommodate multiple sending sources, all valid mechanisms (like include:, ip4:, mx, etc.) must be consolidated into a single SPF record, starting with v=spf1 and ending with a qualifier like ~all or -all.
- Envelope from authentication: SPF authenticates the envelope from (also known as the return-path or bounce domain), not the visible 'From' address seen by recipients.
- Subdomain for ESPs: It is generally recommended to use a dedicated subdomain (e.g., em.yourdomain.com) for sending emails through ESPs like SendinBlue. This practice helps isolate the reputation of your marketing emails from your main organizational domain.
Key considerations
- Unnecessary mechanisms: If you are not sending email from your main web server or mail server, you can often remove the a and mx mechanisms from your SPF record to simplify it and avoid potential issues, especially when using an ESP with a subdomain.
- Reputation isolation: Using a subdomain for marketing emails helps to separate the sender reputation of your bulk sends from your core business communications, protecting your main domain's deliverability.
- SPF validation tools: Always use an SPF validation tool, such as the one provided by dmarcian.com, to check for proper SPF record configuration and to identify any errors like multiple records or too many DNS lookups.
- Comprehensive authentication: Beyond SPF, ensure you have correctly configured DKIM and DMARC records to provide a full suite of email authentication for optimal deliverability. You can learn more in our guide to DMARC, SPF, and DKIM.
What email marketers say
Email marketers frequently encounter challenges with SPF record management, particularly when integrating third-party email service providers (ESPs) like SendinBlue. Their experiences highlight the practical implications of DNS configurations on email deliverability and sender reputation. Marketers often focus on strategies that maintain a healthy sending reputation while ensuring their campaigns reach the inbox effectively, often involving strategic use of subdomains and understanding SPF's role in the authentication process.
Key opinions
- Subdomain preference: It is strongly recommended to set up ESPs like SendinBlue with a subdomain (e.g., em.yourdomain.com) rather than the main organizational domain to protect sender reputation.
- SPF and envelope from: Marketers recognize that SPF authenticates the 'Envelope FROM' (or return-path/bounce domain), which is often different from the visible 'From' address and usually involves the ESP's domain or a configured subdomain. This is critical for alignment, as discussed in our guide on matching SPF records.
- Impact of multiple SPF records: Having two or more SPF records for the same domain will result in validation errors and should be resolved by merging them into a single record.
- ESP configuration guidance: ESPs like SendinBlue typically provide clear instructions and tools within their 'Senders & IPs' or 'domains' sections to help configure the necessary DNS records, including SPF.
Key considerations
- Protecting primary domain reputation: Marketers should always strive to separate the reputation of marketing emails from their main domain, as issues with bulk sending can negatively impact transactional or corporate email delivery.
- Verifying DNS changes: After making DNS changes for SPF, it's crucial to use online tools to verify that the records are correctly published and are not causing errors. For example, some users on Spiceworks Community discuss difficulties in combining multiple SPF records and the importance of verification.
- Sender tab setup: Even when using a subdomain for SPF, the visible 'From' address can still be whatever@yourdomain.com, maintaining brand consistency for the recipient.
Marketer view
An email marketer from Email Geeks suggests that it is possible to configure your organizational root domain (e.g., yourdomain.com) as the sending domain in SendinBlue. However, they highly recommend against this practice.They emphasize that maintaining a separation between the sender reputation of your organizational domain and your marketing subdomain is a critical best practice. This helps protect your primary domain's reputation from any potential deliverability issues that might arise from marketing email activities, ensuring that core communications remain unaffected.
Marketer view
An email marketer from Email Geeks clarifies that every email technically has two 'From' domains. One is the visible 'From' address that recipients see in their email client, and the other is the 'Envelope From' address, also known as the return-path or bounce domain, which is typically invisible to the recipient but can be seen in the full email headers.They explain that the SPF record specifically authenticates this 'Envelope From' domain. For ESPs like SendinBlue, this 'Envelope From' domain is often either a domain owned by the ESP itself or, ideally, a dedicated subdomain of your own domain, rather than your main organizational domain.
What the experts say
Email deliverability experts highlight the critical technical details of SPF record configuration, especially concerning the management of multiple email sending sources. Their insights focus on ensuring compliance with SPF specifications, optimizing DNS lookups, and understanding the subtle but important distinctions between various SPF mechanisms. They provide guidance to prevent common errors that can lead to authentication failures and diminished email deliverability.
Key opinions
- Single record necessity: Experts confirm that having more than one SPF TXT record for a domain will inevitably lead to evaluation errors, rendering SPF ineffective.
- Consolidated includes: The correct approach for multiple sending services (like a self-hosted mail server and SendinBlue) is to consolidate their SPF mechanisms, especially include: statements, into a single SPF record.
- Mechanism placement: While convention suggests placing a and mx mechanisms early in the SPF record, their exact position (after v=spf1) generally shouldn't affect evaluation, though adhering to convention is good practice.
- Conditional mechanism use: Mechanisms like a and mx are only necessary if the web server (for a) or mail server (for mx) associated with the domain is actually sending email on its behalf. If not, they can be safely removed.
- SPF scope: SPF authenticates the 'envelope from' address (also known as the return-path or bounce address), not the visible 'From' address. This is a crucial distinction for understanding how SPF aligns with email authentication protocols.
Key considerations
- DNS lookup limits: Be mindful of the 10 DNS lookup limit for SPF records. Each include:, a, mx, and ptr mechanism counts towards this limit. Exceeding it results in a PermError.
- Subdomain for ESPs: When using an ESP, configure it to send from a subdomain of your main domain. This allows for specific SPF records on the subdomain without interfering with the root domain's SPF record. This is especially true as Word to the Wise advises, that SPF authenticates the envelope sender.
- Corporate domain SPF: For your corporate domain, the mx mechanism might be useful, but if mail is handled by services like Google Workspace or Microsoft 365, it is often not strictly necessary as their SPF includes cover the relevant sending IPs.
Expert view
An expert from Email Geeks clarifies that you typically do not need to publish an SPF record for an ESP (like SendinBlue) on your bare (root) domain, such as yourdomain.com. They suggest that if SendinBlue is not using the bare domain in the SPF authenticated string, then adding its SPF record directly to the root domain is unnecessary and can lead to authentication issues, especially if your primary email system (e.g., Google Workspace) already has an SPF record there.The recommendation is to ensure SPF is correctly configured on the specific subdomain that SendinBlue is using for the envelope from address, which aligns with best practices for managing sender reputation and avoiding conflicts between different sending services.
Expert view
An expert from Email Geeks highlights that having two SPF records on a single domain is an invalid configuration that will cause evaluation errors. They state that such a setup prevents proper SPF authentication, leading to deliverability problems.They emphasize that all legitimate sending sources must be combined into a single SPF TXT record for the domain. This consolidation ensures that all authorized IP addresses and sending services are correctly listed, allowing recipient mail servers to validate incoming email against a unified, correct policy.
What the documentation says
Official documentation and industry standards provide the foundational rules for SPF record creation and management. These guidelines are crucial for ensuring proper email authentication, preventing common configuration errors, and maintaining high deliverability rates. Key documentation focuses on syntax, the single SPF record rule, mechanism usage, and the importance of DNS lookup limits.
Key findings
- One SPF record per domain: RFC 7208, the authoritative SPF specification, dictates that a domain or subdomain must only have one SPF TXT record. Publishing multiple SPF records leads to a PermError during evaluation.
- Consolidation required: If multiple email sending services are used for a domain, all their authorized IP addresses and 'include' mechanisms must be combined into this single SPF record. This is a common point emphasized by various guides on merging SPF records, such as those from FluentSMTP.
- Syntax and order: An SPF record must always start with v=spf1 and end with an 'all' mechanism (e.g., ~all, -all). The mechanisms are evaluated from left to right.
- DNS lookup limit: An SPF record must not cause more than 10 DNS lookups during its evaluation. Mechanisms like a, mx, ptr, and include each count as one lookup.
Key considerations
- Preventing PermError: To avoid SPF PermError caused by exceeding the 10 DNS lookup limit, carefully review your SPF record. Consolidate IP ranges where possible and remove unnecessary include statements.
- Choose 'all' qualifier wisely: The 'all' mechanism's qualifier defines how unauthorized senders are treated. -all (fail) rejects unauthorized mail, ~all (softfail) marks it as suspicious, and ?all (neutral) means it may or may not be authorized. Understanding the full form of SPF is key here.
- Regular validation: Regularly validate your SPF record using online tools to ensure it remains compliant, especially after adding or removing email services. This helps in fixing multiple SPF records and maintaining good deliverability.
Technical article
Documentation from DuoCircle clarifies that the rule for SPF records is to use v=spf1 and an 'all' mechanism (like ~all) only once within the entire record. They state that v=spf1 must always appear at the very beginning of the record, and the 'all' mechanism should be at the very end.This strict adherence to syntax and structure is crucial for SPF records to be correctly parsed and evaluated by recipient mail servers. Deviations from this rule, such as having multiple v=spf1 tags or multiple 'all' mechanisms, will lead to authentication failures and negatively impact email deliverability.
Technical article
Documentation from FluentSMTP advises that if you need to include several SPF records within your DNS zone, the correct approach is to merge them into a single record. This is achieved by incorporating all the necessary values or mechanisms from the individual records into one comprehensive SPF entry.They suggest using the include mechanism to reference the SPF records of other domains or services. This method ensures that all legitimate sending sources are authorized under a single SPF policy, preventing the PermError that results from having multiple SPF TXT records published for the same domain.
Related resources
10 resources
![How to Merge Multiple SPF Records [The Right Way]](https://postmansmtp.com/wp-content/uploads/2023/08/post-smtp-blog_How-to-Merge-Multiple-SPF-Records-The-Right-Way-Social-Media.jpg)
Related pages
Should I authenticate email with my own domain or an ESP's domain?
Does a subdomain used for sending emails need its own SPF record?
Where should SPF, DKIM, and DMARC records be placed for email authentication?
How to troubleshoot SPF authentication issues with multiple ESPs, subdomains, and CNAMEs?
What are the best practices for DNS lookups, SPF records, and subdomain usage for email deliverability?
Best practices for using unique or shared email subdomains across multiple sending tools?
Should I use a subdomain or my main domain for marketing emails?
How to configure SPF when sending from a subdomain with a different 'from' email domain?
What is the best practice for selecting a subdomain for marketing emails and how does it impact deliverability?
A simple guide to DMARC, SPF, and DKIM
