How to add DKIM record for owned domain in Salesforce Marketing Cloud (SFMC)?
Published 26 Apr 2025
Updated 6 Oct 2026
15 min read
Summarize with
Updated on 6 Oct 2026: We updated the SFMC DKIM setup steps for verified From addresses, sender profiles, and message-level authentication checks.
To add a DKIM record for an owned domain in Salesforce Marketing Cloud Engagement, configure authenticated sending through a Private Domain or Sender Authentication Package (SAP). Publish the DNS records SFMC supplies, or delegate the relevant domain or subdomain to Salesforce.
DKIM has a private key and a public key. SFMC must hold the private key to sign messages, while DNS publishes the matching public key. Creating your own DKIM key pair outside SFMC does not make SFMC use it.
- Direct answer: Configure a Private Domain or SAP domain in SFMC, then publish the supplied DNS values.
- Main caveat: An available Private Domain or SAP entitlement is required for authenticated sending.
- What to avoid: Do not treat Registered Domain or a self-generated DKIM key as SFMC authentication.
Private Domain, SAP, and Registered Domain
In SFMC, an owned domain still has to be authenticated by the SFMC sending infrastructure. Owning example.com gives you the right to publish DNS records, but it does not give SFMC the private key needed to sign as that domain. The sender and DNS have to be paired.
Which option enables DKIM?
- If you need DKIM pass: Configure a Private Domain or SAP domain for authenticated sending.
- If you need DMARC pass: Make sure the DKIM d= domain matches your visible From domain under your DMARC domain matching mode.
- If you need tracking branding: Use SAP rather than an authentication-only Private Domain.
- If New Domain is disabled: Check account entitlements and contact Salesforce for the missing license or supported setup path.
|
|
|
|
|---|---|---|---|
Private Domain | Zone file or delegation | Yes | Email authentication |
SAP | Zone file or delegation | Yes | Authentication and branding |
Registered Domain | Ownership TXT token | No | From-address verification |
Own key | Your values | No | Other sending systems |
SFMC domain options and their authentication scope.
Register Domain verifies domain ownership, and Add Email Address adds a From address under a verified domain. Neither option enables DKIM signing. For SFMC DKIM, From Address Management must list the authenticated domain with type SAP or Private.
Do not confuse SFMC domain authentication with the core Salesforce Create a DKIM Key flow. That flow applies to email sent by the core Salesforce platform. Marketing Cloud Engagement uses its SAP and Private Domain configuration.
Salesforce Marketing Cloud Engagement sending domain records with DNS, DKIM, and SPF status.
Why your own DKIM key will not work by itself
DKIM works when the sender creates a DKIM-Signature header and the receiver can use DNS to find the matching public key. The header names a signing domain in d= and a selector in s=. The receiver then queries s._domainkey under that signing domain.
That is why the private key matters. If SFMC signs as a Salesforce-controlled domain, your owned domain DNS record is irrelevant for that signature. If you want SFMC to sign as your owned domain or a subdomain of it, SFMC needs its own approved key material or hosted signing path for that exact domain. This is also why DKIM setup can look complete in DNS while messages still fail, which is covered in more detail in custom domain signing.
What you control
- DNS zone: You publish the SFMC zone-file records or delegate the chosen domain or subdomain.
- Domain choice: You choose root domain use, subdomain use, and sender addresses.
- Policy: You set DMARC policy and reporting destinations for self-hosted DNS.
- Other senders: You keep their selectors separate from the selector SFMC uses.
What SFMC controls
- Signing key: SFMC holds or manages the private key used for outbound signing.
- Header output: SFMC sets the DKIM-Signature domain and selector on sent mail.
- Verification: SFMC validates that your DNS matches the supplied domain configuration.
- Product access: SFMC exposes configuration options according to SAP and Private Domain entitlements.
The private key is the deciding factor
Publishing a DKIM public key without the matching sender-side private key is like publishing a lock without giving the sender the key that fits it. Receivers will not see a valid SFMC signature for that selector unless SFMC signs with the matching private key.
SFMC DKIM flow from private-key signing through DNS verification and DMARC domain matching.
Choose the SFMC authentication option
Configure the owned domain or subdomain for authenticated sending. If the account has an available entitlement, start in Domain SSL Certificates. If New Domain or the needed option is disabled, contact the Salesforce account team or Support about the missing license or supported account path.
Define the scope before configuration. Name the exact From domain, the Business Unit that will send, whether Reply Mail Management is in use, whether DNS will stay self-hosted, and whether link and image branding should use the same domain. Those details decide whether Private Domain is enough or SAP is required.
- Check entitlements: Confirm whether SAP, Private Domain, and required SSL capacity are available.
- Choose the function: Select email authentication only or email authentication with URL branding.
- Obtain DNS values: Use the downloaded zone file or the delegation instructions for that account.
- Verify sending: Wait for Active status, send a campaign test, and inspect the authentication headers.
Private Domain
Use Private Domain when the requirement is authenticated sending from an owned domain or subdomain. It is a paid authentication-only option, does not include a dedicated IP, and can use a shared or existing IP configuration.
- Best fit: You need DKIM and SPF authentication for a sending domain.
- Limit: It does not brand link, image, or view-as-webpage domains.
Sender Authentication Package
Use SAP for authenticated sending plus branded links, images, and view-as-webpage URLs. Salesforce requires SAP for customers sending more than 250,000 email messages per month.
- Best fit: You need domain authentication and account-level URL branding.
- Limit: An available SAP entitlement and enough SSL certificate capacity are required.
Configure the domain in SFMC
SAP and Private Domain configuration starts in Setup. The exact choices shown depend on the account's purchased entitlements and current IP configuration. Follow Salesforce's domain setup instructions for the supported configuration options.
- Open domain settings: In Setup, enter "ssl" in Quick Find and select Domain SSL Certificates.
- Start the domain: In Sending Domain Records, click New Domain and enter the owned domain plus a notification address.
- Select the scope: Choose email authentication only for Private Domain, or email authentication and URL branding for SAP.
- Set sending options: Choose the available IP configuration. The setup wizard offers Reply Mail Management when email authentication and URL branding are selected.
- Choose DNS management: Select Salesforce delegation or self-hosted DNS, review the configuration, and submit it.
- Publish the records: For self-hosted DNS, use Download Zone File from the domain action menu and apply every required record.
Track progress in Sending Domain Records. Do not use the domain for production sending until SFMC marks it Active.
|
|
|
|---|---|---|
Pending DNS validation | Required DNS is not validated | Check every supplied record |
In progress | DNS was detected and setup continues | Allow up to five business days |
Active | Domain is ready | Run external test sends |
Statuses shown during SFMC sending-domain configuration.
Use tenant-specific DNS records for Hyperforce
Salesforce's standard DNS record maintenance examples do not apply to Hyperforce. Salesforce supplies account-specific DNS entries later in the setup process, so use the records supplied for your Hyperforce tenant.
DNS records to publish
For self-hosted DNS, download the zone file from the Sending Domain list and publish all required entries. The file can include DKIM, SPF, DMARC, bounce, reply, and service records according to the selected configuration. Preserve the supplied hostnames and record types. Keep only one SPF TXT record per hostname, merging authorized senders when an SPF record already exists.
The DKIM record in the standard self-hosted pattern is a TXT record at the selector under _domainkey. The selector is stack-specific and can change during key rotation, so use the value in the zone file rather than copying a selector from another account. Confirm the active selector in a recent message using Salesforce's DKIM selector instructions.
Illustrative SFMC DKIM TXT pattern, not a usable keyDNS
selector._domainkey.email.example.com. TXT "v=DKIM1; k=rsa; p=MIIB..."
Long DKIM public keys are often displayed as multiple quoted strings by a DNS interface. They still need to resolve as one logical TXT value. If DNS is delegated, Salesforce maintains the records within the delegated zone and you publish the supplied NS delegation instead.
Publishing checklist
- Host field: Check whether your DNS host automatically appends the zone name.
- Record set: Apply every required entry in the SFMC zone file, not only DKIM.
- Selector: Use the SFMC-supplied selector and keep other senders on separate selectors.
- Propagation: Allow DNS propagation according to record TTLs and cached answers, then confirm public DNS resolution and SFMC validation.
For a new DMARC deployment, start with monitoring until SFMC and all other legitimate senders authenticate correctly. If the domain already uses quarantine or reject, validate the new SFMC configuration before sending and retain the existing policy. The example below uses a reporting mailbox that must be configured to receive aggregate reports.
Example DMARC monitoring recordDNS
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Select the authenticated domain in sender profiles
An Active domain still needs to be selected for the sends that use it. Check the authenticated domain in each sending Business Unit. A Private Domain can be used in another Business Unit once it is added there as an authenticated domain in From Address Management; contact Salesforce Support if it is missing.
- In the sending Business Unit, open Setup > Feature Settings > Email Studio > From Address Management. Confirm the domain type is SAP or Private and the intended From address is verified.
- In Setup, search for "profiles" and open Sender Profiles. Create or edit the sender profile, set its From email to an address on the authenticated domain, verify it if prompted, and save.
- Select that sender profile in the send classification used by the campaign. Check the classification used by Journey Builder and Automation Studio sends as well.
- Send to an external mailbox using the same sender profile and classification as production. For dynamic From addresses, also test the resolved address and verified fallback address.
Salesforce documents sender profile configuration, send classification setup, and Private Domain sharing.
New From addresses require a verified domain
Since October 4, 2026, Salesforce has disabled verification emails for new From addresses on unverified domains in affected accounts that created User Domains since February 1, 2026. Establish a verified domain through SAP, Private Domain, or Register Domain before adding new addresses. Previously created From addresses require no action under this retirement. Register Domain still does not enable DKIM. See Salesforce's User Domain retirement notice.
Verify DKIM in DNS and message headers
After DNS is published, validate two separate things. First, confirm that SFMC shows the sending domain as Active and that the supplied DKIM record resolves. Second, send a real SFMC message to an external mailbox and confirm the message has a DKIM-Signature header where the signing domain is your owned domain or intended subdomain.
For the DNS side, use our Suped DKIM checker to confirm the selector is visible and the record syntax is valid. Our domain health check helps catch nearby SPF, DMARC, and DNS issues before a production campaign.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
For the message side, inspect Authentication-Results and DKIM-Signature in a recently delivered email. Confirm DKIM pass, the expected d= domain, and the active s= selector. Then confirm DMARC pass. A forwarded message generally retains a valid DKIM signature if its signed content is unchanged; modifications to signed content can break it. Test more than one external destination before escalating an isolated failure, and include the failed message's full headers, sending Business Unit MID, From domain, and selector in a Salesforce Support case.
A pass in DNS is not a pass in mail
A DKIM DNS lookup can succeed while SFMC messages still use a different signing domain. Always test a real message. The DNS record proves the public key is available; a trusted receiver's dkim=pass result proves the received signature verifies with that key. A DKIM-Signature header by itself does not prove authentication passed.
When to use a subdomain
A dedicated sending subdomain such as email.example.com or news.example.com separates marketing DNS and bounce handling from corporate mail while retaining the organizational-domain relationship to the brand. It supports a distinct sending reputation, but mailbox providers also assess the organizational domain, so reputation is not fully isolated.
Using the root domain can work, but it raises coordination risk when multiple systems send mail. If another sender already uses DKIM on the root domain, SFMC needs a different selector. If reply handling or bounce handling changes, the root domain becomes harder to manage. This is a common source of SFMC DKIM failures after a migration.
|
|
|
|---|---|---|
Root domain | Keep corporate-domain DNS self-hosted | Coordinate SFMC records with corporate mail and other senders |
Sending subdomain | Self-host or delegate only the sending subdomain | Manage marketing records in a separate DNS zone |
How root domains and subdomains compare for SFMC authentication.
DMARC needs at least one passing DKIM or SPF result whose domain matches the visible From domain under the configured mode. With relaxed DKIM matching, a message from brand.com can pass DMARC using a valid DKIM signature under email.brand.com. With strict DKIM matching, the signing domain must match the visible From domain exactly. Check the adkim setting before configuring the SFMC domain. These domain-matching rules are defined in RFC 9989.
Check multi-bounce domain when brands differ
If a Private Domain uses a different organizational domain from the SAP domain, the default Envelope From can remain under the SAP domain. SPF can pass but fail DMARC domain matching. Verify the required bounce-domain MX and SPF records before requesting multi-bounce domain support for the sending MID. After Salesforce enables it, retest each Private Domain. A passing DKIM signature with a matching domain is sufficient for DMARC even while SPF domain matching is being corrected.
DMARC rollout for a new deployment
For a new DMARC deployment, validate every legitimate sender before enforcing a policy. Retain existing enforcement when adding SFMC to an authenticated domain.
Monitor
p=none
Publish records, collect reports, and test real messages.
Limit
p=quarantine
Move only after SFMC and other senders are consistently passing.
Enforce
p=reject
Use after legitimate sources are authenticated; failed unauthorized mail can be rejected.
How Suped fits into the workflow
Suped is our DMARC and email authentication platform. SFMC supplies the domain configuration and signs the mail, while Suped uses available DMARC aggregate reports to show how receivers evaluate SFMC authentication after the DNS change.
In Suped, the DMARC monitoring workflow groups aggregate report data by sending source, separates expected SFMC traffic from unknown sources, and tracks authentication changes during rollout.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
That matters during SFMC authentication work because the failure can be subtle. A DNS record can be present while the message signs with the wrong domain, misses DMARC domain matching, or comes from a Business Unit that was not included in the domain setup.
Manual validation
- Header checks: Useful for single test messages, but limited for ongoing monitoring.
- DNS checks: Confirm syntax but do not prove real SFMC signing behavior.
- Team process: Requires repeated reviews when domains, selectors, or Business Units change.
Suped workflow
- Issue detection: Surfaces DKIM, SPF, and DMARC failures with sending-source context.
- Change tracking: Shows whether SFMC authentication improves after DNS or account changes.
- Source coverage: Helps review expected SFMC traffic and unknown sources in DMARC aggregate reports.
Views from the trenches
Best practices
Check SFMC entitlements and the exact authentication option before changing production DNS.
Use unique DKIM selectors per sender so root-domain mail systems do not collide later.
Validate real SFMC message headers, not only DNS lookups, before tightening DMARC policy.
Common pitfalls
Teams publish a self-made DKIM key, then assume SFMC can sign with a key it never received.
Registered Domain gets mistaken for authentication even though it only verifies ownership.
Root-domain changes get rushed, then another mail source breaks because selectors overlap.
Expert tips
Treat Private Domain and SAP as product-scope choices, not only DNS record formats.
Keep SFMC marketing mail on a subdomain when corporate mail already uses the root domain.
Open DMARC reports during rollout so failed sources are visible before enforcement starts.
Marketer view
Marketer from Email Geeks says SFMC usually provides the DKIM path after Private Domain or Sender Authentication Package setup, so the missing option in Setup is expected.
2024-04-01 - Email Geeks
Marketer view
Marketer from Email Geeks says owning the domain is not enough because SFMC must sign with the private key that matches the public key in DNS.
2024-04-01 - Email Geeks
SFMC DKIM setup checklist
Before production sending, confirm the Private Domain or SAP is Active, the supplied DNS records resolve, and the sender profile uses the authenticated From domain. Test the same send classification as production and confirm DKIM and DMARC pass at external receivers.
If an existing SFMC Private Domain fails authentication, check the current selector and signing domain in a failed message, confirm its Business Unit scope, and compare public DNS with Salesforce's supplied records. Monitor receiver-reported results after correcting the configuration.
Frequently asked questions
No. SFMC must sign the message with the matching private key. A DNS-only DKIM record does not make SFMC use that selector.
No. Registered Domain verifies domain ownership for From-address use. Authenticated sending requires SAP or Private Domain.
Not always. Private Domain supports email authentication only. Use SAP when you also need branded links and image URLs, or when Salesforce requires it for the account's sending volume and configuration.
Yes. Use different DKIM selectors for each sender, or use separate subdomains to reduce operational risk.
A passing DKIM signature does not satisfy DMARC if its signing domain does not match the visible From domain under the configured mode and SPF provides no passing, matching result. Modification of signed content explains a DKIM failure, rather than a DKIM pass with a DMARC failure.
A sending subdomain makes marketing DNS changes and bounce handling easier to manage separately from corporate mail. It supports a distinct sending reputation, but mailbox providers also assess the organizational domain.
