Authorize Salesforce as a Sender and Pass DMARC

Salesforce is a sender on your domain, not your DNS host

The other guides here cover registrars and mailbox providers: where your zone lives, where your inboxes live. Salesforce is neither. It is a third party that puts your domain in the From line and sends from its own servers, with its own bounce addresses. Authorizing it is a different job from publishing a DMARC record, and it decides whether you can enforce a policy at all.

The failure is quiet. Salesforce keeps accepting sends and reports nothing wrong. What happens to a failing message is decided at the far end, by the receiving server acting on the policy you published, and the only trace you get is a line in an aggregate report.. If you moved to p=quarantine or p=reject and your Salesforce mail went cold, start here.

Work out which Salesforce you have before you touch DNS

Salesforce is several sending systems wearing one name, and they authenticate differently. Instructions for one will not work on another.

• Salesforce core, meaning Sales Cloud, Service Cloud and Platform. Mail from the Send Email action, email alerts, Flows and Apex. Authenticated with DKIM keys you create in Setup.
• Marketing Cloud Engagement. Bulk marketing sends. Authenticated through a Sender Authentication Package or the Private Domain add-on, Private Domain is a paid add-on you buy from an account executive, while every Marketing Cloud Engagement edition already includes at least one SAP license. Both are then configured in Setup, not on the DKIM Keys page..
• Marketing Cloud Next, on Growth and Advanced editions. Needs an authenticated domain built from eight CNAME records.
• Marketing Cloud Account Engagement, formerly Pardot. DKIM is a TXT record you copy from Domain Management, under Email Sending Domains, from the Expected DNS Entries link.

The envelope sender is not the From address

Every message carries two sender addresses. The envelope sender, also called the return path or MAIL FROM, is where bounces go and is what SPF checks. The header From is what your recipient reads. DMARC checks SPF and DKIM, then adds a rule that catches people out: the domain that passed has to line up with the header From domain. That match is alignment.

Now the Salesforce part. In Setup, under Deliverability, sits a checkbox called Enable compliance with standard email security mechanisms. Turn it on and your header From stays as your address, while the envelope from becomes an address at bnc.salesforce.com. Salesforce's own SPF record authorizes its mail servers, so the message passes SPF whether or not you publish anything.

Read that twice. It passes SPF for bnc.salesforce.com. Your DMARC policy is evaluated against your domain, and bnc.salesforce.com does not align with example.com, so the SPF half of DMARC fails whatever your SPF record says. An SPF checker will show you green while DMARC keeps failing, which is why this one is hard to find.

Create the DKIM key: the exact path and fields

There is no key to paste and no file to upload. Salesforce generates the pair, holds the private key, and gives you two CNAME records to publish.

• From Setup, use the Quick Find box to find and select DKIM Keys.
• Click Create New Key. The new pair starts Inactive.
• Select the RSA key size. Salesforce recommends 2048-bit unless something specific needs smaller.
• Selector: a unique string of up to 62 letters, digits and hyphens, starting with a letter or number. Salesforce's example is example-sf-a.
• Alternate Selector: a second unique string, such as example-sf-b. Salesforce uses it to rotate keys.
• Enter the domain used in your From addresses. You cannot edit it after saving.
• Domain match pattern: a comma-separated list of patterns the domain must match before Salesforce signs with this key. For a domain of example.com, use example.com.
• Save, wait around fifteen minutes, then reopen the key by clicking its selector. The CNAME Record and Alternate CNAME Record fields appear once TXT Record Status stops reading Publishing in progress.

Publish both CNAMEs, then activate

Salesforce's worked example: example-sf-a._domainkey.example.com. is a CNAME pointing at example-sf-a.k4tyd2.custdkim.salesforce.com. and example-sf-b._domainkey.example.com. is a CNAME pointing at example-sf-b.e6mxu6.custdkim.salesforce.com. The trailing dots mark the names as absolute. Check how your DNS provider expects the name, because some append your domain to whatever you type and some do not.

Then activate the key in Setup. Salesforce will not let you activate until the CNAMEs resolve, and allows up to 72 hours for DNS to propagate.

One key per domain, and one per subdomain

Domain-level verification only counts when the DKIM key's domain matches the entire domain shown in the From address. A key for example.com does nothing for mail.example.com or sales.example.com. Each domain and subdomain needs its own key.

When several active keys could match, Salesforce uses the one with the longest matching domain match pattern, and picks at random if two patterns tie. Wildcards are still accepted in that field, but Salesforce no longer recommends them for domains you own.

Domain verification is now a gate, not advice

During 2026 Salesforce turned email-sending domain verification into a hard requirement. Enforcement for previously allowlisted domains rolled out to production orgs between June 29 and July 27, 2026. Salesforce no longer delivers mail from an unverified domain, even when the individual user's address is verified.

Verification means one of two things: an active DKIM key, or a verified entry under Setup, then Authorized Email Domains. The second publishes a TXT record holding a code shaped like 00D000000000P08=1TB00000000000B, at your domain, at _sfdv.yourdomain.com, or at orgId._sfdv.yourdomain.com. Salesforce recommends the DKIM route, and rightly: an authorized email domain proves ownership and nothing more. It carries no signature, so it does nothing for DMARC.

When a send fails this check the bounce reads "550 5.7.1 Delivery not authorized, message discarded." Look for it in Email Logs in Setup. A Deliverability option called Use a substitute email address for unverified domains keeps mail moving by swapping the From address for an organization-wide address you choose, or for email@UniqueId.sfcustomeremail.com if you choose none. That is a fallback, not a fix. Your brand leaves the From line.

