On January 06, 2026, the Exchange team surprisingly put on the brakes. The planned introduction of the Mailbox External Recipient Rate Limit (MERR) has been officially canceled indefinitely.
Originally, this technical restriction was intended to cap the sending of e-mails to external recipients at 2,000 pieces per 24 hours (rolling window).
The limit, which was originally planned for January 2025 and then pushed back to April 2026 , was intended to make Exchange Online less attractive to spammers. But Microsoft had to realize that the restriction of legitimate business processes would be too high.
- SOURCE | Microsoft Community Hub:
Exchange Online canceling the Mailbox External Recipient Rate Limit - News | borncity.com/blog:
Exchange Online: “Mailbox External Recipient Rate Limit” is not coming
Why the limit (thankfully) failed
The withdrawal is primarily an admission of a lack of alternatives. The technical problem lies in the discrepancy between the security requirement and the user workflow:
- Missing replacement: Microsoft couldn’t provide a user-friendly alternative for the “gray area” between individual email and bulk mailing.
- Hurdles with Azure Communication Services (ACS): The logical fallback route, ACS or Email Communication Services (ECS), requires technical implementation and separate cost structures. A marketing employee who is used to sending newsletters to partners via Outlook is barred from doing so.
- PDB pivot: The High-Volume Email (HVE) solution has been strategically realigned and focuses primarily on internal application and device communication (scanners, LOB apps), not on external mass sending by users.
This created a dead end: If the limit had been enforced, legitimate business workflows would have hit the wall without a working workaround.
PhinIT | Microsoft introduces the External Recipient Rate (ERR) limit :
Microsoft 365 | Clever recipient limit and mail load
What will remain?
The fact that Microsoft has released the “handbrake” for external recipients (the planned 2,000 limit) does not mean that Exchange Online is now open for unlimited mass sending. The platform’s protections continue to work to secure Microsoft 365’s IP reputation and prevent spam waves from compromised accounts.
Admins need to understand: The removal of the new limit does not change the existing service limits, which are firmly anchored in the Exchange architecture. If these are exceeded, Exchange immediately blocks further sending – often with painful consequences for the affected user (block for 24 hours).
Most important limits at a glance
| Limit Value | Description | |
| Recipient Rate | Limit10,000recipients | Maximum number of recipients (internal + external) that a single mailbox is allowed to write to in a 24-hour window. If the limit is reached, the user can only send again after the time has expired. |
| Recipients Per Mail (Recipient Limit) | 500 Recipients | Maximum number in the “To”, “Cc” and “Bcc” fields of a single email. Larger distribution lists must be solved via groups or distribution lists. |
| Message Rate Limit30 | per minute | Protection against scripts running amok or malware. Those who send faster end up in the queue (throttling) or are temporarily blocked. |
| Distribution Group Limit100,000 | members | Maximum size of a static distribution list (stored in the Shared Address Book). |
- Microsoft Learn | Exchange Online Limits – Service Descriptions
Tenant-Level Limit
Particularly treacherous is the tenant-level External Recipient Rate Limit, which is often forgotten. This is not a rigid number, but a dynamic value for your entire organization. Microsoft charges an outbound email cap based on the number of seats you have and the age of the tenant.
The danger: If a single user exceeds this organization-wide limit by sending a newsletter, in the worst case the e-mail sending for all users in the company can be disrupted, as the IP reputation of the tenant suffers or Microsoft puts the tenant in “Restricted Mode”.
Alternatives (or not?)
From a technical point of view, Azure Communication Services (ACS) would have been the correct architectural answer: You cleanly separate bulk sending from regular user traffic to protect your tenant’s IP reputation.
The practical problem: ACS is a pure developer tool (API) without a frontend. There is simply no “send” button for your department. A marketing manager cannot send JSON payloads to an API. Since the preview for High Volume Email (HVE) was now also strategically focused on machine communication (SMTP for printer/scanner) instead of user dispatch, Microsoft had no choice: Without a functional bridge for the power user, the limit had to fall.
Assessment & Outlook
Microsoft’s decision is a victory of operational reality over theoretical security concepts. It is rare for Redmond to completely cancel an announced security hardening measure. This clearly shows how massive the customer feedback must have been.
Recommendation: You can leave your existing distribution workflows unchanged for the time being. However, keep an eye on the roadmap! Microsoft has announced that it is working on “smarter approaches” than ACS.
So the topic is not off the table, but only postponed.
Be the first to comment