Keep Account Engagement separate from other Salesforce email products
Salesforce Account Engagement has its own domain-management workflow. Begin by confirming that the message is sent through Account Engagement, previously called Pardot, rather than core Salesforce email or Marketing Cloud Engagement. A DNS recipe for another Salesforce product can use different controls and should not be imported simply because the organization uses the same vendor. This guide covers Account Engagement sending-domain verification, DKIM and the optional support-assisted custom return path.
List each business unit, brand and intended From domain used by the account. Include the actual sender selected by campaign and automation settings. A domain that appears in a user's mailbox address is not automatically configured for every Account Engagement route. Assign a marketing owner and DNS administrator to review the inventory together before changing a shared domain's records.
The acceptance goal is a controlled received message with an aligned passing authentication mechanism. Domain ownership validation, DNS publication and a green management status are useful intermediate evidence. None alone proves that a specific campaign used the intended identity or that a receiving server accepted its authentication.
Understand the default SPF path before editing root DNS
Salesforce's Account Engagement DNS guidance states that Account Engagement mail passes SPF through its controlled sending infrastructure and does not require a customer SPF change for that default setup. Do not add a generic Salesforce SPF include to the organization's root domain merely because the product name appears in a DMARC report. Confirm the actual route and evaluated identity first.
SPF authenticates the SMTP MAIL FROM identity, with separate handling for HELO, under RFC 7208. Its result is distinct from alignment with the visible From. A successful provider-domain SPF check can coexist with unaligned SPF. Changing a different domain's policy does not change which envelope domain a message uses.
Preserve the SPF policy needed by the organization's other services. If a separately authorized custom setup requires a policy change, review one complete policy at that owner, including nested DNS-querying terms and the protocol lookup limit. Do not create a second SPF record or remove unrelated senders to make room for an unverified requirement.
Verify ownership and DKIM as separate records
Use Domain Management to identify the intended Email Sending Domain and its Expected DNS Entries. The DNS guidance distinguishes the domain's validation key from its DomainKey. The validation value establishes ownership for sending; the DKIM value supports message signing. Preserve both purposes in the worksheet rather than treating any TXT record containing a Salesforce value as interchangeable evidence.
Copy values from the actual account. Save the complete record owner, type, value and instruction date before making the DNS change. Check whether another Account Engagement account or a different service already depends on the same owner. Do not overwrite a conflicting record, reuse another customer's value or change a selector to an invented name. Ask support for a supported resolution when account arrangements collide.
Keep the email sending domain distinct from the tracker domain. Salesforce explicitly warns against using the identical domain for those two functions. A branded tracking hostname is not the same thing as the From domain, even when both share a parent. Inventory tracking dependencies separately so authentication work does not inadvertently change asset URLs or campaign links.
Publish the DomainKey through the documented workflow
Salesforce's DKIM implementation instructions require the Account Engagement Administrator role. In the Lightning app, open Account Engagement Settings, then Domain Management. In the alternative Account Engagement interface, the documented starting point is Admin. Under Email Sending Domains, open Expected DNS Entries for the chosen domain and copy the DomainKey value for publication as TXT.
Use the owner and value shown for that account and domain. The current article says to allow up to 24 hours for signing to take effect after the record is added. Treat that as provider timing guidance, not a guarantee that every DNS cache or receiver will update at the same instant. Record the publication time and wait for the expected state before judging a fresh test.
Confirm the public DNS answer, including the exact fully qualified owner. DNS editors sometimes append the zone name to the host field, creating a duplicated suffix when a full name is entered. Review the resulting answer rather than trusting the input form. Save any Domain Management error and its details so support can investigate the actual failure instead of a paraphrased status.
Decide whether a custom return path is required
Salesforce's DMARC support article describes aligned DKIM as the normal DMARC path and explains that the default return-path domain does not align with the visible From. It also documents a support-assisted custom return-path request. The stated limitation is one fixed custom return-path domain per business unit, rather than a variable domain selected for every message.
Before requesting this option, identify the business requirement. An organization that needs aligned SPF as well as DKIM should evaluate the actual domain arrangement and alignment mode with support. A business unit sending for unrelated brands should not assume one fixed return path can align with every From domain. Keep that design question open until the observed identities and supported configuration resolve it.
Obtain the exact DNS records from the support case and have the DNS owner review conflicts and dependencies. This article supplies no universal custom-return-path target or activation switch. Publishing guessed records or copying another product's bounce-domain configuration can break a working route without satisfying the requirement.
Test the selected sender through the actual message flow
Send harmless controlled messages through each materially different sending domain and business-unit route. Use the same sender selection as the planned campaign or automation. Record the campaign reference, Message-ID, UTC time and external test recipient. If a preview or test feature uses a different path from production, resolve that difference before treating it as representative evidence.
At the trusted receiving system, capture From, Return-Path and all DKIM signing domains and selectors. RFC 6376 defines the d= and s= values used to locate the public verification key. Compare the observed signing domain with the configured sending domain. A DNS record can be correct while a message still uses an unexpected sender or another route.
Apply RFC 9989 to the actual results. DMARC can pass through a passing aligned DKIM signature or passing aligned SPF. Record which mechanism supplied the result and which alignment mode applied. Keep SPF authentication, SPF alignment, DKIM authentication and DKIM alignment in separate fields. This prevents a single green status from hiding an untested requirement.
Troubleshoot the failing boundary instead of changing every control
If the sending domain is unverified, compare its validation key and exact DNS owner with Expected DNS Entries. If DKIM is missing after the expected activation period, confirm the selected From domain and account, then check Domain Management errors. If a signature fails, verify the selector and public value and inspect any downstream system that changes the message after signing.
If DMARC fails while SPF passes, investigate alignment and whether aligned DKIM was configured for that sender. Do not treat default SPF success as a promise of DMARC success. If a custom return path is involved, compare the observed envelope identity with the fixed business-unit setting and support-provided instructions. Preserve a representative failed message for diagnosis.
Keep the organization's DMARC policy and reporting destinations under their existing ownership. The Salesforce article describes a need for external DMARC monitoring rather than Account Engagement collecting those failure reports. DNS authentication work should not silently replace reporting destinations or lower enforcement across unrelated senders. Review any proposed policy change separately with the mail and security owners.
Account Engagement domain worksheet
- Account, business unit, brand and sending workflow: ____.
- Selected From address and configured Email Sending Domain: ____.
- Separate tracker domain and its existing dependencies: ____.
- Validation key and DKIM record references from Expected DNS Entries: ____.
- Public DNS answers, publication time and management status: ____.
- Default or support-assisted custom return-path design: ____.
- Custom return-path limitation and support confirmation where relevant: ____.
- Test Message-ID, UTC time, From, Return-Path and DKIM identities: ____.
- Trusted authentication results and aligned DMARC mechanism: ____.
- Exceptions, monitoring owner and approved recovery: ____.
Fictional example of SPF success without alignment
Fictional written case only: AE-01 assumes business unit North sends as news@example.org and business unit South sends as news@example.net. A proposed fixed custom return path under bounce.example.org may align with the first under relaxed SPF alignment but cannot be assumed to align with the unrelated second. DKIM signatures and SPF results remain unknown, so neither route has an asserted DMARC verdict. The marketing and mail owners should separate the business-unit settings and validate aligned DKIM per selected From domain before requesting any root SPF edit. All identities and arrangements are invented; no support case, DNS query or message was executed.
Keep completion tied to live evidence
The documented workflow does not verify a real tenant's permissions, generated values or custom return-path capability. Those account checks, live DNS and header verification, visual review and human SME approval remain pending. This guide is unpublished and must not be presented as proof that an organization's campaigns are authenticated in production.
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.