Salesforce Account Engagement SPF, DKIM and DMARC setup, step by step

On this page: Keep Account Engagement separate from other Salesforce products · Verify ownership of each sending domain · Publish the generated DomainKey and confirm signing · Understand default SPF before editing root DNS · Request a custom return path only when needed · Retain DMARC and validate alignment · Test public DNS, then test a real Account Engagement message · Troubleshooting and FAQs · Completion and maintenance

Salesforce Marketing Cloud Account Engagement, formerly Pardot, authenticates its default envelope sender with SPF automatically. For your own From domain, verify ownership in Domain Management, publish the account-generated DomainKey TXT record, and test aligned DKIM. Adding an old Pardot include to your root SPF record does not align Salesforce's default Return-Path with your From address. Salesforce DNS guidance.

Keep Account Engagement separate from other Salesforce products

This guide covers email sent through Marketing Cloud Account Engagement. It is not a guide to core Salesforce CRM outbound email, Email Relay, or Marketing Cloud Engagement's Sender Authentication Package. The names are similar; the sending systems and domain controls are different. Use the product shown in your account and the delivered message's actual transport as your scope boundary.

The domain-verification and DKIM workflows are documented for all Account Engagement editions and require the Account Engagement Administrator role. DNS access is also required, usually through a separate IT administrator. Domain prerequisites, DKIM prerequisites.

Before editing, record the business unit, exact sending domain and campaign route. Save existing DNS values, identify the owner of every record you might touch, and list other senders using that From domain. A domain already configured in a different Salesforce product is not evidence that Account Engagement is signing with it.

Verify ownership of each sending domain

1. In the Lightning app, open Account Engagement Settings → Domain Management. In the Account Engagement interface, use Admin → Domain Management.
2. Select Add New Domain, enter the domain you intend to send from and create it.
3. Open Expected DNS Entries and copy the validation key.
4. Publish it as TXT for the specific domain or subdomain shown in the instructions.
5. Return to Domain Management and select Check DNS Entries.
6. Repeat for each sending domain.

Ownership verification is distinct from DKIM. A validation token proves control; it is not the public key used to verify signatures. Salesforce ownership workflow.

Use a bare domain rather than a URL or an email address. Check how your DNS host appends the zone name: entering a fully qualified name into a relative-name field can publish at the wrong location. Keep the verification record separate from SPF; do not concatenate a validation token into a v=spf1 value.

Publish the generated DomainKey and confirm signing

In Email Sending Domains, find the domain and open Expected DNS Entries. Copy the DomainKey value and publish it as a TXT record at its issued hostname. Salesforce says signing can take up to 24 hours after publication. The domain should show verified; follow the Domain Management error link if it does not. There is no need to invent a separate core-CRM “Activate DKIM” step for this workflow. Account Engagement DKIM setup.

The public records have different jobs:

Ownership
Type: TXT
Owner: <sending domain or exact owner shown in Expected DNS Entries>
Value: <this domain's generated validation token>

DKIM
Type: TXT
Owner: <issued-selector>._domainkey.<sending-domain>
Value: <complete generated public DomainKey value>

Salesforce's DNS guide shows 200608._domainkey.yourdomain.com as the standard hostname, but use your own Expected DNS Entries rather than borrowing any example key. It also documents a default 1024-bit key and a Support route for 2048-bit requirements. Discuss dedicated-IP suitability and risks with Support instead of replacing the public key independently. Salesforce record details and key-size guidance.

Publish only public material. A receiver selects the key using the signature's d= and s= values; another account's key at a plausible-looking hostname will not validate your signatures. Retain the entire encoded value. A provider's split TXT strings must form one record, not independent public keys. DKIM specification.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Understand default SPF before editing root DNS

Account Engagement's default SPF is managed on its own envelope-sender infrastructure. The default Return-Path can therefore authenticate while failing alignment with your brand's visible From domain. Salesforce documents return-path examples under exacttarget.com and mc.pd25.com; these are illustrations, not values you should publish. Account Engagement DMARC support.

For this default route, do not add include:aspmx.pardot.com, _spf.pardot.com or _spf.salesforce.com merely because an old checklist suggests one. First determine whether the account actually uses a domain you control for MAIL FROM and whether the current product instructions call for a change. Leave root SPF authorizations needed by employee mail and other services intact.

SPF evaluates the MAIL FROM domain, not the visible From, and a root policy is not inherited by a subdomain. At an evaluated owner, publish only one SPF TXT record. If an authorized route requires an update, merge required mechanisms before the existing terminal all, preserve legitimate senders, and evaluate nested lookup terms against the ten-term limit. Do not remove authorizations solely to make a counter green. SPF rules.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Request a custom return path only when needed

If organizational policy requires SPF alignment, open an Account Engagement Support case requesting a custom return path. Salesforce supplies the DNS records through its Deliverability Team. There is one fixed custom return-path domain per business unit, not a different one for each campaign. Check all From domains used by the business unit against that design before approving it. Custom return-path limits.

Obtain an exact owner/type/value worksheet and confirmation of product-side activation. Do not construct MX targets or copy records from core Salesforce or Marketing Cloud Engagement. Keep this route pending until Support provides the values; ordinary DKIM setup can proceed independently.

If that Support-issued route requires MX or other routing changes, have the routing owner separately approve the full owner, complete MX numeric-priority/target set and any destination addresses before publication or activation. Compare the complete approved set at authoritative and recursive DNS, preserve corporate mailbox routes and stop on discrepancies. Do not invent routing tuples or infer approval from receiving the packet.

