Salesforce Email Deliverability: The Complete Guide (2026)

A rep clicks send on a quote. Salesforce says the email went out, the activity is logged, and the customer swears nothing arrived. Two days later someone finds it in a spam folder, or finds out it was never sent at all.

Salesforce email deliverability is hard to see from inside Salesforce, because the platform reports what it sent, not where the message landed. This guide covers everything that decides whether Salesforce email reaches the inbox, for both the CRM and Marketing Cloud, in the order you should fix it.

Why Salesforce Email Deliverability Is Really Three Problems

“Salesforce email” covers several sending paths, and they fail for different reasons. Work out which one your problem is on before you change anything.

Fixing the Deliverability setting in a CRM org will not help a Marketing Cloud journey that is failing on a new IP, and the reverse is also true. The rest of this guide marks which sections apply to which path.

The Salesforce Email Deliverability Access Level

If Salesforce emails are not sending at all, this is the first place to look. It is a setting, not a reputation problem.

In Setup, search for Deliverability. The page has an Access level for email with three values:

• All email: every outbound email can leave the org. This is the right value for production.
• System email only: only system-generated messages go out, such as password resets and new user emails. Business email, mass email and workflow messages are blocked.
• No access: no outbound email at all.

Sandboxes are the usual trap. Per Salesforce admin guidance and community reports, a new or refreshed sandbox typically comes up on System email only, which is a deliberate safeguard so a test run does not email real customers. The caveat is that it also means a refresh can silently turn off email you were relying on in a test environment. Check the setting after every refresh, and use Send Test Email on the same page to confirm the result.

Two queries come up here constantly: “test deliverability failed to send email” and “test deliverability not working.” Both usually mean the access level is restricted, or that the sending user’s email address has not been verified. Set the level first, then verify the From address.

How to Check Your Salesforce Deliverability

Salesforce shows sends, bounces, opens and clicks. None of those tell you whether an email reached the inbox. A message can be accepted by the receiving server and still be filed as spam, and open rates are inflated by Apple Mail Privacy Protection, which pre-loads images whether or not a person reads the email. The caveat is that open rate is still useful as a trend within one list, just not as a deliverability measure. The Apple Mail Privacy Protection guide explains the effect.

To see placement you need an outside signal:

• Google Postmaster Tools shows Gmail spam rate and authentication pass rates, published 24 to 48 hours late. See the Google Postmaster Tools guide.
• Seed mailbox testing sends your real campaign to test inboxes and reports Inbox, Promotions or Spam per provider. InboxEagle’s seed panel covers Gmail, Yahoo, AOL and Outlook. The seed testing vs inbox monitoring comparison covers when each is the right tool.
• A blocklist check on your sending domain and IP, using the free email blacklist checker.

None of this needs access to your Salesforce org: the Salesforce setup guide shows how to add your domain, connect Postmaster Tools and add seed addresses to a Salesforce send. For a quick read on your setup with no account, the email deliverability checker is free. Domain and sender reputation behave differently, so it also helps to read how sender reputation scores work.

Set Up SPF, DKIM and DMARC for Salesforce

Authentication is the floor, not a placement guarantee. A fully authenticated sender can still land in spam on a bad list, but an unauthenticated one is filtered or rejected before content matters. For the underlying concepts, read SPF, DKIM and DMARC explained.

The common symptom of missing authentication in Salesforce is mail that carries a Salesforce identity instead of yours. Receivers then attribute reputation to a shared domain rather than to your brand, and some mail clients show a “via” or “on behalf of” label next to the sender.

SPF in Salesforce

SPF is a TXT record that lists who may send for your domain. Per Salesforce’s SPF guidance, the entry to include for mail sent from the Salesforce application is _spf.salesforce.com. Use only that one, because the salesforce.com domain carries several other SPF records that are for other purposes and are not relevant to sending mail from the application. A typical record looks like v=spf1 mx include:_spf.salesforce.com ~all.

Three details matter in practice:

• A domain can only have one SPF record. If you already have one for Google Workspace, Microsoft 365 or another tool, add Salesforce’s include to that record instead of publishing a second. Two SPF records both fail. Salesforce advises placing the other providers’ includes before the Salesforce include.
• You do not need to list Salesforce IPs. The _spf.salesforce.com entry uses a macro that dynamically authorizes Salesforce’s mail transfer agent addresses, so individual IPs are not required.
• Marketing Cloud and Pardot have their own setup. Salesforce points to product-specific SPF and DKIM instructions for each, so follow those rather than the CRM steps if you send from either.

