Engagement - Key Points and FAQ: SAP, Private Domain, and Email Configuration

Q) Can I add an SAP domain to an existing MID?

A) No, only one SAP domain can be applied per MID. If you wish to send emails using a different "From" domain on that MID, you must add a Private Domain.

Q) I want to use the same SAP domain in a Child Business Unit (BU).

A) An SAP domain can be copied to a Child BU. Please review the details in "Marketing Cloud Engagement - Sender Authentication Package (SAP) Copy Request Information and Notes" (referenced at the end), and then submit a support case to request the copy.

Q) I am choosing "Self-Hosted", but I want to preview the sample DNS records beforehand.

A) Please refer to the document below for samples. However, please note that the actual records provided in your specific SAP/PD case may differ slightly; use these samples only as a reference.

Reference: https://help.salesforce.com/s/articleView?id=mktg.mc_es_dns_record_maintenance.htm&type=5

Q) Can I use an existing domain currently used by another service for SAP/PD?

A) Yes, it is possible; however, you must select the "Self-Hosted" (DNS managed by customer) option. This is because the "Delegated" option (DNS managed by Salesforce) cannot accommodate existing MX or DKIM records from other services within the standard Marketing Cloud Engagement SAP DNS requirements.

Critical Configuration Warnings:

• Root Domain Usage: Using a root domain (apex domain) for SAP is strongly discouraged. This configuration frequently leads to DNS record conflicts. Any misconfiguration or oversight can cause prolonged service outages, resulting in critical failures such as email delivery blocks or website inaccessibility.

• Recommended Architecture: We recommend a configuration where a subdomain is utilized for SAP, while the root domain is configured as a Private Domain.

Implementation Requirement: In all cases where an existing domain is repurposed, you must coordinate closely with your internal network and infrastructure teams. A meticulous DNS design is required to ensure that existing traffic and infrastructure remain unaffected.

Reference: https://help.salesforce.com/s/articleView?id=000392198&type=1

Q) I am self-hosting and want to selectively implement records. What are the A and MX records used for?

A)

• A Record: Primarily included to satisfy providers that check for the existence of the sending source domain (web presence).

• MX Record: Used for RMM (Reply Mail Management) functionality. Since the reply domain is often configured as reply.<SAP/PD domain> in many cases, the MX record for the base SAP/PD domain is frequently unnecessary.

Q) I use the A record for a website and the MX record for an email service on another platform. Should I add all the zone file records provided for the Self-Hosted setup?

A) You must verify whether to add them based on the specific traffic and usage of that domain. This decision requires advanced DNS knowledge and an understanding of the domain's infrastructure, so we recommend involving the domain administrator.

Note that if you are already using the A record for a website and the MX record for an email service, replacing them will disrupt your website browsing and email reception. Therefore, in principle, you would choose not to add those specific records. In some rare cases, clients add our MX record with a lower priority. However, this implies that if your primary email service becomes unavailable, mail might be routed to our RMM servers. In that scenario, incoming mail for that domain will not reach your correct mail server, so this configuration is not recommended.

Q) Can I create mailboxes for the SAP/PD domain?

A) No, you cannot. If you wish to receive replies, consider using RMM or configuring the sender address to be an existing address managed by your own company's mail server.

Q) Is it possible to change the SAP domain?

A) Yes, but you must purchase a new SAP SKU.

Q) If I choose to use an existing Dedicated IP when applying for a new SAP domain, can I use the dedicated IP included in the new SAP separately?

A) No, in that case, a new IP address will not be assigned.

Q) What should I consider when purchasing an additional Dedicated IP?

A) Please consider the following points:

• Bounce Retry Logic: If your existing IP address has modified bounce retry settings, you typically want to apply the same settings to the new IP. Please request this via a support case if necessary.

• IP Warmup: The new IP address may also require IP Warmup depending on your volume.

Q) I delegated the SAP/PD domain, but the provided NS records (ns0X.ums-dns-salesforce.com) differ from the documentation (nsX.exacttarget.com). Is this a mistake?

A) Please be aware that NS records differ for Hyperforce environments. If you are using a Hyperforce environment, please use the records provided to you (e.g., ns0X.ums-dns-salesforce.com) exactly as instructed.

Reference: https://help.salesforce.com/s/articleView?language=en_US&id=mktg.mc_es_subdomain_delegation_guide.htm&type=5

Q) Is there a way for a user to check the IP address assigned to a specific MID?

A) Yes. When creating a Delivery Profile, you can select the IP assigned to that MID from the dropdown menu, allowing you to verify it there.

Reference: https://help.salesforce.com/s/articleView?id=mktg.mc_es_delivery_profiles.htm&type=5

Q) How many business days does it take to configure SAP, PD, or SSL?

A) While it depends on the volume of requests and the situation, it typically takes a minimum of 5 business days (excluding Self-service or Hyperforce automated setups). Since this involves domain changes, please ensure you allocate sufficient time and consider having a backup plan in case the setup is not completed in time.

Out of Scope for Support Cases

Support cannot answer the following:

• Configuration and troubleshooting of services provided by DNS servers or Registrars, and detailed QA on general DNS mechanisms.

  • Examples: How to register DNS records, validating settings for specific DNS services, troubleshooting when DNS records do not propagate, or explaining general knowledge such as the detailed meaning of various DNS records.

• Review and troubleshooting of DNS record settings when using Self-Hosted (Caution).

  • Examples: Confirming whether record content is problematic considering coexistence with existing services, or confirming impact on existing services.

• Inquiries about Costs and Licensing Structures.

• Inquiries about the necessary number of Dedicated IPs to purchase.

• Status confirmation of SAP/PD Cases. (Unless there has been no response from us for a long time in the case, or the person in charge of the case is absent).

• Confirmation of detailed schedules. (e.g., specifying the setup date/time for SAP/PD, or requesting prior contact regarding the estimated completion date/time).

• Detailed consulting on Deliverability. (e.g., recommended volume for IP Warmup, procedures, progress confirmation, monitoring reputation, investigating causes of decline, etc.)

  • Reason: These involve proprietary criteria held by external services which are generally not made public. Therefore, it is necessary to control bounce conditions according to general best practices.

• Verification of whether DNS record changes have propagated correctly.

  • Reason: Due to the nature of DNS, whether it is reflected correctly depends on the DNS service used by the receiving mail server, so we cannot verify the reflection. Therefore, you must verify the operation related to the change yourself. For example, if you changed a DMARC record, you should confirm that DMARC passes by actually sending an email.

Note: The behaviors and configuration processes described above are subject to change without notice. Also, they may differ slightly depending on the environment.