The sending domain and tracker domain must not be the same name. For example, using go.example.com for branded assets is not a reason to set the From domain to that same host. Sending/tracker conflict warning. Where a CNAME already exists, do not add competing TXT data or delete the alias without understanding its owner. DNS CNAME rules.

Retain DMARC and validate alignment

A message can pass DMARC through aligned DKIM or aligned SPF. Both are desirable, but both are not required. Relaxed alignment compares organizational domains; strict alignment requires exact domains. Thus DKIM d=example.com with From news@example.com can provide alignment even when SPF passes only for Salesforce's domain.

Inspect the exact From domain's _dmarc record and any applicable parent policy. Preserve existing enforcement and reporting destinations. If no policy applies and you are starting a monitored rollout, the shape is:

Owner: _dmarc.<from-domain>
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:<approved-report-mailbox>

Do not publish the placeholders, duplicate the record or downgrade an established policy. The current DMARC standard is RFC 9989; its removal of pct means percentage-rollout examples are obsolete. DMARC policy and alignment.

Configure a reporting destination you control or have approved. If it is external, follow the report consumer's authorization requirements. Use aggregate reports to identify failures across every sender before advancing enforcement. RFC 9990. Leave failure reporting off unless privacy and operational requirements justify it; such reports can expose message content. RFC 9991.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

Test public DNS, then test a real Account Engagement message

Replace placeholders with the worksheet's actual names. These commands are proposed checks, not results from a customer environment:

dig +short TXT '<ownership-record-owner>'
dig +short TXT '<issued-selector>._domainkey.<sending-domain>'
dig +short TXT '<observed-mail-from-domain>'
dig +short TXT '_dmarc.<from-domain>'
dig +short NS '<dns-zone>'
dig @<authoritative-nameserver> TXT '<issued-selector>._domainkey.<sending-domain>'

Expect the issued validation token and public key at their correct owners. Compare authoritative answers if a recursive lookup and the application disagree. An unrelated TXT token can coexist with other TXT records; multiple SPF policies at one owner cannot. If a custom return path is involved, check every additional record type Support supplied.

Send a low-volume, authorized test through the same Account Engagement business unit and production sending route you plan to use. An email from a salesperson's ordinary Salesforce mailbox is not the same test. Use an external mailbox you control and avoid customer information.

Open the raw message. Record the visible From, Return-Path, DKIM d=/s=, and the trusted receiving server's Authentication-Results. Look for DKIM pass with an aligned signing domain and overall DMARC pass. SPF should pass for the observed envelope identity; lack of default SPF alignment is not itself proof of a broken setup. If SPF itself fails, inspect the evaluated envelope domain, sending IP, DNS/lookup errors and forwarding before changing root SPF. If you requested a custom return path, verify the expected new envelope identity and its alignment explicitly. Reading trustworthy authentication results.

Require the intended Account Engagement signature itself to pass: match its d= and s= to the configured account-issued DomainKey, and require alignment with the intended unchanged visible From under the effective adkim mode. Also require the trusted receiver’s dmarc=pass for that From. An unrelated aligned signature or SPF-only DMARC pass does not complete this DKIM setup. Account Engagement signing configuration, DMARC alignment.

When multiple signatures are present, EmailAuth’s DKIM selector guide helps pair each d= and s= with the correct public-key lookup; do not combine fields from different signatures.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust. Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

A fictional diagnostic case: From is news@example.com, SPF passes for a Salesforce bounce domain, and DKIM passes with d=example.com. DMARC can pass through DKIM. If DKIM instead passes only for an unrelated domain, both green authentication labels can coexist with DMARC failure. The repair is aligned signing or the supported custom envelope route, not an unrelated root SPF edit.

Troubleshooting and FAQs

Why is my sending domain verified but DMARC still failing?

Separate ownership from signing. Inspect the generated DomainKey and a fresh delivered message. Then compare DKIM d= with the actual From domain and the policy's alignment mode. Verification of a DNS token alone does not authenticate a message.

Why does the DKIM record look missing?

Query the full issued owner. Check for a missing sending subdomain, duplicated suffix, wrong record type, truncated key or stale authoritative server. Do not reuse a tracker hostname to bypass the error.

Does a default SPF pass mean I can enforce DMARC immediately?

No. Check alignment and all other legitimate services first. A single successful message establishes that route at that time, not organization-wide readiness.

Can I use any 2048-bit public key?

No. The public key must correspond to Salesforce's active signing key. Use its Support process for custom key-size requirements, then validate both DNS and live signatures. Do not “upgrade” only the DNS half of a key pair.

Should I disable Salesforce Bounce Management to fix this?

Do not apply a core Salesforce workaround to Account Engagement. Confirm the product and route, then use Account Engagement's documented DKIM and optional Support-issued return-path configuration.

Completion and maintenance

Close the change only after public records match the account, the correct business unit verifies the domain, and a representative message shows the intended aligned pass. Keep a dated record of the selectors and custom return-path arrangement. Recheck after new domains, business-unit changes, key replacements or transport changes. Monitor aggregate reports and investigate new failures without blindly broadening SPF.

This guide is based on public documentation. No Account Engagement tenant configuration, DNS changes or sending tests were performed. Authentication does not guarantee inbox placement.