Troubleshoot Delivery Problems for Salesforce Emails

Troubleshooting Steps: Internal IT and System Administrators

Step 1 (Always begin here): Download your email logs to troubleshoot email delivery failure:
 

1. Download your log file with the steps in Request an Email Log.
2. On your log file, review the 'Delivery Stage' column for any errors incurred during the attempted delivery of the emails to the user's Mail Transfer Agent (MTA).

• Successful delivery is noted by a 'D' in the 'Mail Event' column.
• Failures are noted by a 'P' (permanent: mail is bounced to the sender immediately) or 'T' (transient in the 'Mail Event' column. For more details see: Email Log Reference

• Mail delivery to the recipient is attempted for up to 24 hours before it bounces back to the sender).
• For a single email, it’s possible that you could see more than one line item with a 'D' in the Mail Event column. This is because some emails traverse more than one Salesforce MTA before being delivered to the final recipient.  
• Mail that is CC'd to a recipient has its own line item in the logs.
• Common error seen in the email logs: "no MXs for this domain could be reached at this time." This error indicates that the Salesforce MTA can’t resolve the recipients domain correctly or, more commonly, mail attempted to be delivered to the recipients MTA is being blocked on the recipient's end of the connection.

To learn how to interpret outgoing email logs in setup, watch How to Interpret Outgoing Email Logs in Setup.

 

Allowlisting

Most companies monitor incoming mail and traffic from the internet by filtering the untrusted network addresses.

If a single User is not receiving emails from Salesforce, it's less likely to be an issue with the IP allowlisting. If IP addresses are blocked or filtered then several Users will have a problem receiving emails from the Salesforce application. 

For IP range information see: Ensure you can receive email from the Salesforce application.

Sender Policy Framework (SPF)

Salesforce recommends using DKIM and SPF instead of allowlisting as they’re reliable mechanisms that remove the need for allowlisting and the associated challenges:

SPF is a simple email validation system designed to detect email spoofing by providing a process to verify which providers are permitted to send emails on your behalf. It also aims to reduce spam and fraud by making it harder for anyone to hide their identity. For more detail, review Sender Policy Framework and Salesforce SPF Records.

 

DKIM

When you create a DKIM key, Salesforce publishes the TXT record containing your public key to DNS. We also automatically rotate keys to reduce the risk of your keys becoming compromised by a third party. For more detail, review Create a DKIM Key and Best practices to setup DKIM​​​​​.

Configure an Email Client (ex: Outlook, Gmail)

Sometimes the User's email client sends the email to the 'Junk' or 'Spam' folder. The Users themselves, or with the help of their IT team, can allowlist these emails to make sure the emails are received in their 'Inbox' folder.
 

Troubleshooting Steps: Salesforce Application

1. Verify the email address is correct

Always start with the email address and make sure it's spelled correctly. Also, check that there are no commas used instead of dots or blank spaces at the beginning of the email address. 
 

2. Test Deliverability

Before starting to make changes in your Salesforce organization, or in your company's network, Test the Deliverability of Emails Sent Through Salesforce to see how many emails end up in your Inbox.

This test can give you an idea of whether anything is being blocked, by sending several emails depending on your instance from Salesforce IP addresses.  If you didn’t receive all the test messages, your organization’s email administrator must add the Salesforce IP ranges to the allowlist for your organization’s email server.   In addition, work with our network administrator to ensure ‌emails are not being blocked.

An additional test that helps to identify email issues is creating a test Contact/Lead/Record in Salesforce and sending emails directly.  Here you can track the success/failure in the email logs to glean more information.

3. Configure your Email Deliverability settings

Your Salesforce admin can Configure Deliverability Settings for Emails Sent from Salesforce to improve the deliverability of emails that your organization sends out.

During this process, your administrator can select one of the following options:

• No Email: Prevents all outbound emails to and from Users, except for password resets (as of the Spring '21 release.)
• System email only: Allows only automatically generated emails, such as new User emails.
• All email: Allows all types of outbound email. The default for new non-sandbox organizations.

Example: If your administrator has configured these settings in your organization with "No Email" then emails from your organization are restricted. To resolve this issue, one of your Salesforce Administrators must change the 'Deliverability' selections to System Email Only or All Emails.

You may also watch our Salesforce Support YouTube video Configuring the Email Deliverability of Your Org for a walkthrough.

4. Configure Email Relay

When you have Enabled Email Relay and taken the steps to Set Up Email Relay, the Salesforce email server delivers all outbound emails to your email server, which then delivers them to the final recipients. Since your server is doing the final delivery, there’s no question as to the legitimacy of the communications.

After our Salesforce MTA connects and authenticates with your MTA (mail server) the communication is secure. It also has the added advantage that you can filter for content, add footers, and retain a copy of all outbound emails.

This option requires coordination with your IT team, as they have to make changes to your email server. This also generally requires a dedicated server. Free domains like gmail.com / outlook.com / yahoo.com e.t.c may not be supported.

See also: SPF and DKIM alignment fails