Test Deliverability
Test Deliverability is a Salesforce Setup utility that sends a test email from the org to a specified address to verify that outbound email delivery is working correctly.
Definition
Test Deliverability is a Salesforce Setup utility that sends a test email from the org to a specified address to verify that outbound email delivery is working correctly. The tool sits under Setup, then Email, then Test Deliverability, and produces a diagnostic email covering all the email service categories the platform supports: System Email, User Email, Email Alerts, and Mass Email. Each recipient address receives one email per category, and the admin can confirm receipt to verify the delivery path.
The utility is the right first stop for diagnosing email deliverability problems. When users report that automated emails are not arriving, Test Deliverability quickly confirms whether the issue is on the Salesforce side (no email leaving the platform), on the recipient side (delivered but not arriving in the inbox), or somewhere in between. The diagnostic is fast (the test emails arrive within minutes if delivery is working) and inexpensive (it consumes a small amount of the org's daily email allocation). For any email-related support investigation, running Test Deliverability is the standard first action.
How Test Deliverability works and what it tells you
The categories of test emails
Test Deliverability sends emails representing each of the major email service categories the platform supports. System Email is platform-generated email like password resets and notifications. User Email is rep-initiated email like Send Email from a record. Email Alert is automation-driven email from Flows and Approval Processes. Mass Email is the legacy mass-send feature for templated email to many recipients. Each category may route through different infrastructure on the Salesforce side and may have different delivery characteristics. The test sends one email per category, and the admin confirms receipt of all four to verify end-to-end delivery is working.
What success and failure mean
Success in Test Deliverability means the test emails arrived in the recipient's inbox. Failure can manifest in several ways: no emails arrive (a Salesforce-side delivery problem), some emails arrive but others do not (a category-specific configuration issue), emails arrive in the spam folder (a sender reputation or content issue), or emails are delayed significantly (an infrastructure problem). Each failure mode points at a different root cause. The Test Deliverability email itself contains diagnostic information helping the admin distinguish among these cases.
Email Deliverability settings and Test Deliverability
The org's Email Deliverability setting (All Email, System Email Only, or No Email) controls whether outbound emails can leave the org at all. Sandboxes default to System Email Only to prevent test runs from spamming real customers, and the setting is sometimes wrong after a sandbox refresh. Test Deliverability is the right tool to confirm the setting is correct: in System Email Only mode, only System Email tests arrive; in All Email mode, all four categories arrive. Discovering the wrong setting through Test Deliverability is much faster than discovering it because customer notification emails are not going out.
Diagnosing inbox placement issues
When Test Deliverability emails arrive but in the spam folder rather than the inbox, the issue is inbox placement rather than delivery itself. Inbox placement depends on sender reputation (how the recipient's mail server views the sending IP), authentication (SPF, DKIM, DMARC alignment), and content (the email body, links, and attachments). Test Deliverability emails come from Salesforce's sending infrastructure, so the test confirms Salesforce-to-recipient delivery but not necessarily inbox placement for the specific automated emails. For inbox placement issues, the diagnostic extends to checking authentication records on the customer's sending domain and reviewing the content of the actual production emails.
Sandbox post-refresh deliverability
After a sandbox refresh, Email Deliverability is reset to System Email Only by default. This is intentional safety: a fresh sandbox should not spam real customers during test runs. Admins refreshing sandboxes regularly should include Test Deliverability in their post-refresh checklist. Confirm the deliverability setting matches the team's testing needs (often All Email for sandboxes used by sales reps practicing live, System Email Only for automated test runs), run Test Deliverability to verify the configuration is right, and document the post-refresh state in the runbook so future refreshes follow the same pattern.
Combining Test Deliverability with Email Logs
Test Deliverability tells you whether email left the platform. Email Logs (a separate Setup tool) tells you what happened to specific emails over a specific time window: each outbound message with delivery status, bounce reason, recipient response. Combined, the two tools cover the full diagnostic picture: Test Deliverability for can-email-leave-the-platform questions, Email Logs for did-this-specific-email-deliver questions. For complex deliverability investigations, both tools usually need to run. Email Logs require requesting a log for a specific time window, which takes minutes to hours to generate; Test Deliverability is immediate but less detailed.
Limitations of Test Deliverability
Test Deliverability has limitations admins should understand. It sends from Salesforce's default sending infrastructure, not necessarily the same infrastructure as the customer's org-wide email address. For orgs using Send through External Email Services (routing through Amazon SES or SendGrid), Test Deliverability does not test the external path. It does not test specific automation paths (a Flow that sends email via a custom controller may behave differently from the basic Send Email path). For full coverage, supplement Test Deliverability with sample sends through the actual automation that produces the problematic emails. The tool is a useful first step but not a complete deliverability test.
Recurring email troubleshooting patterns
Across many email troubleshooting cases, certain patterns recur. The newly refreshed sandbox where automated tests stop working: Test Deliverability confirms Email Deliverability dropped to System Email Only, and the fix is changing the setting back to All Email plus running the test again. The customer notification that suddenly stops arriving for a specific recipient: Test Deliverability succeeds globally, but the specific recipient has the address blocked at their corporate mail server level, and the fix is whitelisting on the customer side. The password reset that does not arrive for any user: Test Deliverability fails on System Email category, suggesting the org has hit its daily email allocation and password resets are being rejected; the fix is purchasing additional allocation or waiting for the daily reset. The Marketing Cloud sync that stops bringing emails into Salesforce: Test Deliverability confirms outbound is fine, narrowing the problem to the integration rather than Salesforce email itself. Each pattern is recognizable once you have seen it a few times, and Test Deliverability is the diagnostic that quickly separates the patterns. Building a runbook entry for each pattern with the diagnostic signature and the fix saves significant time over the years of operational support that follows.
Run Test Deliverability and act on the results
Running Test Deliverability is straightforward; the value comes from interpreting the results and taking the right diagnostic action. The workflow below covers the standard sequence for an email deliverability investigation.
- Run Test Deliverability with the right recipient
From Setup, navigate to Test Deliverability under Email. Enter the recipient email address (typically the admin's own work email for initial testing, or the specific user reporting the problem if investigating a complaint). Click Send. Within a few minutes, the recipient should receive emails representing each of the four email service categories. Check the inbox for the test emails and note which ones arrived.
- Compare results against expected behavior
Confirm which categories arrived. If all four arrived in the inbox, basic email delivery is working. If some are missing, the gap indicates a category-specific issue or a deliverability setting that needs adjustment. If all four arrived in spam, the issue is inbox placement rather than delivery. Document the results in the support ticket or runbook before moving to the next diagnostic step.
- Investigate based on the result pattern
Based on the Test Deliverability result, follow the appropriate diagnostic path. No emails arrived suggests checking Email Deliverability settings and Email Logs for outbound activity. Some emails missing suggests checking specific automation paths or permission set assignments. Spam folder placement suggests checking SPF, DKIM, DMARC alignment on the sending domain. Each path has its own follow-up steps, but Test Deliverability narrows the search dramatically.
- Re-test after configuration changes
After any configuration change (Email Deliverability setting, DKIM key, allowlist update), re-run Test Deliverability to confirm the change had the expected effect. Iterating between configuration change and Test Deliverability is the standard tight loop for email troubleshooting. Document each change and the result so the support ticket has a clear audit trail. Once the test reports clean delivery, validate with the actual automation that was producing the problem to confirm end-to-end.
- Sandbox Email Deliverability resets to System Email Only after refresh. Test Deliverability catches this immediately if included in the post-refresh checklist.
- Test Deliverability does not test Send through External Email Services. Orgs using external email services need separate verification through those services.
- Tests arriving in spam are not delivery failures; they are placement issues. The root cause is sender reputation or authentication, not Salesforce configuration.
- Some corporate email systems quarantine Salesforce test emails by default. Whitelisting the Salesforce sending domain in the recipient's mail system may be required for valid tests.
- Test Deliverability sends one email per category. For automation-specific testing, supplement with actual sample runs through the production automation.
Trust & references
Straight from the source - Salesforce's reference material on Test Deliverability.
- Test DeliverabilitySalesforce Help
- Email LogsSalesforce 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. What is the primary benefit of Test Deliverability for Salesforce administrators?
Q2. Why is understanding Test Deliverability important for Salesforce admins?
Q3. In which area of Salesforce would you typically find Test Deliverability?
Discussion
Loading discussion…