Salesforce SPF, DKIM and DMARC setup, step by step

For email sent directly by Salesforce CRM, create a DKIM key in Setup → DKIM Keys, publish both CNAME records generated for your org and domain, then activate the key. Review SPF separately: include:_spf.salesforce.com authorizes Salesforce infrastructure when your domain is the envelope sender, but it cannot align a Salesforce-owned Return-Path with your branded From address. Validate a new delivered message before calling the route authenticated.

This guide covers Salesforce platform email, including the distinction between direct sending and external delivery routes. Marketing Cloud Engagement and Account Engagement have separate authentication workflows.

Choose the sending route before editing DNS

Salesforce's email setup comparison distinguishes Send through Salesforce, Gmail, Office 365, and Email Relay. The interface where someone composes a message does not necessarily identify the service that delivers it.

• Send through Salesforce: Use this guide's org-generated DKIM configuration and inspect the envelope identity before changing SPF.
• Send through Gmail or Office 365: Authenticate the connected mailbox provider. Some automated messages still leave through Salesforce or Email Relay, so a passing manually composed message does not cover workflows.
• Email Relay: Inspect both Salesforce signing and the final relay's SPF/DKIM configuration. A gateway that changes signed content can invalidate an upstream signature.
• Marketing Cloud or Account Engagement: Stop here and use that product's own domain setup. Do not reuse CRM selectors, Salesforce Marketing Cloud private-domain instructions, or another org's DNS targets.

Make a small route inventory: org, production or sandbox, business event, visible From domain, actual sending service, and administrator responsible. Include scheduled workflows and organization-wide addresses, not just individual users.

Confirm edition, permissions, and verification

Salesforce's DKIM overview lists Classic and Lightning Experience, excluding Database.com and Starter. Its key-creation page excludes Database.com but does not repeat the Starter exclusion. If you use Starter, confirm availability in your org or with Salesforce before planning implementation. Managing keys requires Customize Application, plus cooperation from the authoritative DNS administrator.

Salesforce now requires domain-level and user-level verification. An active DKIM key can satisfy domain ownership verification when its domain exactly matches the complete From domain. Verify sending subdomains separately. A verified individual organization-wide address does not override an unverified domain.

Authorized Email Domains offers another ownership-verification path, but ownership verification alone does not create a DKIM signature. Review the address-verification requirements for users and shared addresses as well. Do not disable verification controls or enable address substitution merely to make a test appear successful.

Salesforce's verification-method guide also covers sandboxes: DKIM keys cannot be copied from production into a sandbox. Authorized Email Domains can be imported through their separate supported process, but that does not copy signing. Keep sandbox and production evidence separate.

Check the substitute-sender configuration without changing it as a workaround. For an unverified domain, Salesforce can use a selected verified organization-wide address, or an org/site-specific sfcustomeremail.com fallback when none is selected. Display name and Reply-To may stay unchanged. Experience Cloud site settings can override the org setting. Disabling substitution can instead stop mail, sometimes without a user-facing error. Diagnose the received From and the verification gap; do not accept a substituted identity as the intended brand.

Understand Salesforce SPF and alignment

SPF checks the SMTP envelope MAIL FROM domain, usually reflected in the delivered Return-Path. For a null reverse-path, the relevant HELO identity is used; do not assume the visible From supplies an SPF owner. See RFC 7208 section 2.4. DMARC compares that authenticated domain with the visible From domain. Passing SPF for a Salesforce-owned domain does not establish alignment with your business domain.

Salesforce's email security matrix shows how Bounce Management and Email Security Compliance can change the envelope sender to a Salesforce bnc.salesforce.com domain. When the envelope remains your address, your SPF policy must authorize the Salesforce sender. The documented mechanism is include:_spf.salesforce.com.

Do not turn off bounce management as a routine DNS step. That changes how your organization handles invalid addresses. A valid, aligned DKIM signature can satisfy DMARC while you retain a Salesforce-owned bounce domain. If the business specifically needs aligned SPF, have the mail administrator assess those settings and the operational trade-off, then test each affected route.

Where the include is needed, merge it into the one existing SPF TXT record at the actual envelope domain, before the terminal all mechanism. Preserve legitimate senders and the existing policy. Do not copy a full sample policy, add mx without a reason, publish a second SPF record, or replace dynamic provider authorization with a snapshot of IP addresses. RFC 7208 limits lookup-causing terms to ten during SPF evaluation, including nested includes and other evaluated DNS-dependent mechanisms, not merely ten written includes. Preserve existing qualifiers (+, -, ~, ?) and legitimate authorizations. An all mechanism makes redirect in that SPF policy ignored, regardless of order; do not append an include after all or add all to a redirect policy without reviewing its effect. Qualifiers express SPF results, not guaranteed delivery or rejection. See RFC 7208 section 5.1.

