Email Limits: DailyWorkflowEmails vs SingleEmail Explained

Salesforce email governor limits after Spring '19

If you design high-volume email on the platform, you need to know how each sending mechanism gets capped. The usual reading of the limits, DailyWorkflowEmails in particular, tends to clash with what an org actually does once it is on a post-Spring '19 release.

The recipient type dictates the limit

Testing and observation both point the same way. What drives the email governor limit is the recipient type, not the automation context that invoked the send, so Apex, Flow and Workflow Rules land in the same place.

1. Internal Salesforce user recipients: email sent only to users inside the org, the ones with User records, counts against the DailyWorkflowEmails limit alone.
2. External recipients: email sent to any external address, including standard Contact and Lead emails, a hardcoded external address, or recipients sourced from external objects, counts against both DailyWorkflowEmails and the tighter SingleEmail limit.

So Messaging.sendEmail() in Apex, or any Flow action aimed at an external address, feeds the shared SingleEmail cap.

The two daily limits

• DailyWorkflowEmails tracks email triggered by Workflow Rules or Flows aimed at internal users. As above, external sends increment it too.
• SingleEmail is the shared one, typically 5,000 per rolling 24 hours, though that depends on configuration. It is the constraint that bites on external communication. Any email dispatched to an external recipient adds to the total, whether it came from Apex through Messaging.sendEmail, from Flow, or from Process Builder.

You cannot get around the shared SingleEmail cap for external recipients by splitting the work across automation types. An Apex callout sending 100 emails to external contacts draws on the same pool as a Flow sending 100 emails to external contacts.

In Apex, the Messaging.sendEmail() signature does nothing to override the system-level tracking:

List<Messaging.SingleEmailMessage> messages = new List<Messaging.SingleEmailMessage>();

// ... populate messages list ...

// If recipients in 'messages' include external addresses, both DailyWorkflowEmails and SingleEmail are incremented.
Messaging.sendEmail(messages, false); 

Architectural implications

For anything that has to deliver external email at volume, such as transactional notifications or large batch communications:

• Do not read DailyWorkflowEmails as a measure of your overall sending capacity. SingleEmail is usually the real bottleneck.
• If throughput goes past the hard limits, integrate an external Email Service Provider through callouts, which leaves the native Salesforce email governor limits out of the picture.
• In complex automation streams, track usage against the shared SingleEmail limit across every synchronous and asynchronous process that targets non-users.