How do I configure DNS records to send emails from two different ESPs using the same subdomain?
Michael Ko
Co-founder & CEO, Suped
Published 9 Jun 2025
Updated 16 Aug 2025
8 min read
Configuring DNS records to send emails from two different Email Service Providers (ESPs) using the same subdomain is a common challenge for many organizations. It often arises when you have an existing setup, like a service desk or internal mail system on Google Workspace (G-Suite) or Microsoft Outlook, and then you introduce another ESP for marketing or transactional emails, such as Salesforce Marketing Cloud. The goal is often to have all emails appear as if they originate from the same familiar company domain.
While it sounds straightforward, managing SPF, DKIM, and MX records for multiple ESPs on a single subdomain introduces significant complexities. This configuration can lead to deliverability issues if not handled meticulously. I'll walk you through the key considerations and steps to navigate this challenging setup.
Understanding the challenges with DNS records
The core of the challenge lies in how different DNS record types function. SPF (Sender Policy Framework) is designed to specify which mail servers are authorized to send email on behalf of your domain. The critical rule with SPF is that you can only have one SPF TXT record per domain or subdomain. If you publish multiple SPF records, all of them become invalid, potentially leading to emails failing authentication and landing in spam folders.
Another complication arises with the 10-DNS-lookup limit for SPF records. Each include or a mechanism in your SPF record counts towards this limit. Combining multiple ESPs often means adding several include statements, which can quickly push you over the limit. When this limit is exceeded, recipients' mail servers will treat your SPF record as invalid, causing your emails to fail SPF authentication. This is a common source of SPF TempError in your DMARC reports.
RFC 5321 vs. RFC 5322 From addresses
Understanding the difference between the RFC 5321 From (Mail From or Return-Path) and the RFC 5322 From (Header From) addresses is crucial. SPF authenticates the RFC 5321 From address, which is typically hidden from the end-user but is used for bounce handling. The RFC 5322 From address is the visible sender address you see in your email client. When using multiple ESPs with the same visible From address, they may use different Return-Path domains, complicating SPF setup. Learn more in this article on email standards.
DKIM (DomainKeys Identified Mail) is generally less problematic than SPF. DKIM uses a digital signature to verify that an email was not altered in transit and was sent by an authorized sender. Each ESP typically provides its own DKIM keys, and you can publish multiple DKIM records for the same domain or subdomain by using different selectors. These selectors differentiate between the various DKIM keys used by your ESPs.
Strategies for successful dual-ESP setup
The simplest and most recommended approach is to use separate subdomains for each mail stream. For example, your primary email (e.g., mail.yourdomain.com) can handle your internal communications and service desk, while marketing emails use m.yourdomain.com and transactional emails use t.yourdomain.com. Each subdomain would then have its own distinct SPF, DKIM, and MX records, eliminating conflicts and simplifying management. This also helps with sender reputation isolation.
However, if using the same subdomain is a non-negotiable requirement, you'll need to consolidate your SPF records. This involves merging all include mechanisms from both ESPs into a single SPF TXT record for that subdomain. It's crucial to ensure this combined record does not exceed the 10-DNS-lookup limit. You can use an SPF validation tool to check this before deployment. Setting up SPF with multiple services can be tricky.
Example of a combined SPF record (for illustrative purposes)DNS
For DKIM, the process is simpler. Each ESP will provide specific CNAME records for DKIM authentication, often including a unique selector (e.g., s1._domainkey, mc._domainkey). You can publish multiple DKIM CNAME records for the same subdomain as long as their selectors are distinct. This allows each ESP to sign emails with its own unique key without interfering with the others. We have a guide to common DKIM selectors.
MX records, which dictate where incoming mail for a domain or subdomain should be delivered, are the most problematic when sharing a single subdomain. If your subdomain already has an MX record pointing to your internal mail server (e.g., ASPMX.L.GOOGLE.COM for yourdomain.com), you cannot simply add another MX record for a different ESP for bounce handling. Bounces for emails sent by an ESP need to be routed back to that ESP's infrastructure for proper processing and suppression. If the MX record points elsewhere, your ESP won't receive bounce notifications, impacting your deliverability and sender reputation. There are specific ways to add an MX record when CNAMEs are used, but it adds complexity.
Impact on deliverability and reputation
Sharing a subdomain between two ESPs introduces significant challenges for managing email deliverability and sender reputation. When different mail streams originate from the same domain (or subdomain), it becomes difficult to isolate the cause of deliverability issues, such as emails landing in the spam folder or being blocklisted. A poor sending practice from one ESP can negatively affect the reputation of the shared subdomain, thereby impacting the deliverability of emails sent from the other ESP, even if their practices are stellar.
The complexity extends to DMARC (Domain-based Message Authentication, Reporting & Conformance) reporting. While DMARC allows you to monitor authentication results, a shared subdomain means your DMARC reports will contain data from both ESPs. This makes it challenging to pinpoint which ESP or mail stream is causing authentication failures or reputation issues, requiring more granular analysis. Sharing a subdomain between ESPs has implications.
Using separate subdomains
Each ESP operates with its own dedicated subdomain. This means a distinct set of SPF, DKIM, and MX records for each, eliminating conflicts.
DMARC: Reports are combined, making source identification for authentication failures complex. Managing subdomain reputation becomes harder.
For these reasons, while technically possible to use the same subdomain for multiple ESPs, it's generally advised against. The increased complexity in configuration, debugging, and reputation management often outweighs the perceived benefit of a unified sending domain.
Practical implementation steps and considerations
If you decide to proceed with a shared subdomain, the first critical step is to identify the 5321.from (Return-Path) domain used by each of your ESPs. This is the domain that SPF will authenticate. For example, Google Workspace (G-Suite) typically uses the sender's primary domain for both the 5321.from and 5322.from addresses. Other ESPs might use their own dedicated subdomains for the 5321.from, even if the 5322.from matches your desired sending domain.
DNS Record Type
Function
Multi-ESP on Same Subdomain
SPF
Authorizes sending IPs for the 5321.from domain.
Requires a single combined TXT record including all ESPs, adhering to the 10-lookup limit.
DKIM
Verifies message integrity and sender identity through cryptographic signatures.
Allows multiple CNAME records using distinct selectors for each ESP.
MX
Directs incoming email to the correct mail server for a domain.
One primary set of MX records for the subdomain. Bounces will route to this server, potentially bypassing ESP bounce handling. Requires careful management.
After configuring your DNS records, thorough testing is paramount. Send test emails from both ESPs to various mailbox providers (Gmail, Outlook, Yahoo, etc.) and check their email headers to verify SPF, DKIM, and DMARC authentication results. Pay close attention to the Return-Path header to ensure bounces are correctly handled. Monitoring your blocklist status is also important. If you encounter issues, review your DNS records carefully and consult your ESP's documentation or support team, as they can provide specific guidance for their platform's requirements. Delegating a subdomain to your ESP can often simplify this process significantly.
Views from the trenches
Best practices
Use dedicated subdomains for each mail stream for simplicity and better management.
Ensure each ESP uses its own 5321.from domain with dedicated SPF and MX records.
Always use unique DKIM selectors for each email service provider to avoid conflicts.
Carefully combine SPF records into a single TXT record, ensuring it adheres to the 10-DNS-lookup limit.
Common pitfalls
Exceeding the 10-DNS-lookup limit in your SPF record, which leads to SPF authentication failures.
Having multiple SPF TXT records for the same domain or subdomain, rendering them all invalid.
MX record conflicts if the subdomain is already handling replies, impacting bounce processing by your ESP.
Difficulty in isolating and troubleshooting deliverability issues when multiple ESPs share the same sending identity.
Expert tips
Before making any changes, retrieve and analyze email headers from both ESPs to understand the 5321.from and 5322.from domains being used.
Always consult with your ESP's support team. They can provide specific DNS requirements for their platform and advise on the feasibility of your setup.
Implement DMARC with a p=none policy initially to monitor authentication results and identify any misconfigurations without impacting delivery.
Gradually transition your DMARC policy to quarantine or reject once you are confident in your authentication setup and report analysis.
Expert view
Expert from Email Geeks says SPF records can be joined into one record, but be careful not to exceed 10 DNS lookups, which would invalidate it. It's important to remember that having two SPF record entries is not supported and will invalidate both. You need to join them first and validate the combined record before deployment.
2023-02-03 - Email Geeks
Expert view
Expert from Email Geeks says you should not have the same SPF record for two different ESPs. Each ESP should use its own 5321.from domain, and that domain needs its own TXT record for SPF. Otherwise, you will encounter problems.
2023-02-03 - Email Geeks
Final considerations
While configuring DNS records for two different ESPs on the same subdomain is technically feasible, it introduces significant complexity and potential pitfalls for email deliverability. The primary challenges revolve around the single SPF record limit and the conflicting nature of MX records for bounce handling. Setting up email authentication for multiple ESPs is critical for success.
For optimal deliverability, simplified management, and clear reputation isolation, I strongly recommend using dedicated subdomains for each email stream. If a shared subdomain is unavoidable, meticulously combine your SPF records, ensure unique DKIM selectors, and plan carefully for bounce handling. Continuous monitoring of your email authentication and deliverability is essential to catch and resolve issues promptly. Utilize email testing tools to ensure everything is set up correctly.