Does Salesforce need an SPF include, and can you afford one

It depends on that Deliverability checkbox, and Salesforce is clear about it. If you do not enable Email Security Compliance, set up an SPF record for your domain and include Salesforce in it. If you do enable it, the envelope sender is a Salesforce domain and your include contributes nothing to those messages.

The entry is _spf.salesforce.com, and Salesforce asks you to use only that one, because other salesforce.com SPF records exist for unrelated purposes. A working example from its documentation is v=spf1 mx include:_spf.salesforce.com ~all.

Now the cost. RFC 7208 stops an SPF evaluation after ten DNS-querying mechanisms and returns permerror, which is not a pass. Checked on August 27, 2026, _spf.salesforce.com contains v=spf1 exists:%{i}._spf.mta.salesforce.com -all. The include is one lookup and the exists macro inside it is a second, so Salesforce costs two of your ten. The mx in Salesforce's sample record costs a third. Count what Google Workspace, Microsoft 365 and your other senders already spend before you add it.

Return path and bounce settings, where alignment is won or lost

Core Salesforce offers no custom return path and no branded bounce domain. There is no field for it. You get two states, and Email Relay changes the picture again after that.

Email Relay changes the picture again. It routes Salesforce mail through your own SMTP server, which helps with archiving, content filtering and disclaimers. Salesforce warns that Email Relay with Bounce Management causes an SPF soft failure, because your relay's IP is not authorized for bnc.salesforce.com. Its guidance is to turn off Enable compliance with standard email security mechanisms when relaying, consider turning off Activate Bounce Management, and rely on DKIM with DMARC instead. Salesforce also states that Email Relay does not support sending through Microsoft 365 or Exchange Online to people outside your organization.

• Email Security Compliance or Bounce Management on: the return path is a Variable Envelope Return Path at bnc.salesforce.com, shaped like name@domain.com__x@x.bnc.salesforce.com. SPF passes for Salesforce and cannot align to your domain.
• Both off: the envelope from and return path are your own address, an SPF include can align, and you give up Salesforce bounce tracking.

Marketing Cloud authenticates the opposite way

Marketing Cloud Engagement does not use the DKIM Keys page, and nothing above applies to it. Authentication arrives with a Sender Authentication Package, included with every Marketing Cloud Engagement edition, or with the Private Domain add-on, which you buy from an account executive. Private Domain is authentication only and carries no dedicated IP, which Salesforce says makes it suitable for any sending volume. SAP adds branded link, image and view-as-webpage domains, and Salesforce requires it above 250,000 messages a month.

The DNS shape differs in every respect. Marketing Cloud wants its own sending subdomain, with MX records on the root and on bounce, reply and leave, CNAMEs for image, view, click, pages and cloud, an A record for mta, and DKIM published as a TXT record at selector._domainkey.yoursubdomain.example.com. A TXT, not the CNAME that core Salesforce hands you.

This is also where Marketing Cloud beats core Salesforce. Bounces go to bounce.yoursubdomain.example.com, which sits under your own organizational domain, so the return path aligns with your From domain under relaxed SPF alignment. Both DMARC checks can pass rather than DKIM alone, which core Salesforce cannot manage.

You can self-host all of that, or delegate the subdomain to Salesforce with four NS records pointing at ns1.exacttarget.com through ns4.exacttarget.com. Choose deliberately. Salesforce says its support for self-hosted DNS is limited, but delegation costs you the panel: Salesforce sets a global SPF policy and a simple DMARC policy on every newly provisioned SAP domain, and changing that DMARC record, adding BIMI or adding a verification code then goes through a support case. Salesforce also will not host DKIM keys for non-Salesforce sending platforms on a delegated domain.

Verify by reading headers, not by trusting the tick

An Active DKIM key in Setup means the CNAMEs resolve. A verified authorized domain means a TXT record was found. Neither tells you a real message aligned for a real recipient.

So send one. Trigger the send you care about, an email alert or a Flow or a Marketing Cloud test, to a Gmail address. Open it, choose Show original, and read Authentication-Results.

• dkim=pass alone is not enough. Find header.d= and confirm it is your domain or a subdomain of it. A pass on salesforce.com is a pass for Salesforce, not for you.
• For core Salesforce, expect smtp.mailfrom= to show a bnc.salesforce.com address. That is the design, and it is why the SPF result will not align.
• dmarc=pass is the line that matters. In that configuration only DKIM can produce it.
• Test each system separately. A passing Sales Cloud alert tells you nothing about a Marketing Cloud send, or about Account Engagement.

Getting help without handing over a login

Be honest about this one. Salesforce has no scoped delegation for email authentication. Managing DKIM keys and Deliverability settings needs the Customize Application permission, and Authorized Email Domains needs Email Administration. Those are broad permissions on a system holding your customer records, and Grant Account Login Access is built for your own administrators and Salesforce support.

So split the work at its natural seam. Your admin does the clicking in Setup. Whoever helps you handles the DNS records, reads the aggregate reports, and tells your admin exactly what to enter and when to click Activate. We never ask for a Salesforce password, and none of this needs one.

If you would rather not do it yourself

This is an afternoon's work for someone comfortable with DNS records and willing to read a message header. If that is you, take it and go. We would rather you succeed than hire us.

If you would rather hand it off, that is what Verified Everywhere does. We inventory every system sending as your domain, publish and check the records, watch the reports, and tell you when the data supports moving to enforcement. We do not take passwords, government ID documents or card numbers, and we promise correct records and honest reporting rather than a specific outcome from any mailbox provider.