How to set up DKIM keys in Salesforce

To set up DKIM keys in Salesforce, open Setup, search for DKIM Keys, and click Create New Key. Choose 2048-bit RSA, enter unique primary and alternate selectors, enter the exact sending domain and domain match pattern, then save. Salesforce generates two account-specific CNAME records. Publish both in DNS, wait for Salesforce to detect them, and activate the key. Never copy selectors or CNAME targets from another org or from an online example.

What should I check before configuring Salesforce?

This guide covers email sent by the Salesforce platform from a domain you own. It does not cover Marketing Cloud, Marketing Cloud Advanced, Gmail or Microsoft 365 integrations, Einstein Activity Capture, or mail sent from a Salesforce-owned domain. Salesforce lists those as separate or exempt sending paths in its current email-sending domain requirements.

You need the Customize Application permission to manage DKIM keys and access to the authoritative DNS zone for the sending domain. Identify every domain and subdomain that can appear after the @ in a Salesforce From address. Salesforce requires a separate key for each one, and an active key verifies domain ownership only when the key domain matches the full From domain.

If selectors, signing domains, and DNS delegation are unfamiliar, review the DKIM overview before changing production DNS.

Salesforce now requires domain-level and user-level verification for most platform email. The Spring 2026 domain-verification notice says an active DKIM key or a verified Authorized Email Domain can satisfy the domain-level requirement. DKIM is the useful choice here because it also signs outbound messages.

Copy DNS values from the Salesforce org and sending domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another org or from an online example.

Which setup method should I use?

Use Salesforce's standard secure DKIM workflow unless a documented application requires something different.

Key size. Select 2048-bit RSA. Salesforce's current Create a DKIM Key instructions recommend 2048-bit unless a specific application requires a smaller key.

Selectors. Create two unique selector names: a primary selector and an alternate selector. Salesforce permits up to 62 letters, digits, and hyphens, beginning with a letter or number. Use names that are unique across your production and sandbox orgs.

Domain match pattern. For a domain you own, use the exact domain as the match pattern. Salesforce no longer recommends wildcards for owned domains. Create a separate key for a subdomain such as mail.example.com.

How do I configure DKIM keys in Salesforce?

1. Open the DKIM Keys page

In Salesforce Setup, enter DKIM Keys in Quick Find and select DKIM Keys. Review the existing list before creating anything. A selector must be unique for the domain, and an active key may already own the sending path.

2. Create the primary and alternate selectors

Click Create New Key, select 2048-bit, and enter:

• a unique Selector;
• a different Alternate Selector;
• the exact sending Domain; and
• the Domain Match Pattern that Salesforce must match before signing.

3. Publish both generated CNAME records

After saving, Salesforce publishes its side of the key pair and generates a primary CNAME and an alternate CNAME for your domain. Salesforce says this usually finishes within 15 minutes. Open the selector from the DKIM Keys list and copy both host and target values exactly as your org displays them.

Your records will have this structure. The values below are Salesforce's documentation example and are illustrative only:

example-sf-a._domainkey.example.com. 3600 IN CNAME example-sf-a.k4tyd2.custdkim.salesforce.com.
example-sf-b._domainkey.example.com. 3600 IN CNAME example-sf-b.e6mxu6.custdkim.salesforce.com.

Do not publish those example records. Publish the two names and targets generated by your own Salesforce org. Follow your DNS provider's rule for host names: some providers append the zone automatically, while others expect the full name.

4. Activate the key after DNS resolves

Return to the key details page after both CNAME records resolve publicly. Salesforce can take up to 72 hours to detect DNS changes. Reload the DKIM Keys list, open the selector, and click Activate when the control becomes available.

An inactive key does not sign mail. If Activate remains unavailable, compare both public CNAME answers with the exact targets in Salesforce before regenerating anything. Salesforce's current activation troubleshooting article treats missing, proxied, or mismatched CNAME answers as the first checks.

5. Send a real message through the same Salesforce path

