Summary
Migrating email services, particularly with self-hosted DNS and multiple IP addresses in Salesforce Marketing Cloud (SFMC), presents unique challenges. This scenario often involves retaining existing IP addresses while introducing new ones for segmentation, such as separating transactional and marketing emails. A key concern during such a migration is the potential for DNS conflicts, especially when overlapping private domains are involved and the DNS configuration is not managed directly by the email service provider. Understanding how new DNS entries for additional IPs impact existing sending infrastructure and ensuring all relevant domains are correctly configured for the new IPs is critical to maintaining email deliverability and avoiding disruptions.
Key findings
- IP reuse: Existing IP addresses can be reused on new SFMC instances while introducing additional dedicated IPs for specific email types like transactional or marketing sends.
- DNS warnings: Salesforce (or ExactTarget) may provide zone files with warnings about potential conflicts with other existing SFMC setups, particularly with self-hosted DNS. This highlights the importance of precise configuration.
- Overlapping domains: Even if the Sender Authentication Package (SAP) domain differs, overlapping private domains between old and new SFMC instances can lead to configuration complexities and potential conflicts if not managed carefully.
- New IP impact: Adding new IP addresses (e.g., for allocating campaigns across multiple IPs) requires specific DNS entries to ensure that private domains can send from these new IPs without adversely affecting the old setup.
- DNS entry role: An additional A record, such as for 'mta2', directs traffic for a specific mail transfer agent to the new dedicated IP, allowing associated domains to send through it.
Key considerations
- Thorough testing: After configuring DNS, it is crucial to test all sending paths to ensure emails are correctly routed through the intended IPs and domains, and that no conflicts arise. Consider validating DNS settings with a complete DNS migration guide.
- Impact assessment: Carefully assess whether new DNS entries will impact the old SFMC organization, particularly if private domains overlap. This requires a detailed understanding of existing DNS records.
- Private domain setup: Determine if additional DNS setup (e.g., A records or CNAMEs) is required for other private domains to explicitly send from the new dedicated IP addresses. This is part of resolving email deliverability issues during migration.
- Vendor support: While self-hosting DNS implies client responsibility, push for clarification or consultation from your ESP's account executive if support declines to assist with specific self-hosted configurations, especially given the costs involved.
What email marketers say
Email marketers often face significant apprehension when managing complex DNS configurations, especially during a migration to or within Salesforce Marketing Cloud. The primary concerns revolve around the potential for new DNS entries to disrupt existing email flows and the need for clear guidance on how new IP addresses integrate with overlapping private domains. They typically seek confirmation that their current sending capabilities will remain unaffected and that new configurations will enable desired segmentation without unforeseen conflicts.
Key opinions
- Impact on old org: Marketers are concerned whether adding a new DNS entry for a second IP will negatively affect their old SFMC organization, especially if it's still sending from the same private domains.
- Private domain sending: They want to confirm if existing private domains will automatically be able to send from the new dedicated IP, or if additional DNS setup is required for these domains.
- Generic warnings: Marketers frequently encounter generic warnings from SFMC about DNS conflicts, leading to uncertainty about their specific setup. This requires careful consideration of best practices for migrating ESPs.
- Support limitations: Frustration often arises when Salesforce support declines to provide hands-on assistance for self-hosted DNS configurations.
- Trust in setup: There's a general desire for reassurance that their understanding of the DNS changes is correct and that the setup will proceed without unintended consequences.
Key considerations
- Validating new entries: Ensure that the new DNS entry specifically enables the new Sender Authentication Package (SAP) or private domains to send from the new IP, without unintended routing for other domains.
- Holistic view: Consider the entire DNS zone file and how each record interacts, especially when managing overlapping private domains or warming up a new domain.
- Testing email sending: Implement rigorous testing of email sending from both the old and new instances, verifying correct IP usage for each domain and preventing any unintended routing or blocks.
- Salesforce community: Engage with Salesforce community forums and resources like Trailhead community discussions for insights into self-hosted DNS specifics, as direct support might be limited for such configurations.
Marketer view
Marketer from Email Geeks asks about the impact of a new DNS entry on an old organization still sending from the same private domains, despite not sharing the same Sender Authentication Package (SAP).
Marketer view
Marketer from Email Geeks questions if additional private domains will require extra DNS setup to send from the new IP address, beyond the initial configuration.
What the experts say
Experts in email deliverability and DNS management emphasize that the success of self-hosted DNS configurations during SFMC migrations hinges on meticulous attention to detail. While a basic DNS entry might seem straightforward, the interplay between old and new systems, especially with shared or overlapping domains and multiple IP addresses, can introduce subtle yet critical conflicts. Their consensus points to the necessity of comprehensive testing and managing expectations around vendor support, given the inherent complexities of client-managed infrastructure.
Key opinions
- Additive changes: New DNS entries, like an A record for 'mta2', should typically be added without replacing or deleting existing DNS records to avoid disrupting current email flows.
- Testing is key: Regardless of how well planned, thorough testing of the entire email sending configuration is essential after implementing any DNS changes. For example, verifying reverse DNS (rDNS) with multiple IPs.
- Detailed configuration: General advice is difficult because the success of the configuration lies in the specific details of the DNS setup. Even minor errors can lead to significant issues.
- Support expectations: While an ESP's support team might decline to walk through self-hosted DNS configurations, it's worth providing feedback to account managers about the need for clearer guidance on complex scenarios.
- Consultation: If internal expertise is limited, consider engaging a consultant for intricate self-hosted DNS and multi-IP setups, especially when managing subdomain reputation.
Key considerations
- DNS records review: Before making changes, thoroughly review all existing DNS records for the domain and subdomain to identify any potential conflicts or redundancies.
- Test environment: If possible, test the new DNS configuration in a non-production environment or with a small segment of traffic before a full cutover.
- Authentication standards: Ensure that SPF, DKIM, and DMARC records are correctly configured for all new IP addresses and associated sending domains to maintain strong authentication. Review relevant information on choosing domain and IP addresses.
- Monitoring: Implement continuous monitoring of email deliverability and DNS resolution after the migration to quickly identify and address any issues, including potential IP blocklisting (also known as blacklisting).
Expert view
Expert from Email Geeks advises adding the new DNS entry for mta2 without deleting or replacing any existing DNS records, as this could cause disruptions.
Expert view
Expert from Email Geeks suggests reaching out to Salesforce support for guidance, acknowledging the complexities of self-hosted DNS configurations despite initial reluctance.
What the documentation says
Official documentation from Salesforce and general DNS resources provides foundational guidance for configuring email infrastructure. These documents typically outline the necessary DNS record types (like A, CNAME, MX), the function of a Sender Authentication Package (SAP), and the general process for DNS migration. While they may not cover every intricate self-hosted scenario with multiple overlapping IPs, they emphasize the importance of correct record creation, understanding TTL values, and validating changes to ensure proper email routing and authentication. The core message is that accuracy in DNS configuration is paramount to prevent conflicts and maintain deliverability.
Key findings
- SAP role: A Sender Authentication Package is designed to brand a specific sending domain within Salesforce Marketing Cloud, necessitating particular DNS records for proper functionality.
- Record types: Proper configuration involves various DNS record types, including A records for IP mapping, CNAME records for aliasing, and MX records for mail exchange.
- TTL impact: The Time To Live (TTL) value for DNS records dictates how long resolvers cache information, affecting the propagation speed of changes during migration.
- Self-hosting responsibility: When DNS is self-hosted, the client assumes full responsibility for creating, maintaining, and troubleshooting all necessary DNS records, including adding DKIM records.
- Conflict warnings: Documentation may issue generic warnings about potential DNS conflicts if configurations are not precise, especially with overlapping email setups.
Key considerations
- Accurate record creation: Follow specific instructions for each DNS record type (A, CNAME, MX, SPF, DKIM) provided by SFMC to ensure proper email authentication and routing. A good place to start is with a simple guide to DMARC, SPF, and DKIM.
- Minimize TTL: Temporarily reduce TTL values for critical records before migration to speed up propagation, then revert to standard values afterwards.
- Full DNS zone: Obtain and review the complete DNS zone file from both old and new SFMC instances (if applicable) to ensure all required records are included and no conflicts exist.
- Post-migration checks: Verify DNS propagation using public tools and monitor email deliverability, including bounce rates and spam folder placement. This helps understand if changes have fully propagated.
Technical article
Documentation from Salesforce states that a Sender Authentication Package (SAP) is designed to ensure proper branding and email deliverability for a specific domain within their ecosystem.
Technical article
A technical guide from a DNS provider highlights that an A record maps a domain name to an IPv4 address, which is crucial for the correct identification and routing of email servers.
Related resources
3 resources
Related pages
How to resolve email deliverability issues and IP blocks when migrating to a new ESP?
What are the best practices for migrating ESPs with subdomain and IP warmups?
How do I configure reverse DNS (rDNS) with multiple IP addresses for email sending?
How do I configure DNS records to send emails from two different ESPs using the same subdomain?
How to manage subdomain reputation when using multiple IP addresses for email sending?
How to add DKIM record for owned domain in Salesforce Marketing Cloud (SFMC)?
A simple guide to DMARC, SPF, and DKIM
Why your emails fail at Microsoft: the hidden SPF DNS timeout
Boost Email Deliverability Rates: Technical Solutions from Top Performing Senders
Email Deliverability Issues: Getting Your Messages to the Inbox in 2025
