Can I keep the same IP addresses for both old and new SFMC instances during migration?

While you can keep the same IP address configured on both the old and new SFMC instances during a transition period, it is crucial that any new dedicated IPs (e.g., for transactional emails) are added as new, distinct DNS `A records`. This allows both systems to operate concurrently without immediate disruption.

What is the risk if private domains overlap between old and new SFMC organizations?

The main risk with overlapping private domains is that mail servers might struggle to correctly route emails or authenticate them, leading to deliverability issues. Each SFMC instance needs its own unique `mta` hostnames (e.g., `mta1.email.yourdomain.com` for the old and `mta2.email.yourdomain.com` for the new) to avoid conflicts and ensure emails are sent from the correct dedicated IP.

Do additional private domains need extra DNS setup to send from a new dedicated IP?

Yes, additional private domains you wish to send from the new dedicated IP will require specific DNS setup. This involves ensuring these domains are properly associated with the new IP within your SFMC account and that their corresponding `SPF` and `DKIM` `TXT records` are updated to include the new IP address. This helps to secure SPF and DKIM alignment for those domains.

How can I verify that my self-hosted DNS configuration for SFMC is correct?

After configuring DNS, you should perform thorough testing. This includes: 1. Using DNS lookup tools to verify `A`, `MX`, and `TXT` record propagation. 2. Sending test emails from the new SFMC instance to various providers and checking email headers for `SPF`, `DKIM`, and `DMARC` pass results. 3. Monitoring your IP warmup progress and sender reputation.

How to configure self-hosted DNS for SFMC migration with multiple IPs and avoid conflicts? - Technical - Email deliverability - Knowledge base

Migrating a client from an old Salesforce Marketing Cloud (SFMC) instance to a new one, especially when dealing with self-hosted DNS and multiple IP addresses, can present a unique set of challenges. The complexity increases when you're aiming to segregate email traffic, like transactional versus marketing emails, onto different dedicated IPs. It's not uncommon to receive warnings about potential conflicts with existing SFMC setups, which can be concerning.

My experience tells me that while the warnings are valid, they highlight the need for meticulous planning and execution rather than suggesting an impossible task. The key lies in understanding how DNS records interact across different SFMC instances and shared or overlapping private domains. We need to ensure that the new DNS entries for the additional IP addresses integrate seamlessly without disrupting the deliverability of the old organization or creating unexpected issues.

The objective is to enable the new SFMC instance to send from its newly assigned dedicated IP, while also confirming that any private domains associated with it are correctly configured to use this IP. This requires a deep dive into DNS configurations, understanding `A records`, and ensuring proper `SPF`, `DKIM`, and `DMARC` alignment for all sending domains and IPs involved.

Understanding the self-hosted DNS challenge for SFMC

When you're dealing with a self-hosted DNS setup for Salesforce Marketing Cloud, the control is entirely in your hands, but so is the responsibility for correct configuration. Unlike a fully managed solution where the provider handles DNS, you're tasked with accurately updating your zone files.

One common concern during a migration is the overlap of private domains. Even if the Sender Authentication Package (SAP) domains differ between the old and new SFMC instances, shared private domains can lead to conflicts if not managed carefully. The goal is to ensure that each domain, whether SAP or private, points to the correct IP addresses for its designated sending purposes.

Salesforce provides a DNS zone file, which is essentially a blueprint of the records needed for your SFMC setup. You can consult the Salesforce DNS record maintenance article for more details. This file includes `A records` that map hostnames like `mta2` to specific IP addresses. The critical part is to add these new entries without altering or deleting any existing records that are still in use by your old SFMC instance, especially if they share infrastructure or domains.

Old SFMC instance

Continues sending from its existing IP addresses.

DNS records remain untouched, ensuring uninterrupted email flow.

Maintain separate sender reputation and deliverability metrics for the old setup.

New SFMC instance

Introduces new dedicated IPs for specific email types (e.g., transactional).

Requires new DNS entries (like `A records` for `mta` hostnames) to point to these IPs.

Begins building new sender reputation on fresh IPs.

Managing multiple IPs and avoiding conflicts

The strategic allocation of multiple IP addresses is crucial for effective email deliverability, especially when you're separating transactional and marketing sends. Each IP should have its own set of DNS records, including `A records`, `MX records`, and `TXT records` for `SPF` and `DKIM`.

When you have private domains that overlap between the old and new SFMC organizations, the primary concern is ensuring that the DNS resolution for these domains directs traffic to the correct SFMC instance and IP. This is where careful management of your `A records` becomes paramount. An `A record` maps a domain or subdomain to an IP address. For instance, if `email.yourdomain.com` is used by both old and new, you need to ensure the `mta` records for each are unique and point to the respective IPs without overwriting each other.

For `SPF` and `DKIM`, ensure that the `TXT records` are properly configured to include all authorized sending IPs for that domain, regardless of which SFMC instance they originate from. This is vital to prevent `SPF` authentication issues and maintain email authenticity. You can learn more about how to resolve SPF SOFTFAIL errors. If you are also configuring rDNS with multiple IP addresses, this also needs careful attention to ensure proper mapping.

The challenge: overlapping private domains

If both the old and new SFMC instances use the same private domains, careful DNS configuration is required. A single domain cannot point to two different sets of `mta` records simultaneously without causing conflicts.

This could lead to emails from one instance failing `SPF` or `DKIM` authentication, as mail servers might resolve to the wrong IP or find misaligned records.

The solution: distinct hostnames and careful planning

Ensure that the `mta` hostnames (e.g., `mta1`, `mta2`) provided by Salesforce for each instance are unique within your DNS zone file. This ensures that when a mail server looks up `mta2.email.yourdomain.com`, it resolves to the correct IP for the new SFMC instance without interfering with the old one.