Map the TXT to the evaluated domain: an apex example.com envelope uses the editor's blank/@ owner in the example.com zone; sales.example.com uses relative sales there, or blank/@ in a separately delegated sales.example.com zone. These are explanatory names, not a claim that Salesforce uses that envelope in your org. Do not add your SPF to Salesforce's own bounce namespace.

Create the DKIM configuration

Follow Salesforce's current key-creation instructions in the intended org:

1. In Setup, search for DKIM Keys, then select Create New Key.
2. Prefer 2048-bit RSA, unless a documented application constraint requires otherwise.
3. Choose distinct primary and alternate selectors. Use an org-specific naming convention to avoid collision with other senders or sandboxes. Salesforce allows up to 62 letters, digits, and hyphens, starting with a letter or digit.
4. Enter the exact sending domain. Set the domain match pattern deliberately for that domain. Salesforce now recommends separate keys for owned subdomains rather than wildcard matching.
5. Save. Allow Salesforce to publish its public keys, then reopen the key details and obtain the CNAME Record and Alternate CNAME Record.

The domain cannot be edited after saving a key. Confirm it before creation. If the status says publishing is in progress, refresh after allowing time; do not invent targets while waiting.

Salesforce manages the private signing keys. Your DNS publishes aliases to Salesforce-hosted public keys. Never export a private key into DNS or substitute a public key generated by an unrelated online tool.

Publish both CNAMEs, then activate

Copy the complete owner and target from each field in your org. The record roles are:

These descriptions are not publishable values. The Salesforce-generated targets contain identifiers that cannot be derived safely from your company name.

Before saving, inspect how your DNS editor handles zone suffixes. If it appends the zone automatically, enter the relative owner it expects. Confirm the resulting full name does not contain your domain twice. A CNAME cannot share its owner with a TXT record or unrelated data. Resolve a collision by choosing appropriate selectors, not deleting another service's key.

For example only, PRIMARY_SELECTOR._domainkey.sales.example.com maps to PRIMARY_SELECTOR._domainkey.sales in zone example.com, to PRIMARY_SELECTOR._domainkey in a delegated sales.example.com zone, or to PRIMARY_SELECTOR in a delegated _domainkey.sales.example.com zone. Substitute the account-issued selector, not the literal placeholder. Follow the actual NS authority; a parent-zone entry below a delegation does not replace child-zone publication. Preserve existing NS delegations and coordinate with their operator. Never remove a delegation, change MX, parent nameservers or DNSSEC merely to fit this guide.

Use DNS-only aliases, not HTTP forwarding or a web proxy. At each owner, avoid conflicting TXT, A, AAAA, MX or a second CNAME. Where the DNS host offers flattening, preserve the literal issued CNAME answer. For Cloudflare, use DNS-only, turn a relevant per-record Flatten control off when available, and ensure applicable whole-zone flatten-all behavior does not suppress these aliases. Coordinate shared-setting changes rather than disabling them blindly. Cloudflare documents mandatory apex and same-zone behavior too: if it cannot preserve the required literal answer, stop and agree a supported configuration with the DNS owner and Salesforce. Do not invent an override. See Cloudflare's flattening controls and exceptions. Preserve both records after activation. Salesforce's activation documentation describes automatic 30-day rotation using the alternate key; the alternate record is not disposable setup debris.

Once Salesforce detects the public records, refresh the key details, use Activate and confirm OK as documented, then confirm the active state. The documentation allows up to 72 hours for DNS propagation. Waiting will not fix an incorrect owner or target, so compare the actual DNS answers first.

Verify DNS and a real business event

Use these read-only command shapes after replacing every uppercase placeholder with an actual hostname or server. Do not run them unchanged:

dig @AUTHORITATIVE_NAMESERVER PRIMARY_CNAME_OWNER CNAME +short
dig @AUTHORITATIVE_NAMESERVER ALTERNATE_CNAME_OWNER CNAME +short
dig PRIMARY_CNAME_OWNER CNAME +short
dig ALTERNATE_CNAME_OWNER CNAME +short
dig PRIMARY_CNAME_TARGET TXT +short
dig ALTERNATE_CNAME_TARGET TXT +short
dig ACTUAL_ENVELOPE_DOMAIN TXT +short
dig _dmarc.ACTUAL_FROM_DOMAIN TXT +short

Each CNAME should return the corresponding Salesforce target. The target should resolve to a DKIM public key. A blank answer warrants investigation of the queried name, authoritative zone, record type, and propagation; it is not proof that Salesforce cannot sign. Check both selectors, including the alternate target.

Next, send an authorized, non-sensitive test through the actual business event to a mailbox where raw headers are available. Record:

• Visible From domain and Return-Path domain.
• DKIM-Signature values d= and s=.
• Trusted receiver results for dkim=pass, spf=pass, and dmarc=pass.
• Whether the passing DKIM or SPF domain aligns with the visible From.

