Hitting the Salesforce 5,000 email limit? The architecture that gets around it

A telehealth company was losing legitimate transactional email. Their automation flows sent appointment and order messages through Salesforce, and on busy days the org slammed into the platform’s hard limit: 5,000 external recipients per 24 hours. Salesforce will not raise that number for anyone. The flows kept firing; the emails silently stopped sending.

The short answer

Keep Salesforce as the brain, stop using it as the mail server. The pattern has three parts:

1. Render in Salesforce. The platform can render a stored email template, merge fields included, without sending it. Rendering does not count against the send limit. All your existing templates keep working.
2. Send through an external email service. The rendered HTML posts to a cloud email API over an authenticated callout. These services are built for volume; the daily cap effectively disappears, and per-message cost is a fraction of a cent.
3. Close the loop on deliverability. The email service emits bounce and complaint events to a webhook. A small REST endpoint inside Salesforce receives them and flips the contact’s opt-out flag automatically. List hygiene continues without anyone touching a spreadsheet.

What changes for admins and flows

Almost nothing, which is the point. The flow’s “Send Email” action is replaced with a custom invocable action that takes the same inputs: template, recipient, related record. Admins keep building in Flow. Marketers keep editing templates in Salesforce. The swap happens beneath them.

Details that decide success

• Domain authentication carries over. SPF, DKIM, and DMARC are configured once on the sending domain, so deliverability reputation transfers to the new service rather than starting from zero.
• Named Credentials, not hardcoded secrets. The callout authenticates with OAuth client credentials stored in Salesforce Named Credentials. No keys in code, and rotation is an admin task.
• Treat the event webhook as production code. Bounce events arrive out of order, duplicated, and occasionally malformed. Matching on email address with idempotent updates keeps the contact data truthful.

When you should do this

If you are anywhere near 5,000 sends per day, do it before you hit the wall, because the failure mode is silent. Salesforce does not error loudly when the cap is reached; messages just stop going out, and you find out from customers. The whole pattern is an evening of architecture and roughly a week of careful build and test. Compare that to the cost of appointment confirmations quietly not arriving.

The broader lesson

Salesforce limits are rarely the end of a requirement; they are a routing instruction. The platform is excellent at deciding who should get what message when. Delivery at volume is a solved problem elsewhere. Connecting the two, while keeping admins in their familiar tools, is what good Salesforce architecture looks like.