1. Overview of Changes and Impact on Deliverability

In Marketing Cloud Engagement (MCE), there is a system constraint of "one SAP domain per Business Unit (BU)." Therefore, changing an SAP domain is not simply overwriting a setting value; it is a reconstruction process involving the deletion of the old domain configuration and the setup of a new domain.

Since SAP domain and IP configurations vary by environment, it is crucial to understand what changes before and after the SAP domain modification. Specifically, ensuring PTR record integrity and considering domain warming are essential.

2. Prerequisites: Contract and Environment Check

Before submitting a change request, please verify your contract status and current configuration.

A. Contract Requirements

• SAP SKU: To change the domain, the purchase or consumption of a new SAP SKU is required.

• SSL SKU: To secure images, click links, CloudPages, etc., the purchase or consumption of a new SSL SKU is required.

  • Note: SSL configuration may take up to 3-4 weeks after the SAP application is complete. Therefore, considering potential rework or delays, we recommend securing a schedule of 1-2 months or more.

B. Selection of the New Domain

As with standard SAP configurations, use a subdomain such as email.example.com.

• Corporate Root Domains: In principle, corporate root domains cannot be used as SAP domains.

• If you wish to use a corporate root domain as a sender address, consider using it as a Private Domain.

3. IMPORTANT: Verifying SAP/PD and IP Configurations in Each BU

A. Check SAP and Private Domains (PD) in Each BU

Verify whether the SAP domain to be deleted is being used as an SAP or Private Domain in other BUs. If the DNS records of the old SAP domain are deleted while still in use by another BU, it may disrupt deliverability and functionality for that BU.

B. Check Assigned Sending IPs and PTR Records (Important)

The most common technical inconsistency affecting deliverability arises from Reverse DNS (PTR record) settings. You must check the assigned IP addresses and their PTR records not only for the BU changing SAP but for all BUs.

<Why PTR Record Verification is Necessary>

Receiving servers strictly verify whether the connecting "IP address" matches the "domain" it claims to be (FCrDNS authentication). Typically, the sending IP address has a hostname using the SAP domain set in its PTR record. A request to change the SAP domain does not automatically update the PTR record domain. Therefore, if the SAP domain is changed and the old DNS records are removed, the A record associated with the PTR record will fail to resolve. This leads to FCrDNS failure, resulting in bounces and negatively impacting deliverability.

<Specific Verification and Action Steps>

Check the sending IP addresses assigned to each BU. If a PTR record is assigned to the old SAP domain, please request a PTR record update via a Support Case.

1. How to Check Assigned Sending IPs

You can view the IP assigned to a specific MID when creating or editing a Delivery Profile. The IP will be selectable from a dropdown menu.

• Reference: Delivery Profiles

2. Example of PTR Record Verification

Use external web tools or terminal commands (dig, nslookup, etc.) to check the PTR record. If you encounter a situation like the one below, the PTR must be changed to the new SAP domain or a default domain. Please report any IPs with such configurations to Support.

Configuration Example: Existing SAP is old-sap.example.com

• Sending IP: 1.2.3.4

• PTR: mta.old-sap.example.com

• (Deleting the DNS for old-sap in this state will cause authentication failures.)

4. Post-Migration Deliverability Measures

Immediately after switching to the new domain, the domain reputation is low, and ISPs may accept fewer emails than usual. Additionally, there are cases where DNS records are not updated as expected, causing SPF or DKIM failures. Therefore, these must be monitored for a certain period.

A. Verification of Authentication Protocols (SPF/DKIM/DMARC)

After the SAP domain change and DNS setup are complete, perform test sends before starting full-scale delivery to verify that SPF, DKIM, and DMARC result in a Pass.

1. Test Sending Scope (Sender Sources)

We recommend testing the following sender patterns:

• Sender is the New SAP Domain: The most basic test.

• Sender is a Private Domain within the same BU: If a Private Domain is set up in the BU where SAP was changed, test sending from it as well (to check impact on DKIM and DMARC alignment).

• All IPs where the Old SAP Domain was assigned to PTR: Test sending from IPs that had the old SAP domain in their PTR records to ensure no bounces occur due to FCrDNS verification.

2. Selection of Test Destinations (Receivers)

Use major consumer ISPs (Webmail) such as Gmail or Outlook.com for test destinations. Selecting multiple providers helps isolate ISP-specific issues.

• Note - Avoid Corporate Domains: Testing against corporate email addresses is not suitable for pure DNS verification because security gateways or forwarding settings often rewrite email headers, causing SPF/DKIM to fail.

