Salesforce: DKIM and DMARC alignment across the clouds

<selector1>._domainkey.example.com.  CNAME  <selector1>.<key>.dkim.sfdc.net.
<selector2>._domainkey.example.com.  CNAME  <selector2>.<key>.dkim.sfdc.net.

DMARC alignment rests on DKIM

DMARC only validates a message if SPF or DKIM passes and aligns with the From domain. For each properly configured Salesforce cloud, it is DKIM that carries alignment: the d=example.com signature (Sales/Service) or the SAP subdomain's (Marketing Cloud) aligns with the From domain, in relaxed mode for a subdomain, in strict for the domain itself.

SPF is trickier. Depending on the bounce-management configuration, the envelope of Salesforce messages may stay on a platform domain, in which case SPF passes without aligning — and does not count. Relying on DKIM is therefore the reliable and recommended choice for Salesforce. The records broken down line by line show how to set the _dmarc instruction once the clouds are authenticated. Under DMARCbis, the reference organisational domain is determined by the DNS tree walk, with no change to this reasoning.

One DMARCbis detail follows from the subdomain approach. Because Marketing Cloud and some setups send from subdomains (mkt.example.com), the sp= tag — the policy applied to subdomains — governs how strictly those sends are treated when they lack their own record. Leaving sp unset means subdomains inherit the main p= policy; setting it explicitly lets an organisation, for instance, keep the apex at p=reject while a subdomain still finishes its rollout. It is a lever worth knowing when several clouds come online at different times, and it avoids an all-or-nothing choice during a staged migration.

The ten-DNS-lookup budget of SPF

A trap specific to Salesforce deserves its own section. Many guides recommend adding include:_spf.salesforce.com to the domain's root SPF record. But this include is heavy: it nests others, and consumes on its own several of the ten DNS lookups SPF allows before flipping to permerror. Combined with other services (an office suite, an ESP), it quickly exceeds the ceiling — and a permerror invalidates SPF for the whole domain, including the mail that did align.

Two practical consequences. First, adding this include does not align SPF anyway if the envelope stays on a Salesforce domain: one pays the cost without the benefit. Second, when SPF is not the chosen alignment mechanism (and it is not, here, in favour of DKIM), the Salesforce include is often superfluous. Watching the ten-DNS-lookup limit is all the more useful in a Salesforce environment because the temptation to stack includes runs high there.

The Marketing Cloud subdomain

The Marketing Cloud's Sender Authentication Package deserves a pause, as it is the most complete configuration of the Salesforce clouds. The SAP provisions a dedicated sending subdomain — often of the form mkt.example.com — that becomes the campaigns' sending domain: SPF, DKIM signature and the link-tracking domain are all attached to it. Alignment there is therefore double, SPF and DKIM, in relaxed mode toward example.com, which brings the redundancy that protects in case of forwarding.

This completeness has a counterpart: the SAP is configured once, and its dedicated subdomain must stay reserved for the Marketing Cloud. Mixing it with other uses, or changing subdomain without redoing the configuration, breaks the whole. For an organisation broadcasting at scale, it is nonetheless the most solid foundation — and the most legible in the reports, where the subdomain appears as a clean, aligned source, easy to tell apart from Sales/Service traffic.

Email Relay and bounce management

Two Salesforce settings touch authentication indirectly and are worth knowing. The first, Email Relay, routes Salesforce mail through the organisation's SMTP server before delivery: in that arrangement, the email leaves the internal infrastructure, inherits its SPF and reputation, and alignment is then reasoned about like any in-house server — a different case from direct sending by Salesforce. The second, bounce management, determines the envelope domain of messages: depending on whether it is enabled, the Return-Path leans toward a Salesforce domain or the organisation's, which changes SPF alignment.

These settings do not replace DKIM — which stays the reliable alignment mechanism — but they explain why two organisations on Salesforce may see different SPF results in their reports. Understanding which is in place avoids hunting for an SPF alignment defect where there is only a bounce-configuration choice.

Common configuration mistakes

Several traps recur in the body of reports the free DMARC analyzer processes daily.

Authenticating only one cloud. The most frequent: DKIM set for the Sales Cloud, Marketing Cloud or Pardot forgotten — the latter fail DMARC under a strict policy.

Generating the key without activating it. In Setup, a DKIM key created but left inactive signs nothing; the domain appears configured, the messages are not signed.

Stacking the Salesforce SPF include needlessly. Described above: cost in lookups, risk of permerror, without alignment benefit when it is DKIM that aligns.

Tightening before everything is covered. Moving to p=reject believing Salesforce authenticated while a cloud still sends without an aligned signature means rejecting part of one's own business traffic.

The final proof: RUA reports

The only proof that a configuration holds is not the Setup screen, but what recipients report. Once a _dmarc record is published with a rua= address, aggregate reports arrive within a few days and detail, source by source, what aligns and what fails. Reading the aggregation reports, read in detail is particularly valuable here, because it reveals each Salesforce cloud as a distinct source: one sees at a glance whether the Sales Cloud, Marketing Cloud and Account Engagement all align, or whether one still fails.

A simple cadence is enough: a first read a few days after configuration, once several recipients have reported, then a weekly glance while the policy stays at p=none. It is the confirmation that all sending clouds align that licenses tightening — a single unaligned cloud is reason enough to wait. Once that complete coverage is observed over several days, the move to p=reject carries no risk. The online analyzer reconstructs this state from the published records and the reports received, and places the domain on the path that leads to p=reject.