“Salesforce sends our email” is not a sufficient configuration brief. CRM messages, classic Account Engagement sending, Marketing Cloud Engagement and newer campaign experiences have different administration and DNS workflows. Start with the message-producing product and feature, then select its supported authentication procedure.
Build a product-to-message inventory
For each business email, record the product, edition or experience, organization or business unit, initiating feature, visible From domain and any configured email relay. Obtain a redacted external sample and the application event that produced it. A CRM workflow notification and a marketing journey may share a brand but use unrelated sending systems.
Make the inventory specific enough to assign an administrator. “Marketing Cloud” without its product and experience is too broad. Check whether an Account Engagement user is using its established sending interface or the newer Marketing Cloud campaign experience. Salesforce’s current documentation explicitly distinguishes those cases.
Select the correct configuration branch
For Salesforce CRM sending, the Create a DKIM Key procedure uses Setup, DKIM Keys, a primary selector and an alternate selector. Generate the key for the exact sending domain, publish both generated CNAME records and activate after DNS is ready. Current guidance calls for separate keys for owned subdomains rather than relying on wildcard matching. Do not reuse another organization’s generated values.
For classic Account Engagement sending, its DKIM guide uses Domain Management, Email Sending Domains and Expected DNS Entries. Copy that domain’s generated DomainKey into the specified TXT record. This is not the CRM two-CNAME workflow. Resolve verification errors in the product’s domain-management state, then inspect an actual delivered message.
For Marketing Cloud Engagement, determine whether the account uses a Sender Authentication Package or Private Domain and who hosts its DNS. The Private Domain documentation distinguishes authentication from link and image branding and says that a Private Domain does not include a dedicated IP. Follow the configured account’s domain setup rather than treating an unrelated CRM DKIM key as sufficient.
For Marketing Cloud Next Growth/Advanced editions and the Account Engagement new campaign experience, Salesforce’s current guide describes activated Authenticated Domains on Unified Messaging. SPF is managed through the bounce CNAME and the required outbound CNAMEs support DKIM. Review the generated setup for that experience; do not add a generic Salesforce SPF include as a substitute. Its recommended DMARC record still needs your domain owner’s review. This branch does not cover the Marketing App in Salesforce Starter, Salesforce Pro Suite or Salesforce Foundations: the cited Next guide says those sends use a salesforce.com domain with authentication handled automatically and no customer DNS setup. Confirm the actual experience before choosing either branch.
Keep the shared protocol questions consistent
Regardless of product, record the envelope domain used for SPF, the DKIM d= and s= values and the visible From domain. Distinguish a product’s successful domain-verification screen from the authentication result at the final recipient. If a corporate relay changes the message or its identities, include that relay in the test.
Maintain a single applicable SPF policy wherever you manage SPF directly. Do not paste several product-specific SPF records at the same owner. Coordinate DMARC at the From domain across all legitimate products before increasing enforcement. One product’s successful test cannot establish readiness for every sender using the brand.
Use an original selection worksheet
This is a proposed worksheet, not an inventory of a customer deployment.
- Business event: CRM workflow notification; Configuration branch: CRM DKIM Keys and actual relay settings; Evidence needed before approval: Active key, both CNAMEs and external headers.
- Business event: Established Account Engagement campaign; Configuration branch: Domain Management DKIM TXT; Evidence needed before approval: Expected DNS entry, verified state and sample.
- Business event: Marketing Cloud Engagement journey; Configuration branch: Account SAP or Private Domain; Evidence needed before approval: Product-specific domain setup and journey sample.
- Business event: New campaign experience; Configuration branch: Unified Messaging Authenticated Domains; Evidence needed before approval: Activated domain records and experience-specific sample.
If the product cannot be identified, stop the DNS change, not the investigation. Ask the application owner for the originating screen, send definition or event identifier. Never infer the branch from a marketing label alone.
Retest when the experience changes
Repeat the selection and header review after a product migration, new business unit, authenticated-domain change, relay change, selector rotation or provider DNS migration notice. Keep generated values and the source instructions dated. This guide reflects documentary review and synthetic acceptance planning; real messages and tenant settings remain the organization’s execution evidence.
Require a branch decision before the DNS ticket
Attach the product and experience name, business unit or organization, selected feature, generated public-record export and responsible administrator to the proposed ticket. Do not include credentials. Record why the other branches do not apply. A migration to another experience reopens this decision even when the From domain stays the same.