When Salesforce sends as your domain: how DMARC alignment can fail

That new mail stream must pass DMARC through at least one aligned authentication mechanism: SPF or DKIM. A message can pass SPF, DKIM, or both and still fail DMARC if neither authenticated domain aligns with the domain the recipient sees.

First determine which system is actually sending

“Salesforce integration” can describe materially different architectures. A user may send from Outlook or Gmail while Salesforce only logs the message; Salesforce may generate notifications directly; or Salesforce may generate mail and route it through Microsoft 365 or another relay. The first arrangement may not create a new external sending path at all. The other two can.

Before changing DNS, inspect a representative message as received by an external mailbox. The final headers—not application settings alone—show which system originated the message, which systems relayed it, and which domains were authenticated.

What “alignment” means

DMARC evaluates whether the domain visible to the recipient aligns with at least one authenticated identity. SPF authenticates the envelope sender; DKIM authenticates the signing domain in the message header. DMARC then compares those authenticated domains with the visible From domain.

That distinction matters because a message can pass SPF or DKIM and still fail DMARC. The underlying check may succeed for a Salesforce or service-provider domain while the visible From address uses your organization’s domain.

DMARC passes when at least one aligned path succeeds. Under relaxed alignment, the domains may be different subdomains of the same organizational domain; under strict alignment, they must match exactly.

Do not change SPF until you inspect the Return-Path

A common response to a Salesforce delivery problem is to add another provider entry to the organization’s SPF record. That may be unnecessary—and may not correct DMARC at all. SPF is evaluated against the SMTP MAIL FROM domain, not simply the domain displayed in the visible From: address.

For example, if the visible From domain is example.com but the Return-Path uses provider.example, SPF may pass for the provider while failing DMARC alignment withexample.com. Adding that provider to the SPF record forexample.com does not create alignment unless the message actually uses an aligned domain in MAIL FROM.

SPF also permits no more than ten DNS-querying terms during an evaluation. Adding an unnecessary provider include can consume limited lookup headroom without solving the alignment problem.

If policy is still at p=none, unaligned traffic may remain invisible to users while appearing in aggregate reports. At quarantine or reject, legitimate unaligned mail faces materially greater delivery risk.

Common causes after an integration

• The service is sending with a Return-Path or envelope-sender domain that has not been authorized or aligned.
• DKIM signing is not enabled for the organization’s sending domain, or the required DNS records were not published correctly.
• SPF authorization was added for one sending path but not another, leaving a vendor, relay or legacy path outside the record.
• A change to the visible From address altered the alignment result even though the sending platform itself did not change.

What actually needs to happen

• Confirm the current SPF lookup count and understand the available headroom before adding another sender. If there is no headroom, restructure the record first.
• Configure DKIM signing under your own domain for the third-party sender where the platform supports it, rather than relying on a default provider domain.
• Review DMARC aggregate reports specifically for the new sending path before and after rollout—not merely whether mail still sends.
• Make DNS and authentication review a required step in integration projects, with a clear owner for the DMARC policy.

How to diagnose the problem safely

Start with evidence rather than policy changes. Send representative messages for each Salesforce function that produces external email, then capture complete headers from an independent mailbox.

Record the visible From domain, Return-Path or MAIL FROM domain, sending IP, DKIM d= and s= values, SPF, DKIM, and DMARC results, and the systems shown in the Received chain. Compare those samples with aggregate reports before establishing an aligned SPF or DKIM path.

Why this gets missed

The Salesforce integration project and the DMARC policy often belong to different people and different timelines. The person validating the integration is checking that mail sends and threads correctly; they may not be reviewing aggregate reports for alignment.

A small pilot can also appear successful before enough reporting data exists to reveal the new sender path. That is why authentication review belongs in the integration project itself, before organization-wide rollout.

Why enforcement should be staged

Moving directly to a reject policy can interrupt legitimate mail if an unknown sender has not yet been identified. A safer sequence is to inventory the sending paths, correct SPF and DKIM, review reporting data, and tighten the policy only after legitimate traffic is accounted for.

The objective is not merely to make one integration pass a test. It is to make the sending architecture understandable, documented and resilient when the next vendor or platform is added. The mail platforms may be operating correctly; the gap is often that nobody evaluated what the combination did to alignment.