You can send email from your domain via Salesforce, but that alone does not prove the email is really from you. The proof comes from DMARC, an email security standard that mail providers like Gmail and Outlook use to check whether a message was sent with the domain owner's permission. Until you finish a short authentication setup in each Salesforce product, any email you send using Salesforce fails this check and can land in spam, or be rejected outright.
The fix is well documented but spread across several Salesforce products with different setups. This guide explains where the authentication gaps are in a default Salesforce configuration and how to close them for Sales Cloud, Account Engagement (formerly Pardot), and Marketing Cloud Engagement.
When you send through Salesforce, the email does not go out from your own systems. Salesforce's servers build the message and deliver it to your recipients, with your address in the From line. Those servers run on Salesforce's own domains and use Salesforce's own configuration, separate from anything you control.
Mail providers like Gmail and Outlook do not trust the From address by itself, because anyone can type any address into it. They look at the technical evidence instead: which servers delivered the message, and which domain vouched for it.
DMARC determines whether the domain your recipients see in the From address is also the domain that authenticated the message. If the domains match, the receiving email server knows the email is from you. This match is called alignment, and a default Salesforce configuration does not provide DMARC alignment: the message authenticates as Salesforce, while your domain's name is on it.
What happens next depends on your DMARC policy. At p=none, the mail still arrives and the failure only shows up in reports. At p=quarantine or p=reject, receivers send the unaligned mail to spam or refuse it, and campaigns stop reaching inboxes.
Every email carries two sender addresses. The From address is the one your recipients see. The return path is a hidden address where delivery failures, called bounces, are sent. DMARC's SPF check cares about the return path: the domain in it must match the From domain for SPF alignment to hold.
When Salesforce sends for you, the message leaves Salesforce's mail servers, and by default the return path uses a domain Salesforce operates rather than your domain. This is normal platform behavior, and it keeps bounce processing working without any setup on your side. It also means your domain goes unauthenticated by default.
Each Salesforce product sends through its own infrastructure with its own authentication setup. Sales Cloud covers the email your team sends from the CRM. Account Engagement runs marketing automation and nurture campaigns. Marketing Cloud Engagement handles high-volume campaign sending. Configuring one does not configure the others.
Two addresses matter here: the From address your recipients see, and the hidden return path where delivery failures go. DMARC only counts an SPF pass when the return path uses your domain. In a default Salesforce setup, it never does.
Take Account Engagement as an example. Its messages carry a return path on a Salesforce-owned domain, with addresses like bounce.s7.exacttarget.com, per Salesforce's own DMARC support documentation. When a receiving server runs the SPF check, it checks this Salesforce domain rather than yours. The check may pass, but it proves the wrong thing: it vouches for Salesforce's domain and leaves yours unproven. DMARC counts this as a failure.
Sales Cloud can create the same mismatch. With Bounce Management or Email Security Compliance turned on, Salesforce replaces the return path with a bounce-tracking address on a Salesforce domain, as described in Salesforce's SPF and DKIM FAQ. The domains no longer match, and DMARC's SPF check fails for the same reason.
You may have already added Salesforce's include, include:_spf.salesforce.com, to your SPF record. Keep it: it tells receivers that Salesforce's servers are allowed to send as your domain. But it does not change the return path, so it cannot fix this mismatch on its own.
This is why DKIM is the reliable path with Salesforce. A DKIM signature travels inside the message itself and is tied directly to your domain, no matter whose servers deliver the mail. Once you set up DKIM keys, Salesforce signs every message as your domain, and DMARC has the proof it needs.
Each Salesforce product needs a one-time setup, and each one ends with a few new DNS records on your domain. If you do not have access to your company's DNS settings, share this section with the person who does: it contains everything they need. If you do, the steps below are yours to follow.
If the setup is in someone else's hands, you can skip ahead to checking whether your Salesforce email passes DMARC.
In Salesforce Setup, under Email, then DKIM Keys, create a DKIM key: choose a 2048-bit key and set the domain to your sending domain. Salesforce responds with CNAME records, which are small DNS entries to publish on your domain. Once the records are live, activate the key. From then on, Salesforce rotates it automatically every 30 days with no maintenance from anyone.
The setup has the same shape: Account Engagement generates DKIM records for your sending domain, you publish them in DNS, and Account Engagement signs your email as your domain from then on. Salesforce's guidance is direct on this point: with DKIM properly configured, DMARC should pass.
Two cautions from Salesforce's documentation are worth noting. Keep the email sending domain and the tracker domain separate, because using the same domain for both causes authentication errors. And if your team also wants SPF alignment, that requires a custom return path, requested through an Account Engagement support case.
Marketing Cloud is the one case where the setup is a purchase rather than a settings change. Its Private Domain product, part of the Sender Authentication Package, applies DKIM, SPF, and DMARC authentication to a dedicated sending domain, per Salesforce's Private Domain FAQ. Most teams delegate a subdomain such as mail.example.com and let Salesforce manage its records. If your organization hosts the DNS itself instead, your DNS team maintains those records, and Salesforce support does not troubleshoot self-hosted DNS.
Whichever products you use, one more DNS change completes the picture: add include:_spf.salesforce.com to your domain's SPF record. Alignment still comes from DKIM, but a complete SPF record keeps baseline authentication intact for every path Salesforce mail takes.
The quick test takes one message. Send an email from each Salesforce product to a mailbox you control, open the message headers, and look for dkim=pass with a d= value showing your domain. A pass for a Salesforce-owned domain in the signature means the DKIM setup for your domain is not finished.
You can confirm the DNS side in seconds with the checker below: it shows whether your domain publishes valid DKIM records.
The definitive check is your own DMARC data. Your DMARC aggregate reports list every source sending as your domain, including Salesforce's IP ranges, and show whether each message passed with alignment. If Salesforce traffic appears in your reports as failing, the reports also tell you which leg, SPF or DKIM, needs work. DMARCeye's free plan covers one domain and turns raw reports into a readable list of senders and next steps. You can watch the Salesforce sources move from failing to aligned as your DNS changes take effect.
Platform defaults authenticate the platform, not your domain. Salesforce's own documentation is clear about the fix: set up DKIM for every Salesforce product that sends as your domain, and keep include:_spf.salesforce.com in your SPF record. Judge success by alignment rather than by a bare SPF or DKIM pass.
The work is a handful of DNS records, and your DMARC reports will confirm within days that Salesforce mail is passing as your domain. DMARCeye monitors those reports for you and flags the senders that still need attention.