Confirm that this is Marketing Cloud Engagement
This guide covers email sent through Salesforce Marketing Cloud Engagement. It does not apply the Salesforce CRM DKIM Keys workflow, Account Engagement configuration, or Marketing Cloud Next settings to Engagement. Record the product, tenant environment, Enterprise ID, business unit Member IDs, and approved From domains before selecting a setup procedure. Similar product names are not evidence that the same DNS records or interface apply.
The important initial decision is whether the organization needs authenticated sending alone or also branded message links and images. Salesforce distinguishes a Private Domain from the Sender Authentication Package, abbreviated SAP here. SAP in this guide is a Salesforce product name, not the separate enterprise software vendor. The Private Domain product does not include a dedicated IP and does not brand link or image domains. Salesforce Private Domain FAQ
Treat licenses, sending infrastructure, and domain control as prerequisites rather than tasks to improvise during a campaign launch. Confirm the available entitlements with the account owner. This document does not authorize purchasing a domain product or accepting a contract. Where an existing package can meet the requirement, avoid designing a migration solely to remove a display label in a recipient's inbox.
Separate sending authority from branding
Salesforce describes SAP as a bundle that includes account branding, a private sending domain, an IP configuration, and reply-management features. Its documentation distinguishes Salesforce-hosted setup from Hyperforce arrangements requiring account-team involvement. A business unit's branding configuration can differ from the multiple Private Domains used as From addresses. Salesforce Sender Authentication Package
Map the business reason for each domain. One domain may represent the visible sender, another may support bounce processing, and others may host images or track clicks. A successful HTTPS link test does not tell you which domain signed the message. Likewise, a passing DKIM signature does not prove that the unsubscribe experience, images, or reply destination work correctly.
Choose an unused sending subdomain where that fits the organization's design. Before changing any delegation, inventory existing websites, mailboxes, verification records, and other applications at and below the proposed name. Delegating a zone changes who answers for its records. A security reviewer should understand that operational responsibility before approval. Do not replace authoritative name servers for the whole corporate domain to solve a narrowly scoped campaign problem.
Configure the supported domain route
The documented entry point is Setup, search for ssl, then Domain SSL Certificates. Use New Domain and select the needed authentication or authentication-and-branding scope, available IP arrangement, reply handling, and DNS management approach. Preserve the choices and the generated instructions. For self-hosted DNS, Salesforce provides Download Zone File on the sending-domain action menu. For delegated DNS, use the current supplied delegation instructions. Salesforce domain configuration
Have the DNS administrator review the generated records before applying them. The review should compare each proposed owner with what already exists, identify whether a name is relative or fully qualified in the DNS console, and explain each record's purpose. An imported zone file should not silently replace unrelated production data. Keep a dated copy of the issued file, its tenant association, and the approved change plan.
Do not type selectors or record targets remembered from another Engagement account. Current environment-specific instructions take priority over generic examples. If a required license or configuration choice is unavailable, ask the account owner or Salesforce to resolve it rather than borrowing the core CRM authentication workflow. This is especially important when the tenant's environment or domain-hosting arrangement differs from the public example.
Distinguish DNS recognition from activation
Salesforce documents three sending-domain states: Pending DNS validation, In progress, and Active. The middle state means setup is continuing after DNS detection. Do not schedule a production cutover on the assumption that a published record immediately makes the sender usable. Record the status and observation time, and obtain confirmation if the domain remains in an unexpected state. Salesforce domain configuration
For each business unit, confirm that the intended domain is available as an authenticated sending domain. Salesforce's Private Domain FAQ describes business-unit use through From Address Management. A domain's presence somewhere in the Enterprise does not prove that a particular sender profile or journey uses it. Salesforce Private Domain FAQ
The acceptance record should identify the exact send configuration, not merely the marketing department. Include a controlled campaign, any distinct transactional or triggered route, and the business units being released. Keep all test recipients authorized and avoid using a customer data extension as a troubleshooting shortcut. A safe test should not create unintended orders, reminders, or customer-facing commitments.
Prove authentication on received mail
Capture the original message at a receiver you control. Record the visible From domain, SMTP envelope identity, DKIM signing domains and selectors, and the receiver's trusted authentication results. The signature's d= value identifies its signing domain and s= selects the corresponding DNS key. Preserve all relevant signatures when there is more than one. DKIM RFC 6376
Evaluate alignment with the actual visible From domain under the domain's effective policy. DMARC requires a passing aligned SPF or DKIM path. A passing provider signature for an unrelated domain is insufficient, and a successful SPF evaluation does not automatically establish alignment. Use the current DMARC specification rather than treating any green authentication icon as complete evidence. DMARC RFC 9989
For SPF, inspect the identity the receiver actually evaluated. Maintain one applicable policy at that owner and account for the DNS-lookup budget, including nested evaluation. Do not paste a Salesforce CRM SPF include into an Engagement design merely because both services share a company name. The issued configuration and message route must support the change. SPF RFC 7208
If authentication fails after activation, compare the message with the selected business unit, sender domain, and published records. A mismatch can be a configuration-selection issue rather than a broken key. If DKIM passes but DMARC fails, investigate domain alignment. If both pass and delivery still suffers, preserve the receiver response and investigate reputation, consent, or content separately instead of repeatedly replacing authentication records.
Test replies and branded resources independently
Use a controlled reply to confirm that the expected mailbox or reply-management route receives it. Check a representative image, tracked link, web-view link, and unsubscribe action where those functions are enabled. Record the actual hostname and result without assuming every branded asset uses the same configuration. Do not include recipient-specific tracking tokens in a public implementation worksheet.
Plan recovery before replacing a live domain. Retain a previously supported sender route where feasible and define who can pause a campaign if tests fail. Removing old branding records can break links in mail already delivered. Preserve those dependencies until their owners approve retirement. Reverting an email sender selection may be safer than removing a delegation on which several workflows now depend.
Fictional example with two business units
Fictional written case only: MC-01 stipulates that the retail unit sends notices@news.example with a passing signature d=news.example. The support unit intends service@care.example but its domain is still In progress, with sender availability, DKIM and SPF results unknown. The support owner must wait for activation and verify its own selected route; the retail result does not close support acceptance. No tenant, domain or campaign was tested.
Implementation worksheet and release limits
Complete one worksheet for every domain and business-unit route:
- Scope: Engagement environment, Enterprise ID, Member ID, owner, From identity, and send type.
- Product decision: current entitlement, authentication-only or branding scope, approved IP and reply arrangements.
- DNS change: issued file or delegation instructions, existing dependencies, exact public owners and values, reviewer, TTL, and timestamp.
- Activation: observed sending-domain state, provider confirmation, authenticated-domain availability, and tested sender selection.
- Message evidence: test reference, receiver, From, envelope identity, DKIM d=/s= values, authentication results, and alignment decision.
- Functional checks: reply delivery, links, images, unsubscribe, recovery route, and retirement dependencies.
Live tenant configuration, DNS answers, received headers, current screenshots, visual review, and human SME approval remain pending. The guide is an unpublished documentary candidate. Hyperforce-specific values and any unsupported route remain on hold until the provider and account owner confirm the correct procedure.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.