For Salesforce B2C Commerce (Demandware) native SMTP on a first-party POD, authorize the actual production realm hostname in SPF, generate a matching RSA public/private key pair, import the private key as PKCS#12 into Business Manager, and select the key and selector under Email Settings → Enable DKIM → Apply. Publish the public DKIM TXT record for every actual sending domain. One instance has one active key and selector, even when it serves multiple storefronts. Native DKIM support, Configuration.
Stop here if the realm is on Hyperforce or uses a custom SMTP service. Those routes are not interchangeable with this first-party POD procedure. Confirm the infrastructure before generating keys or editing DNS.
Identify the infrastructure and actual mail route
This guide covers the first-party POD native transactional-email route, with DKIM support introduced in release 24.1. Examples include order confirmations, account messages and password-reset messages sent by the storefront. It does not cover core Salesforce CRM, Marketing Cloud, Account Engagement, other Commerce products, or a separately configured SMTP relay. Salesforce recommends a dedicated service for marketing mail rather than treating the basic native send function as a bulk-marketing platform. B2C mail best practices.
Infrastructure is now an essential eligibility check. Salesforce's Hyperforce FAQ describes a gradual migration away from first-party PODs and new customers running on Hyperforce. The current post-migration article says B2C Hyperforce mail uses Unified Messaging Service (UMS), with sending-domain approval and DNS validation in Email Settings → Domains. It also documents conflicts involving an automatically derived bounce hostname. Do not solve those problems by importing this article's POD key or adding the POD SPF mechanism. Use the realm's migration instructions and issued DNS packet instead; preserve any hostname already serving another system. Hyperforce FAQ, Current Hyperforce mail issues.
The newer migration checklist also calls for approved sending domains, required DNS records and production-hostname SPF rather than a fixed IP. It does not make the POD private-key workflow a universal Hyperforce procedure. Follow the actual realm packet and resolve differences with Salesforce before making a change. Migration checklist.
In Business Manager, inspect the existing email configuration without changing it. If no custom configuration is set, customer and platform email use Salesforce's default service. A custom SMTP configuration can cover customer email only, leaving platform notifications on the default service, or cover both through Use for all email. A single successful test therefore cannot validate every route. An incomplete custom configuration can stop mail; enabling it is not an authentication repair. Email Configurator, Custom configuration scope.
Document the realm, instance, infrastructure, storefront, event, actual sending service and From domain. You need authorized access to the relevant Business Manager Operations settings, approved private-key handling and authoritative DNS editing. The cited procedure does not establish a universal role name for every account. Have the administrator confirm access rather than granting broad privileges or switching routes to expose a control.
Inventory every sending domain and protect existing mail
List every merchant-controlled From domain used by storefront code and site preferences. Include country storefronts, notifications, scheduled jobs and infrequent transactional events. For the default SFRA implementation, Salesforce points to Merchant Tools → Site Preferences → Custom Preferences → Storefront Configs → Customer Service Email. Custom cartridges can set the address independently, so inspect the actual implementation too. Sender-address guidance.
Do not use a shopper's Gmail, Outlook or other uncontrolled address as the From identity of a Contact Us message. Use an authorized merchant identity and, where appropriate, put the validated customer address in Reply-To. Changing Reply-To does not authenticate an unauthorized From domain. Review code and preferences through the normal deployment process; do not trigger real orders or reset messages casually. B2C third-party spoofing guidance.
Before changes, save the affected DNS records, current key alias/selector/signing state, sending-domain inventory and direct or inherited DMARC policy. Keep private-key backups only in approved restricted storage. Record which other instances share a key so rollback and rotation do not break them. Preserve MX, nameservers, DNSSEC, website hostname mappings and unrelated selectors. Authentication setup is not a storefront, DNS-provider or mailbox migration.
Authorize the correct POD hostname in SPF
The first-party POD best-practice article specifies an authorization mechanism shaped like this:
a:production.REALM.CUSTOMER.demandware.net
This is a mechanism, not a complete policy or a literal hostname to publish. Obtain the actual production realm/customer hostname for the confirmed POD route. Salesforce documents production outbound NAT for native mail from development, staging and production in this architecture. Do not substitute the shared outgoing address used by unrelated FTP/web-service traffic, a staging hostname, a copied IP snapshot, or core CRM's _spf.salesforce.com include. Native SMTP hostname guidance.
The article discusses reverse DNS, but its SPF instruction uses a:, not the obsolete ptr mechanism. Do not add ptr or attempt to change provider-managed reverse DNS as part of this task. Failure notifications can follow a different documented outgoing POD identity, so keep them separate from the merchant transactional-message test.
SPF evaluates the SMTP envelope MAIL FROM domain, not automatically the visible From header; HELO is relevant for empty return paths. Determine the actual evaluated owner from the sending configuration and trusted received results. A child envelope domain does not inherit apex SPF. A provider-owned envelope can pass SPF without aligning with the merchant's From; adding a mechanism to the merchant apex cannot repair SPF evaluated elsewhere. SPF identities.
At the required owner, maintain one TXT policy beginning v=spf1. Reconcile the authorized POD mechanism with all other legitimate senders, preserving the intended qualifier. Do not concatenate complete policies, add a second SPF record or remove existing services. Place mechanisms before the terminal all; an all mechanism makes redirect ineffective. Evaluate the complete ten-DNS-dependent-term budget, including nested includes and other lookup-causing terms. Never use +all to make a failure disappear. SPF processing.
Prepare the key pair and password-protected PKCS#12 file
Unlike core CRM's provider-generated CNAME workflow, this POD procedure has the authorized administrator generate the key material. Salesforce documents a 2048-bit RSA private key, a self-signed certificate for packaging, a PKCS#12 .p12 export and a matching public-key export. Follow its private/public key generation instructions on an approved administrative system, not an online generator.
The following command shapes reflect that sequence. They are instructions for an authorized administrator, not commands executed for this guide. Use a new protected working directory and unique filenames so you do not overwrite an existing key. Adapt the example certificate subject and validity to the provider's supported requirements and your key-management policy.
openssl genrsa -out private.pem 2048
openssl req -new -key private.pem -out tmp.csr -subj "/CN=dkim01/O=customer"
openssl x509 -days 3650 -signkey private.pem -in tmp.csr -req -out tmp_certificate.pem
openssl pkcs12 -export -inkey private.pem -in tmp_certificate.pem -out private_key.p12
openssl rsa -in private.pem -pubout -out public.pem
The PKCS#12 command intentionally omits the source example's hardcoded password argument so the administrator can supply a strong unique export password at the interactive prompt. Do not copy the published example password, put a real password in shell history, or share it in a ticket. Store it through your approved credential process. The exported private PEM is sensitive even though the .p12 is password-protected: restrict access, backups and retention for both. Do not upload private files or the password to DNS, public repositories, email drafts or general-purpose checking tools.
The .p12 file is imported into the intended Business Manager instance. The public key is used in DNS. Preserve the complete base64 public-key body for the DKIM p= value, not the PEM boundary lines or the private-key body. Do not publish a CSR or certificate in place of the DKIM public key. Keep an exact association between the private key, public key, planned selector and instance.
Publish the public key for every actual sending domain
Choose an unused selector and prepare the public TXT record at each sending domain. This is a structural example only:
Owner: YOUR_SELECTOR._domainkey.notifications.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=COMPLETE_BASE64_PUBLIC_KEY
The signing domain derives from the domain used to send the email; it is not a separate domain field in this documented DKIM configuration. An instance has one active private key and selector. Multiple storefronts on that instance share that pair, but every distinct sending domain or subdomain needs the matching public TXT owner. Publishing only at example.com does not cover notifications.example.com. The official diagrams show shared instance keys with separate DNS records for storefront subdomains. Domain and instance model.
For a full owner ending in notifications.example.com, a parent-zone editor that appends example.com expects YOUR_SELECTOR._domainkey.notifications. In a separately delegated notifications.example.com zone it expects YOUR_SELECTOR._domainkey. Avoid doubled suffixes. Inspect any _domainkey delegation and publish at the actual authority without deleting delegation or another sender's record.
Use the full key without ellipses. A single DNS TXT character-string is limited to 255 octets; a long DKIM value can use multiple quoted strings within one TXT record. Follow your editor's supported long-value representation and verify that the retrieved strings concatenate to the complete value. Do not split the key into independent records. A CNAME cannot coexist with this TXT at the same owner; resolve selector ownership rather than overwriting another service. DKIM record format.
Publish and verify the new public key before switching the active signer where possible. This staging avoids signing with a key receivers cannot yet retrieve. It does not create a second active key slot or authorize changing storefront hostname mappings.
Import the key and activate the intended selector
In the intended Business Manager instance, use App Launcher → Administration → Operations → Private Key and Certificates. Select Import, choose the .p12 file, supply its alias and the export password where required, and save. Then open Administration → Operations → Email Settings, select Enable DKIM, choose the imported key under Private RSA key, enter the planned selector and click Apply. Official import and activation.
Verify the selected key/selector against the public records already staged for every sending domain. Do not enable a custom SMTP configuration or alter Use for all email during this operation. Importing a key is not the same as selecting it for signing, and Apply is not proof that a recipient verified a message.
Test in development or staging before production as Salesforce recommends, but keep the instance settings distinct. A shared outbound production IP does not prove the instances share an active DKIM configuration. Changing the one active pair on a production instance affects its storefronts together; obtain the coordinated deployment approval before switching it. Instance testing guidance.
Preserve DMARC and approved reports
DMARC passes when SPF passes with an aligned envelope domain or DKIM passes with an aligned signing domain. Relaxed alignment compares Organizational Domains; strict alignment requires exact equality. A child domain can align with its parent in relaxed mode but not strict mode. Inspect the actual effective aspf and adkim settings rather than promising strict alignment from a DNS record. Current DMARC specification.
Preserve direct and applicable inherited policies and approved report recipients. Do not downgrade enforcement to p=none, duplicate a policy or adopt obsolete percentage-based enforcement advice for onboarding. Only if no direct or applicable inherited policy exists and the owner approves a monitored first-policy rollout, this minimal example illustrates placement:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none;
Use _dmarc in the parent zone. A deliberately selected child policy at _dmarc.notifications.example.com uses _dmarc.notifications in the parent zone or _dmarc in a delegated child zone. Agree an authorized reporting destination or another monitoring arrangement; the example deliberately invents no recipient.
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. If they differ, the report-generating receiver must check DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted; a different hostname alone is insufficient. That protocol check does not replace the owner's separate approval to share report data. RFC 9990 section 4.
Verify DNS and the actual storefront event
Replace every uppercase placeholder before using these read-only command shapes. Query each authoritative server and repeat through a public resolver:
dig @AUTHORITATIVE_NAMESERVER ACTUAL_SPF_OWNER TXT +noall +answer
dig @AUTHORITATIVE_NAMESERVER SELECTOR._domainkey.ACTUAL_SENDING_DOMAIN TXT +noall +answer
dig SELECTOR._domainkey.ACTUAL_SENDING_DOMAIN TXT +short
dig _dmarc.ACTUAL_POLICY_DOMAIN TXT +short
Expect one reconciled SPF policy and the exact public key at every domain/selector owner. Check DNS delegation and cached negative answers when a record is missing. NXDOMAIN, SERVFAIL, timeouts and inconsistent authorities require investigation; elapsed time does not correct a wrong owner. Do not infer an account status from a DNS lookup.
After activation, run an authorized, controlled test through the actual storefront event, using valid test recipients and avoiding real purchases or customer password resets. Repeat across sending domains and materially different routes. Record the instance, event and time; no such messages were sent while preparing this guide.
Read the received original through the receiving service's documented tools. Establish which Authentication-Results fields that service produced inside its known processing boundary and how it strips or treats externally supplied fields. If unclear, ask the receiving administrator. A familiar authserv-id or header position is not proof; ignore attacker-supplied and otherwise untrusted results. Result-field security.
Require the intended branded From, the expected B2C signature with passing DKIM and matching d=/s=, alignment under the effective policy and trusted dmarc=pass. A provider-rewritten From, unrelated signature or DMARC pass through SPF alone does not prove this DKIM setup works. Independently assess actual smtp.mailfrom and SPF: investigate fail, softfail, neutral, none, temperror and permerror even if DKIM rescues DMARC. Inbox placement is a separate observation, not an authentication guarantee.
Troubleshooting, rotation and rollback
- Post-migration domain-validation error: confirm Hyperforce/UMS. Follow its domain-approval and issued-DNS workflow, not this POD recipe. Do not overwrite an existing bounce hostname claimed by another service.
- Imported key but unsigned message: confirm Enable DKIM, selected alias, selector and Apply on the actual sending instance; then confirm the message did not use custom SMTP.
- Only one storefront fails DKIM: check the exact sending subdomain's TXT owner and message selector. A shared key does not create missing domain records automatically.
- DKIM fails after a key change: compare the active private/public pair, caches and selector. Do not publish a second conflicting key at the same owner.
- SPF fails only in testing: verify the actual production-realm authorization for the documented POD route and the evaluated envelope domain. Staging origin does not imply staging SMTP egress.
For rotation, use a new selector, publish its public key at every affected domain and wait for verified visibility before switching the single active instance pair. Retain the old public records while queued mail and dependent instances still require them; this guide does not invent a universal retirement interval. Coordinate rollback by restoring the last verified instance key/selector and only affected DNS records, checking intervening edits. Do not remove shared keys or restore an entire zone.
Source dates and verification limits
No publication date is invented for undated manuals. Primary bodies and both instance/storefront diagrams were inspected. Key generation, private-key import, account changes, DNS edits, actual sends, visual CMS rendering, live publication, indexing and rankings were not tested.