Send a message from the configured Salesforce From domain to a mailbox outside the org. Use the same user, organization-wide address, Flow, or automation path that matters in production. A generic deliverability test does not prove that this From domain used the selector you configured.

Investigate this with your coding agent

Use this handoff only after Salesforce has generated both CNAME records and your authoritative DNS zone is managed in a repository. Replace every sample token with the values from your own org; do not paste credentials or private keys.

How does this setup affect DMARC?

DKIM passing and DMARC passing are different checks. RFC 6376 defines how a receiver verifies the signature against the selector's public key. RFC 9989 additionally requires the signing d= domain to align with the visible From domain for DKIM to satisfy DMARC.

An active Salesforce key can verify ownership for Salesforce's sending requirement, but that status does not prove that a specific message passed DKIM or aligned for DMARC. Inspect a delivered message and compare header.d with header.from. Use Palisade's DMARC checker to read the published policy before changing enforcement.

Salesforce rotates an active DKIM key every 30 days. Its DKIM considerations explain that the alternate key is published before rotation and then becomes active. Keep both CNAME records in DNS so rotation does not break verification. The DKIM key-rotation guide explains how that provider-managed model differs from a manual new-selector cutover.

How do I validate the setup?

Check public DNS

Query both selectors, not just the primary one:

dig CNAME <primary-selector>._domainkey.example.com
dig CNAME <alternate-selector>._domainkey.example.com

Each answer should match the corresponding custdkim.salesforce.com target shown in your org. The Palisade DKIM checker can inspect a known domain and selector through public DNS. A public lookup cannot see the Salesforce activation state or prove that a production message was signed.

Check the Salesforce status

Open Setup > DKIM Keys and open the selector. Confirm that the key is active and both generated records remain present. This establishes Salesforce's configuration state. It does not establish the headers on a delivered message.

Inspect a delivered message

Open the full headers of the test message. RFC 8601 defines the Authentication-Results field. Look for dkim=pass, then compare the reported selector and signing domain with the Salesforce key and visible From domain:

Authentication-Results: mx.example.net;
       dkim=pass header.d=mail.example.com header.s=<your-selector>;
       dmarc=pass header.from=mail.example.com

Treat those values as message-specific evidence. A different Salesforce sending path or From domain can produce a different result.

Review DMARC aggregate reports

A single message proves one path at one time. RFC 9990 defines DMARC aggregate reports, which summarize authentication and alignment results by source across a reporting window. Use them to confirm that Salesforce mail continues to pass after activation and key rotation and to separate Salesforce from other systems using the domain.

Troubleshooting

The Activate button is unavailable

Query both CNAME hosts publicly and compare their targets with Salesforce. Remove DNS proxying from the CNAMEs when your provider supports it, correct doubled zone names, and wait for propagation before creating another key.

Salesforce shows Publishing in progress

Salesforce has not finished publishing its side of the key yet. Its setup page says the generated records usually appear within 15 minutes. Reload the list and selector after that window.

DKIM passes but DMARC fails

Compare the delivered message's header.d and header.from. If they do not align under the domain's DMARC mode, changing the public key will not solve the alignment problem. Confirm that the Salesforce key domain and match pattern cover the exact From domain.

Mail still cannot be sent after DKIM activation

Check the separate user or organization-wide address verification state and confirm the message is not using an excluded sending path. Salesforce's 2026 rules require both domain-level and user-level verification in most cases.

Check both Salesforce selectors before activation

Run the sending domain and each Salesforce selector through the Palisade DKIM checker before you activate the key. Compare the public CNAME answer with the value shown in Salesforce.

The checker confirms what public DNS returns for the selector. It cannot activate Salesforce, prove that a production message was signed, confirm DMARC alignment for that message, or monitor future key rotations.

For the ongoing view across every sending source, Palisade's DMARC Agent processes incoming DMARC reports and creates actionable tickets when it detects an authentication issue. Each ticket identifies the affected source and recommends a course of action; your team reviews the evidence and applies any fix. Start with Palisade