Check the result with the free SPF record checker, and read about the 10 lookup limit if you send from several tools. Salesforce also suggests testing with Kitterman’s SPF query tool.

DKIM in Salesforce

DKIM is the check that matters most for Salesforce, because the envelope sender on Salesforce mail often belongs to Salesforce. That means SPF alone will not align with your From domain. In Setup, open DKIM Keys, create a key for your domain, publish the CNAME records Salesforce shows you, wait for them to propagate, and then activate the key. Per Salesforce’s DKIM best practices, enter your email domain in the Domain setting, not your My Domain name, and note that the Activate button stays disabled until Salesforce detects the correct CNAME records in DNS. Keys cannot be copied between orgs, so in a sandbox you must recreate them after a refresh and republish the CNAME records.

Three more details from the same article save debugging time:

• Use a unique selector. Two keys cannot share a selector for the same domain. A duplicate stops the new CNAME from publishing, and the key can be created but never activated.
• Only one key is active at a time. A DNS lookup returns whichever key, primary or secondary, is active in the rotation at that moment, so do not expect to see both.
• Keys do not expire. Existing keys keep working, but new keys must be generated with the current method, whether in Setup or through the EmailDomainKey API.

Follow the exact targets Salesforce displays, and confirm the result with the DKIM record checker. If DKIM passes but DMARC still fails, the DKIM failing fix covers the usual causes.

DMARC and alignment for Salesforce

DMARC passes when SPF or DKIM passes and aligns with the domain in your From address. With Salesforce, DKIM alignment is usually the one to get right first. Start with a monitoring policy of p=none, confirm every sender aligns, and then move toward enforcement. The guide to moving DMARC to enforcement covers the sequence, and the free DMARC record generator builds the record. Use a subdomain you control for sending where you can, and see the email subdomain strategy guide for how to choose one.

Paste your sending domain here to see what your records say right now:

Marketing Cloud: Sending Domain, SAP and Dedicated IPs

Marketing Cloud adds a layer the CRM does not have: you choose the domain and IP that carry your reputation.

The Sender Authentication Package (SAP) is the bundle Salesforce sells for this. As SalesforceBen’s SAP breakdown lists it, SAP combines four components: a private domain, account branding (your own domain in wrapped links and images), a dedicated IP and Reply Mail Management. Without a dedicated IP, mail goes out on shared infrastructure, so other senders on the same pool affect your placement. The private domain, dedicated IP and Reply Mail Management can each be bought separately, while account branding comes only with SAP, and a standalone private domain does not wrap links and images. Check what you actually need before buying the full package.

On the IP question, the caveat is that a dedicated IP only isolates you. It cannot repair a weak domain reputation or a poor list, and a low-volume sender on a fresh dedicated IP often does worse than on a shared pool that is already warm. A dedicated IP earns its keep at large monthly volumes, so volume is the deciding factor. If you do move to one, a new IP, or one left unused for over a month, needs warming by gradually increasing send volume, and the domain needs warming too. The dedicated vs shared IP comparison shows when it pays off, and IP reputation vs domain reputation explains which one the mailbox providers weigh most.

Warm-ups fail most often because volume ramps too fast or the first sends go to the least engaged contacts. Plan the ramp with the email warmup planner, and read why warm-ups fail before you start.

Salesforce Bounce Management

A hard bounce is a permanent failure, such as an address that does not exist. A soft bounce is temporary, such as a full mailbox. Hard bounces are the ones that damage reputation, because mailing dead addresses signals poor list quality. The hard vs soft bounce guide lists the reasons behind each.

In the CRM, Bounce Management is a setting that flags bounced addresses on the contact or lead record. Read that as a report, not a cleanup: it tells you an address is undeliverable, and it is still your job to stop mailing it. Some setup guides suggest switching Bounce Management off while configuring authentication. Weigh that carefully, because turning it off means Salesforce no longer flags your bounces.

What to do:

1. Review flagged and bounced addresses after every large send.
2. Validate any list before importing it. A spike right after an import almost always traces back to the list, and the bounce rate spike guide walks through the diagnosis.
3. Suppress contacts that soft bounce repeatedly.
4. Track the number over time with the bounce rate calculator.

List Hygiene: Imports, Stale Contacts and Purchased Lists

Mailbox providers watch engagement. Mailing people who never open teaches them your mail is unwanted, and CRM data decays quickly because leads change jobs and addresses.

