To maintain consistent access to Salesforce's shared email services, any long-term or indefinite email limit increase requires ongoing monitoring of outbound email failure rates. To qualify for email limit increases, customers must maintain a Permanent Failure Rate (PFR) of less than 1% of their total outbound email. This requirement remains in effect throughout the lifetime of the increased email limit.
For example, an organization sending 10,000 emails per day must ensure no more than 99 of those emails result in a permanent failure — such as a bounce to an invalid or non-existent address — in order to remain compliant and retain their increased limit.
Professional, Enterprise, Unlimited, and Developer
Default Limit: Salesforce organizations must maintain a Permanent Failure Rate (PFR) of less than 1% of total outbound email at all times.
Submit a limit increase request with Salesforce Support
Review the Salesforce documentation on how to Calculate PFR before submitting a limit increase request.
Please refer to the article on how to Calculate PFR before proceeding with the steps below.
If you've reviewed all relevant documentation and still need assistance with a limit increase request, please have a System Administrator create a limit increase request with Support.
A System Administrator will need to take responsibility for the export of known bad addresses within the organization's Setup. Depending on the solution selected, this individual may not be the same person designated to take action to correct these addresses and/or records.
It is essential that bad addresses collected in the organization's email logs are addressed on a consistent basis. The manner in which these bad addresses are handled can vary and will be solely determined by the organization's leaders and/or change management teams.
Organizations have shown great success when taking one or more of the approaches outlined below:
Append ".invalid" to the end of the email address on any Contact, Lead, or other record in which it is stored. The Salesforce email system discards any outbound email addressed in this manner, and any mailing sent will not impact the organization's failure rate.
Delete the email address on any Contact, Lead, or other record in which it is stored. These can be confirmed through reports, list views, and API queries. Manual, Import Wizard, or API-based updates can then be utilized to remove the offending addresses.
Delete the Contact, Lead, or other record associated with the bad email address. These records can be confirmed as described above. Deletion can occur using the organization's Mass Delete functionality or API-based deletion methods.
Archive the Contact, Lead, or other record. This includes exporting and then deleting the records. The exported details can be stored locally outside of Salesforce for future reference. The export can occur via reports, API-based export functionality, or the organization's Data Export functionality.
Implement the Bounce Management functionality within the organization. This allows Salesforce to automatically handle email bounces and flag known bad addresses going forward.
Implement a custom checkbox to indicate that a Contact, Lead, or other record has a known bad address. This is not a foolproof solution, as there are many elements that would be required for it to work effectively. However, if the majority of email is originating via API integrations, this approach may be worthwhile if the integrations can filter these records from use through this checkbox.
Email Logs can be located by a System Administrator within the organization's Setup. See this article for more details on how to request and analyze email logs.
We recommend that the established monitoring and cleanup steps occur as frequently as once every 15 days to ensure the organization's PFR remains below the required 1% threshold.
001738809

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.