You are here:
Guidelines for Configuring Deliverability Settings for Emails Sent from Salesforce
Two things affect email deliverability: past bounced emails to the same email domain, and email that doesn’t comply with a recipient's email security framework. Check out some guidelines to help you handle these roadblocks so your users’ emails get where they’re going fast.
Required Editions
| Available in: Salesforce Classic and Lightning Experience |
| Available in: All editions except Database |
Using the Deliverability page in Setup, you can improve email deliverability.
- To control the type of email that your organization sends, use the Access
level option in the Access to Send Email section. The available options include:
- No access: This setting prevents all outbound email to and from users. All password reset emails continue to send.
- System email only: This setting allows only automatically generated emails, such as new user and password reset emails. Enable this setting to control email sent from sandboxes so that testing and development work doesn’t send test emails to your users. Newly created sandboxes default to System email only.
- All email: This setting allows all types of outbound email. New,
non-sandbox organizations default to this setting. Sandboxes created before Spring
’13 default to All email.
Note To see the Send Email quick action in the activity composer, as the Email tab, choose All email.
- When using bounce management:
- If you also use Email Relay, make sure that your organization's email server allows the relaying of email sent from Salesforce.
- If an email to a contact, lead, or person account bounces, an alert icon appears next
to the email address in the detail page. The icon appears when a hard bounce is received
(a permanent delivery failure). It doesn’t appear with a soft bounce (a temporary
delivery failure).

Ensure that the email address field is in the highlights panel of the detail page so that users can see the alert.
Note Other users can’t send an email to the address until it’s updated or confirmed. - Emails bounce to Salesforce and not to the sender's personal email account.
- Use the Bounced Contacts and Bounced Leads standard report to view a list of email all addresses that have bounced email. The report includes the reason the email was bounced, the date the bounce occurred, and the contact, lead, or person account that bounced the email.
- To comply with your recipients’ email security frameworks like SPF:
- Check Enable compliance with standard email security mechanisms. This setting modifies the envelope From address of emails sent from Salesforce. The header From address remains set to the sender's email address. Usually security frameworks only check the envelope address.
- If you have recipients using the sender ID email authentication protocol, which isn’t
widely used, check Enable Sender ID compliance. This setting
modifies the Sender field in the envelope of emails sent from
Salesforce to automatically include
no-reply@Salesforce. All replies from the recipients are still delivered to the sender's email address. The recipients’ email client (not Salesforce) may append the phrase “Sent on behalf of” to the From field of emails sent from Salesforce.
- To specify how Salesforce uses the Transport Layer Security (TLS) protocol for secure
email communication for SMTP sessions, select a TLS Setting. The
available options include:
- Off—TLS is turned off. SMTP session continues through an insecure connection.
- Preferred—If the remote server supports TLS, Salesforce upgrades the current SMTP session to use TLS. If TLS is unavailable, Salesforce continues the session without TLS. This setting is the default.
- Required—Salesforce continues the session only if the remote server supports TLS. If TLS is unavailable, Salesforce terminates the session without delivering the email.
- Preferred Verify—If the remote server supports TLS, Salesforce upgrades the current SMTP session to use TLS. Before the session begins, Salesforce verifies that a valid certificate authority has signed the certificate and that the common name presented in the certificate matches the domain or mail exchange of the current connection. If TLS is available but the certificate isn’t signed or the common name doesn’t match, Salesforce disconnects the session and doesn’t deliver the email. If TLS is unavailable, Salesforce continues the session without TLS.
- Required Verify— Salesforce continues the session only if the remote server supports TLS, a valid certificate authority has signed the certificate, and the common name presented in the certificate matches the domain or mail exchange to which Salesforce is connected. If any of these criteria aren’t met, Salesforce terminates the session without delivering the email.
- If you select a setting other than
Preferred(the default setting), select Restrict TLS to these domains and specify a comma-separated domain list. The asterisk (*) wildcard is allowed; for example,*.subdomains.commatches john@aco.subdomains.com and john@bco.subdomains.com (but not john@subdomains.com). If you don't specify domains, Salesforce uses the TLS setting you specify for all outbound emails. This can cause undelivered emails.
Note TLS 1.0 has been disabled.
Did this article solve your issue?
Let us know so we can improve!

