Salesforce can send mail through different products and routes. Before changing DNS, identify which system sent the message and which organisation owns its configuration. A Sales Cloud notification, Marketing Cloud campaign and external relay should not be treated as one interchangeable setup.
This guide focuses on the Salesforce platform workflow that manages DKIM Keys in Setup. Follow the appropriate product documentation for other sending products.
Separate permission to send from message authentication
Salesforce's current domain-verification rules and DMARC solve different questions. Domain verification establishes an approved domain in the Salesforce sending workflow. DMARC evaluates a received message's visible From domain against a passing aligned authentication result.
An active DKIM key can satisfy Salesforce's sending-domain verification requirement. Salesforce also documents an authorised-domain verification option. The existence of that alternative does not mean a DNS ownership check creates an aligned DKIM signature on a message.
Check any individual address-verification requirement separately. Record the actual route, sender address, domain verification state and active signing configuration instead of collapsing them into one green status.
Create the DKIM configuration for the intended domain
Use the documented DKIM Keys workflow in the correct organisation. Select the intended domain and supported key configuration, with distinct selectors that do not overwrite another sender's records.
Salesforce generates a primary and alternate CNAME arrangement for the domain. Publish the account-generated names and targets, rather than copying a public example. The alternate participates in the provider's rotation design and should not be discarded as a duplicate.
Its current instructions call for separate DKIM keys for owned subdomains and advise against wildcard matching for owned-domain configurations. Check the exact sending identities rather than assuming that one parent-domain setup covers every subdomain.
Retain the organisation reference and generated record set in the change request. These details help distinguish production, sandbox and separate business-unit configurations.
Verify publication, then activation
Inspect the authoritative answers at the generated selector names. Check that the DNS editor has not appended the domain twice or changed the record type.
Wait for the provider's publishing process and public DNS requirements to be satisfied, then follow the supported activation step. A saved key configuration and a publicly visible CNAME are dependencies; neither alone proves that the intended outbound message is being signed.
Preserve other active DNS records and an existing DMARC policy. Adding Salesforce as a sender should not silently reset domain-wide reporting or weaker/stronger policy choices.
Check for substituted identities and alternate routes
Salesforce documents a substitute sender option for unverified domains. If enabled, the visible From may use a selected verified organization-wide address; if none is selected, the documented fallback is an org- or site-specific sfcustomeremail.com address. Site-specific settings can override the org-wide setting. The display name and Reply-To can remain unchanged. Diagnose the address actually received instead of assuming the user-entered address survived unchanged.
Also check for email relay or product-specific routing. A downstream system can change which identity is authenticated and where a message is modified. The final received message is the evidence for the route under review.
In a synthetic example, a team verifies a domain through an ownership workflow and closes the ticket. A later alert still has no aligned brand signature. The missing evidence was signing and receipt through that alert's actual path, not another proof that the organisation controls DNS.
Test the business events people depend on
Exercise a controlled version of an important workflow, such as a case notification or automated alert. Inspect the original received message and trusted receiver results, keeping visible From, DKIM d= and envelope identity together.
DMARC can pass through either aligned SPF or aligned DKIM. Record which path worked and what would happen if a relay changes the message or envelope identity. Do not assume SPF authorisation for a service-controlled return path aligns with the brand.
Keep alignment diagnosis and the sender inventory linked to the handover. Completion means that the specific product, organisation and workflow use the intended identity with evidence the next operator can repeat.
Track a verified but unsigned route
Written case SF-01 assumes example.org has a verified Authorized Email Domain entry, but its DKIM key is inactive because the alternate CNAME is missing. The intended From is cases@example.org; no received message, envelope or signature result exists. The Salesforce owner and DNS owner must reconcile both generated aliases and activate the correct key before testing the case-notification route. Ownership verification does not fill the signing gap. No organization, configuration, DNS record or case message was accessed.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.