3. Verification of Header Information (Before / After)

Check the headers of received emails to confirm authentication results and configuration changes.

• Authentication Results: Check the Authentication-Results header and ensure SPF, DKIM, and DMARC are all pass.

• Envelope From (Mail From) Change: With the SAP change, the bounce return path (Envelope From) also switches. Confirm this change in the headers.

  • Before: bounce.[Old SAP Domain]

  • After: bounce.[New SAP Domain]

NOTE:

DMARC Alignment when using Private Domains

Typically, when using a Private Domain as the Sender (From address), the Envelope From remains the SAP domain (bounce.[New SAP Domain]). If this mismatch causes DMARC validation failure (Alignment Fail), you may need to enable the "Multi-Bounce Domain" feature.

• Reference: Multi-Bounce Domain

B. Implementation of IP Warming

Since the domain has changed, ISPs may require warming (throttling) even if the IP address remains the same. Consider gradually increasing sending volume immediately after the change. Also, if a new Dedicated IP included with the SAP is assigned to the BU, warming for that specific IP must also be considered.

C. Monitoring Bounces

After the change, use SQL Query Activities in Automation Studio to query the _Bounce Data View and monitor bounce status more carefully than usual. If bounces increase, scrutinize the SMTPBounceReason field for words suggesting DNS configuration errors or reputation issues:

• Example Keywords:

  • FCrDNS: Reverse DNS mismatch (suggests missing PTR record configuration).

  • DKIM fail / SPF fail: Authentication configuration errors.

  • Block, Reject: Suggests blocking due to lack of reputation.

5. DNS Validity Period for Old Domains (Handling Past Emails)

Images and links in past emails sent will continue to reference the old domain. Typically, the DNS configuration for the old domain is maintained on the Salesforce side for approximately 60 days. During this period, image rendering, unsubscribe links, Open/Click tracking, and RMM for past emails will function.

IMPORTANT:

Even if Salesforce maintains the configuration, if you (the customer) perform DNS changes on your side (such as removing NS record delegation or deleting records in a self-hosted setup), the old domain will fail to resolve immediately upon propagation. This causes broken images, tracking failures, broken unsubscribe links, and RMM failure for past emails. Please fully understand this impact before deciding on the timing of deletion and notifying users.

FAQ

Q. Can I specify or shorten the completion date for SAP or SSL setup?

A. No, in principle, a completion date cannot be specified. Configuration work requires time, so we recommend planning with ample lead time.

Q. Can I run the new and old SAP domains in parallel?

A. No, due to the "one SAP domain per BU" constraint, parallel operation is not possible.

Q. I want to continue using the old SAP domain as a sender address.

A. Please consider reprovisioning it as a Private Domain.

Q. What should I do if I want to immediately stop using the SAP domain?

A. If you remove the delegation of the SAP domain in your DNS settings (or delete the necessary records for self-hosted domains), access to the domain from the outside will be blocked. However, please consider that functions dependent on the SAP domain—such as image rendering, link redirection, and open tracking—will immediately cease to function.

There is a particularly critical risk: As explained in Section 3, if the PTR record of a sending IP address uses that SAP domain, deleting the DNS records will cause FCrDNS authentication (Reverse DNS) to fail. Furthermore, since the reference points for Sender Domain Authentication (SPF/DKIM) will also disappear, almost all ISPs are expected to reject (block) emails due to authentication failure. This can have a catastrophic impact on all sending activities using that IP. Please be fully aware of this risk. We strongly recommend being prepared to immediately restore (rollback) the records in case of an emergency.

Q. How many days does it take for DNS changes to propagate?

A. DNS propagation speed depends on the status of DNS servers across the internet, so we cannot provide a specific answer. It may finish in a few hours or take several days. Please use DNS check tools or perform actual test sends to verify propagation status.

Q. What are the recommended volumes and duration for domain warming?

A. How much an ISP accepts mail from a new domain depends on comprehensive factors such as current reputation and recipient engagement. Exact criteria are not public. However, as a general guideline, start with a small volume limited to "highly engaged users with a history of opens/clicks." Then, recommended operations involve gradually increasing volume while monitoring bounce rates and spam report rates. Please also refer to the documentation for details.

• Reference: IP Address Warming

*This article applies to Marketing Cloud Engagement. Considerations may differ for Marketing Cloud Growth & Advanced Editions (Marketing Cloud Next). *The behaviors described are current as of the time of writing and are subject to change without notice. *Since SAP/PD and sending IP configurations vary by environment, please plan changes after carefully considering the situation before and after the modification based on the above.