Confirm that all relevant private domains on the new SFMC organization are properly associated with the new dedicated IP within SFMC and have corresponding DNS records pointing to it.

Configuring DNS records for SFMC

Configuring self-hosted DNS for a Salesforce Marketing Cloud migration with multiple IPs involves adding specific records to your DNS zone file. The core records you'll be dealing with are `A records`, `MX records`, `CNAMEs`, and `TXT records` for authentication like `SPF` and `DKIM`. The DNS zone file you receive from Salesforce will detail these entries.

For the new dedicated IP, you'll typically add new `A records` for hostnames like `mta2` that resolve to the new IP address. It's crucial not to delete or modify any existing `A records` that your old SFMC instance or other services are currently using. Each instance needs its own distinct set of `mta` (Mail Transfer Agent) hostnames and corresponding `A records`.

Here's an example of what a new `A record` entry might look like in your zone file:

Example DNS A record for a new IPDNS

$TTL 1H
$ORIGIN email.yourdomain.com.

mta2             IN A            192.0.2.100

In this example, `mta2` is a new hostname specific to your new SFMC setup, and `192.0.2.100` is its associated dedicated IP. Remember to update the `SPF` record for your sending domain to include the new IP address. If you're setting up for multiple ESPs, you might find this guide on DNS records for two ESPs with the same subdomain helpful.

Verification and troubleshooting during migration

After making DNS changes, thorough testing is non-negotiable. DNS propagation takes time, so patience is required, but verification should happen regularly. Use DNS lookup tools to confirm that your `A records`, `MX records`, and `TXT records` (for `SPF` and `DKIM`) are resolving correctly to the intended IP addresses and values.

Send test emails from the new SFMC instance to various email providers (Gmail, Outlook, Yahoo, etc.) and check the email headers. Look for `Authentication-Results` headers to ensure `SPF`, `DKIM`, and `DMARC` pass. This confirms that your DNS changes are correctly enabling email sending from the new IP and private domains.

During migration, you need to be especially vigilant about potential deliverability issues. This includes watching out for any new IP blocklisting or blacklisting that could occur due to misconfigurations or sudden changes in sending behavior. For broader guidance on deliverability during migrations, refer to top DNS migration mistakes to avoid. Remember that best practices for migrating ESPs often include a dedicated IP warmup process, which should commence once the DNS is validated.

Key checks during SFMC DNS migration

DNS propagation: Verify that all new `A records`, `MX records`, and `TXT records` have propagated correctly across the internet.
Authentication records: Confirm that `SPF` records for all sending domains correctly authorize both old and new IPs. Ensure `DKIM` records are published and valid.
Test sends: Send emails to various test accounts and inspect headers for successful `SPF`, `DKIM`, and `DMARC` passes.
Deliverability monitoring: Keep a close eye on inbox placement, bounce rates, and any blocklisting (or blacklisting) issues for both the old and new setups. This is part of resolving email deliverability issues and IP blocks during migration.

Final considerations during migration

When approaching a complex DNS migration for SFMC, especially with self-hosted systems and multiple IPs, I always emphasize proactive planning and rigorous testing. The general advice from Salesforce support is usually correct, but they often can't provide specific guidance for self-hosted intricacies, as I've seen firsthand.

The warning about conflicts with existing SFMC setups is a blanket statement, but it highlights a real risk if DNS entries are not handled with precision. It's about ensuring that each instance has its clearly defined path for email sending, especially when private domains might overlap. This is also where understanding your subdomain reputation with multiple IP addresses becomes critical.

Therefore, the focus should always be on adding new records for new IPs without disturbing the old, and verifying that all domains are correctly mapped to their intended sending IPs. This includes the additional private domains you want to send from the new IP, which will require their own specific DNS entries if they haven't been configured yet.

Views from the trenches

Best practices

Ensure distinct `mta` hostnames for each SFMC instance to avoid DNS conflicts and routing issues.

Always validate DNS propagation after making changes, using tools to confirm correct record resolution.

Implement a gradual IP warmup process for new dedicated IPs to build sender reputation effectively.

Routinely monitor email deliverability metrics for both old and new setups during and after migration.

Common pitfalls

Overwriting or deleting existing DNS records used by the old SFMC instance or other services.

Failing to update `SPF` records to include all new sending IP addresses, leading to authentication failures.

Neglecting to configure `rDNS` for new dedicated IP addresses, impacting sender reputation.

Not accounting for DNS propagation time, which can lead to premature testing and confusion.

Expert tips

Use version control for your DNS zone files to track changes and easily revert if issues arise.

Leverage DMARC reports to identify authentication failures and gain insights into sending behavior from both instances.

Engage with Salesforce support for clarity on the exact DNS requirements for each new IP and domain.

Consider a phased migration approach to gradually shift traffic and monitor performance.

Expert view

Expert from Email Geeks says that the DNS entry for `mta2` appears to be an additional record and no existing DNS entries should be deleted or replaced.

2024-09-13 - Email Geeks

Marketer view

Marketer from Email Geeks says that the generic warning message from Salesforce will likely have no impact on the old organization, and the new `mta2` entry should only affect the new SAP.

2024-09-13 - Email Geeks

Key takeaways for SFMC DNS migration

Configuring self-hosted DNS for a Salesforce Marketing Cloud migration with multiple IPs requires a detailed understanding of DNS records and careful planning. The primary goal is to integrate new dedicated IPs for different email streams while preventing conflicts with existing setups, especially when private domains are shared across old and new instances.

Always ensure that new DNS entries are added without altering active records and that all authentication mechanisms (`SPF`, `DKIM`, `DMARC`) are correctly updated to reflect the new IP addresses. Rigorous testing and continuous monitoring are your best allies to ensure a smooth transition and maintain optimal email deliverability during and after the migration.