Deliverability
Deliverability in Salesforce is the umbrella Setup area that controls the org's outbound email behavior: which delivery mode is active (Default, System Email Only, No Access), which authentication mechanisms are configured (SPF, DKIM, DMARC alignment), which compliance and archival features are enabled (Compliance BCC, Email Relay), and the various toggles that affect whether Salesforce-sent emails reach recipient inboxes or land in spam folders.
Definition
Deliverability in Salesforce is the umbrella Setup area that controls the org's outbound email behavior: which delivery mode is active (Default, System Email Only, No Access), which authentication mechanisms are configured (SPF, DKIM, DMARC alignment), which compliance and archival features are enabled (Compliance BCC, Email Relay), and the various toggles that affect whether Salesforce-sent emails reach recipient inboxes or land in spam folders. The Deliverability page is the central surface for outbound email integrity.
Deliverability matters because modern mail providers (Gmail, Outlook, Yahoo) heavily penalize unauthenticated, low-reputation, or policy-violating outbound mail. A misconfigured Salesforce org sends email that lands in spam folders; the recipient never sees it; the sales follow-up or service notification fails silently. Most outbound email issues admins debug trace back to deliverability misconfiguration: missing DKIM, no SPF inclusion, no DMARC enforcement, wrong sender domain. The Deliverability Setup page is where these are configured and audited.
Why Deliverability is the operational umbrella for outbound email reaching the inbox
Where Deliverability lives in setup
Setup, Email, Deliverability. The page groups settings into delivery mode (which user populations can send email), email security configurations (SPF, DKIM, TLS), compliance toggles (Compliance BCC, Email Relay), and per-feature behavior (Bounce Management, Test Deliverability). Each setting is independent; together they form the org's email posture. New orgs default to System Email Only in sandboxes (preventing accidental email to real recipients during testing) and Default in production.
Delivery mode: Default, System Email Only, No Access
The delivery mode toggle controls which emails Salesforce actually sends. Default allows all outbound email (production behavior). System Email Only restricts to platform-managed emails like password resets (sandbox behavior, to prevent accidental sends to customer data during testing). No Access blocks every outbound email (rare; used during sensitive maintenance windows). The mode is org-wide; most production orgs run Default, most sandboxes run System Email Only by Salesforce's safe default.
Authentication: SPF, DKIM, DMARC alignment
Deliverability includes the SPF and DKIM configurations that authenticate outbound email. SPF (Sender Policy Framework) authorizes Salesforce IPs to send for the org's domains; configured via DNS TXT record on the customer side. DKIM signs each outbound email cryptographically; configured via Authorized Email Domains in Salesforce plus DNS CNAME on the customer side. DMARC enforces policy when SPF or DKIM fail; configured as a DNS TXT record on the customer side. The three together are the modern outbound authentication trio; missing any one drops inbox delivery rates significantly.
Compliance BCC and Email Relay integration
Compliance BCC auto-archives every outbound email to a configured address for regulated retention. Email Relay routes outbound through the customer's own mail server instead of Salesforce IPs. Both are Deliverability-adjacent features configured on the same page or in related Setup areas. Compliance BCC pairs with most Deliverability postures (the archive is independent of routing); Email Relay changes the routing and authentication path entirely. Pick deliberately based on the org's compliance and infrastructure needs.
Test Deliverability and the verification workflow
Salesforce provides a Test Deliverability button that sends a test email to every Salesforce IP plus a few external mailboxes to verify the org can send. The test results show per-IP and per-recipient delivery success or failure. Admins use Test Deliverability after any Deliverability configuration change to verify the change did not break sending. The test is also the diagnostic when users complain about missing emails; the test results tell you whether the issue is Salesforce-side or recipient-side.
Bounce Management and the recipient-side feedback
Bounce Management is the Salesforce feature that processes bounce notifications from recipient mail servers. When an email fails to deliver (mailbox full, address invalid, blocked), the recipient's mail server returns a bounce message. Salesforce parses the bounce, updates the Lead or Contact's Email Bounced Reason and Email Bounced Date fields, and optionally adds the email to a do-not-send list. Without Bounce Management, the org keeps trying to send to invalid addresses, hurting sender reputation. With it, the org learns from bounces and stops sending to known-bad addresses.
Sender reputation and the long game
Recipient mail providers track sender reputation per sending domain. High reputation gets emails delivered to the inbox; low reputation gets emails sent to spam. Salesforce's IPs have shared reputation across all customers using them; one bad-actor customer can hurt every other customer's deliverability. Email Relay through the customer's own mail server isolates the customer's reputation (good or bad). Most large enterprise orgs use Email Relay for high-volume marketing sends to manage reputation; most smaller orgs accept the shared-reputation model and focus on their own authentication and bounce management.
How to configure Deliverability for production-grade outbound email
The pattern: confirm delivery mode is Default for production, configure SPF/DKIM/DMARC end to end, enable Bounce Management, test with Test Deliverability, monitor delivery rates over weeks. The setup is significant; the impact on inbox placement is real.
- Open Setup, Email, Deliverability
Confirm the delivery mode (Default for production). Sandboxes should be on System Email Only to prevent accidental sends.
- Register sending domains via Authorized Email Domains
Every distinct sending domain (acme.com, news.acme.com) needs registration plus a DKIM record on DNS. Without DKIM, deliverability suffers.
- Configure SPF on the sending domain DNS
Add the Salesforce SPF include string to the domain's SPF TXT record. Without SPF, deliverability suffers and DMARC enforcement fails.
- Publish DMARC at policy "none" first, then escalate
DMARC at "none" reports without enforcing. Validate that all legitimate senders pass authentication, then escalate to "quarantine" then "reject".
- Enable Bounce Management
Setup, Email, Deliverability, Bounce Management. Salesforce starts processing bounces and updating Lead/Contact records with bounce reasons.
- Test with Test Deliverability
Click Test Deliverability. Confirm test emails arrive at recipient mailboxes and the per-IP results show success.
- Monitor delivery rates and DMARC reports over weeks
DMARC aggregate reports show how often emails pass authentication at each receiving provider. Sustained high pass rates indicate healthy deliverability.
Default, System Email Only, No Access. Production runs Default; sandboxes run System Email Only.
The three authentication mechanisms that together produce inbox delivery. All three needed for modern deliverability.
Org-wide BCC of outbound emails to a compliance archival address.
Routes outbound through customer-managed mail server instead of Salesforce IPs.
Processes bounce notifications and updates Lead/Contact bounce fields.
- System Email Only on sandbox is the safe default. Switching to Default in sandbox produces accidental sends to real recipients during testing.
- Authentication missing one of SPF, DKIM, DMARC drops inbox delivery significantly. All three are needed for modern mail provider acceptance.
- Without Bounce Management, the org keeps sending to invalid addresses, hurting reputation. Enable as part of the deliverability baseline.
- Salesforce IPs have shared reputation across customers. Bad-actor customers can hurt your delivery; Email Relay isolates reputation for high-volume sending.
- DMARC at "none" indefinitely is not enforcement. The escalation to "quarantine" then "reject" is what actually makes DMARC matter.
Trust & references
Cross-checked against the following references.
- Deliverability referenceSalesforce
- DMARC.orgDMARC.org
Straight from the source - Salesforce's reference material on Deliverability.
- Email DeliverabilitySalesforce Help
- Test DeliverabilitySalesforce Help
- Bounce ManagementSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Can a Salesforce admin configure Deliverability without writing code?
Q2. What is the primary benefit of Deliverability for Salesforce administrators?
Q3. In which area of Salesforce would you typically find Deliverability?
Discussion
Loading discussion…