• Stale CRM records. Old leads that nobody has touched are the most likely to bounce or hit spam traps. Segment on recent engagement and stop mailing the rest.
• Imports. Validate any list before it enters Salesforce. One bad import can lift your bounce rate for weeks.
• Unengaged contacts. Because of Apple Mail Privacy Protection, a contact who “opens” may be a machine, so use clicks and replies as a second signal.
• Purchased lists. They carry spam traps and no consent. Read why purchased lists wreck deliverability.

For a full process, see email list hygiene for deliverability, and run the free list health estimator on your current list.

Why Salesforce Emails Go to Spam: A Diagnostic Checklist

Work down this list in order. Each step is cheaper than the next.

1. Is the access level set to All email, and is the From address verified? If not, nothing else matters yet.
2. Do SPF and DKIM pass, and does DKIM align with your own From domain? If not, fix this before anything else.
3. Did bounces or complaints jump after a specific send or import? Find the campaign and the list behind it.
4. Are you mailing contacts who stopped engaging? Suppress them.
5. Are you on a blocklist? Use the blocklist checker.
6. Does the content read as promotional? Test it with the spam word checker and the email spam tester. Content rarely decides placement alone, as content signals vs reputation explains.
7. Is it one provider or all of them? An Outlook-only problem points to Outlook filtering, not your whole setup. See provider-specific inbox placement.

Salesforce Email Limits and Sending Volume

Salesforce caps how much email an org can send, and the caps differ by feature. Single emails sent through the API or Apex, mass email and list email are each limited, and an org that hits a limit sees failures rather than a warning. The numbers depend on your edition and on the feature, and they change between releases, so confirm the current figures in Salesforce Help before you plan volume around them.

The practical points that do not change:

• Limits are org-wide. One team’s large send can use capacity that another team needs.
• Sandboxes and trial orgs are far tighter than production.
• Marketing Cloud and Account Engagement are the right tools for bulk marketing. CRM mass email is not built for newsletter-scale volume, and pushing it that way is a common cause of complaints.

The Gmail, Yahoo and Outlook Bulk Sender Rules

The rules apply to the mail you send, whatever platform sends it. Gmail and Yahoo introduced them in 2024, and Outlook followed in 2025. In summary, bulk senders need SPF, DKIM and DMARC, an easy way to unsubscribe, and low spam complaint rates. Google lists a spam rate below 0.30% as a requirement and recommends staying below 0.10%, and non-compliant traffic can face temporary or permanent rejection. Check the details on Google’s sender requirements and Yahoo’s sender best practices.

For Salesforce, that means a sending domain with aligned authentication, working unsubscribe links on marketing email, and a watch on complaint rate. Our Gmail bulk sender requirements guide and spam complaint rate explainer cover the thresholds in more depth.

So What Do You Actually Do?

1. Set the Deliverability access level to All email in production, and recheck sandboxes after every refresh.
2. Authenticate your own domain. Publish SPF with Salesforce’s include, create and activate a DKIM key, and confirm DKIM aligns with your From domain.
3. Move DMARC from p=none toward enforcement once every sender aligns.
4. Review bounces after every large send and validate imports before you mail them.
5. In Marketing Cloud, decide on SAP and a dedicated IP by volume. Stay on shared IPs unless you have the volume to justify a dedicated one, and plan the warm-up if you do.
6. Keep the CRM for one-to-one and transactional mail and use a marketing platform for bulk.
7. Measure placement, not opens. Use Postmaster Tools and seed testing so you see Inbox, Promotions and Spam.

The Bottom Line

Salesforce email deliverability comes down to three things you control: a setting that lets mail leave the org, an authenticated sending domain that is yours, and a clean, engaged list sent at sensible volume. Salesforce gives you the controls, but its reports cannot tell you where an email landed.

How This Guide Was Compiled

This guide draws on Salesforce’s published documentation (Help articles 000387804 and 000382664, plus DKIM best practices), on SalesforceBen’s Sender Authentication Package guide, on the official sender requirements from Google and Yahoo linked above, and on community reports for sandbox behavior. It was reviewed in October 2026. Salesforce changes setup screens, editions, DNS record formats and sending limits between releases, so treat the specific values and menu paths here as a starting point and confirm them in Salesforce Help for your org. Daily limits are deliberately not quoted as fixed figures for that reason. Everything on authentication and bulk sender rules reflects the mailbox providers’ own published requirements.