322 votesJrdn supported this idea ·
Our service is designed to protect the resources and ensure that certain users will not overwhelm it and cause latency for others. This limit is in place to protect against spike sending that we wish to discourage. As such, we have no plans to change the limit for regular mailboxes.
Where possible, we encourage customers who have these requirements to seek solutions that do not send emails all at once, can make use of DLs, or use services like Dynamics or third-party services to send large volumes of emails to customers or student and parents.
However, we are thinking about alternatives we can provide to solve this issue of higher sending for automated email scenarios to address this customer need.
An error occurred while saving the commentJrdn commented
Many legacy business applications have very limited email configurations, due to having been built for wholly on prem infrastructure. I don't see a reason that it would be a problem for most applications if the mailbox would accept the mail and que it in the outbox until it can be sent.
This is actually affecting is most on the receive side. Some of our edge devices currently only support email reporting, and many are running jobs on a schedule which means we could have 50+ notifications at one time. The 30 messages per min is causing dropped reporting email
I would be in favor of allowing admins to increase the limit to some slightly higher limit, or adding in a "bulk" SKU of some sort to allow mailboxes to bypass the limit.