For this branded-DKIM workflow, accept completion only when the intended Salesforce signature passes, its signing domain aligns with the originally intended visible From under the current policy, and the trusted receiver reports dmarc=pass. A rewritten provider From or a DMARC pass through SPF alone does not prove the intended brand DKIM setup works. SPF pass is useful evidence, but is not a universal requirement for that DKIM-based DMARC result.

Read Authentication-Results produced inside the receiving service's known processing boundary. Have its mail administrator identify those results using the service's documented treatment of externally supplied Authentication-Results, such as removal or isolation at ingress. Header position or a familiar authserv-id string alone is not proof: ignore attacker-supplied or otherwise untrusted fields. See RFC 8601 section 7.1. A DKIM header's mere presence is insufficient. Repeat for important workflow, user, and relay routes. Save redacted evidence with the route name and time, rather than assuming one successful message proves every org is covered.

Keep raw signature results separate from policy alignment; see raw DKIM results versus aligned DKIM policy results.

A fictional case-notification handoff illustrates the gap: cases@example.org has an Authorized Email Domain entry, but its Salesforce key is inactive because the alternate CNAME is missing. There is no delivered-message evidence yet. The Salesforce and DNS owners must reconcile both issued aliases, activate the key, then test that actual case-notification path. Domain ownership alone cannot close the signing task. No such customer test was performed here.

Keep DMARC policy changes separate

Current DMARC, RFC 9989, passes when either SPF or DKIM both passes authentication and aligns. Relaxed alignment allows the same organizational domain; strict alignment requires an exact domain match. Inspect existing adkim and aspf settings instead of automatically weakening them.

For a hypothetical passing signature, visible From cases@example.com and DKIM d=sales.example.com align under relaxed adkim=r, but not strict adkim=s. A passing d=example.com with that From matches both modes. This illustrates alignment only, not permission to configure a parent key for a separately verified Salesforce child domain. For SPF, compare the actual evaluated envelope/HELO domain independently; a child envelope may align relaxed but not strict.

Preserve direct and applicable inherited DMARC policies, alignment settings and authorized reporting destinations. Only when no applicable policy exists, the domain owner approves, and someone owns monitoring and follow-up may a first monitoring TXT look like this:

v=DMARC1; p=none; rua=mailto:YOUR_APPROVED_REPORT_MAILBOX

Replace the placeholder with the approved mailbox address only, not another mailto: prefix. This example is not ready to publish. For From example.com, full TXT owner _dmarc.example.com is relative _dmarc in that zone. For From sales.example.com, _dmarc.sales.example.com is _dmarc.sales in parent zone example.com, or _dmarc in delegated zone sales.example.com. Publish one record at the intended owner only; do not create a child monitoring record that weakens inherited protection. p=none requests monitoring, not quarantine or rejection, and cannot turn failed authentication into a pass.

If the report destination is in a different Organizational Domain from the policy domain, the report-generating receiver must check destination DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone does not establish external reporting. Coordinate any required authorization with the destination operator. See RFC 9990 section 4. This protocol check does not replace the domain owner's approval to share aggregate report data, identifiers and traffic information with that recipient.

RFC 9989 replaces RFC 7489 and removes the pct tag. Do not propose percentage-based enforcement as the rollout control. Review all legitimate services sharing the policy domain before changing enforcement, not just Salesforce.

Do not weaken established enforcement to conceal an unsigned route. RFC 9989 section 7.4 requires valid DKIM when a domain publishes p=reject; test important indirect and relay paths before any separately approved policy change.

Troubleshooting

Activate remains unavailable: Refresh the details page, compare both full CNAME pairs, check selector conflicts and duplicated domain suffixes, and verify the authoritative DNS zone. Escalate persistent mismatch with the exact public answers, not private keys.

Active key but unsigned message: Confirm the org and sending route, exact From domain, match pattern, and whether the message predates activation. A production key does not establish that a sandbox or connected mailbox uses it.

DKIM passes but DMARC fails: Compare the passing signature's d= with From under the published alignment mode. An unrelated Salesforce signature is not your branded signature.

DKIM fails only after relay: Compare an original message and relayed copy. Investigate signed-header or body modification and the relay's own signing rather than expanding SPF to repair DKIM.

SPF fails despite DKIM-based DMARC pass: Diagnose fail as failed authorization for the evaluated sender, temperror as a transient evaluation/DNS problem to investigate and retry, and permerror as an invalid policy/evaluation, such as multiple SPF records, malformed syntax or a lookup-budget breach. None is merely an alignment mismatch. Retain separate remediation even when aligned DKIM produces DMARC pass; do not expand authorization to hide a DNS error. See RFC 7208 result definitions.

Mail stops before reaching recipients: Review current domain and address verification, deliverability settings, and routing. A DNS-only check cannot prove that Salesforce generated or accepted the message.