Am 06. Januar 2026 hat das Exchange-Team überraschend eine Vollbremsung hingelegt. Die geplante Einführung des Mailbox External Recipient Rate Limit (MERR) ist offiziell und auf unbestimmte Zeit abgesagt.
Ursprünglich sollte diese technische Restriktion den Versand von E-Mails an externe Empfänger auf 2.000 Stück pro 24 Stunden (Rolling Window) deckeln.
Das Limit, das ursprünglich für Januar 2025 geplant war und dann auf April 2026 verschoben wurde, sollte Exchange Online unattraktiver für Spammer machen. Doch Microsoft musste einsehen, dass die Einschränkung legitimer Geschäftsprozesse zu hoch wäre.
- QUELLE | Microsoft Community Hub:
Exchange Online canceling the Mailbox External Recipient Rate Limit - Newsmeldung | borncity.com/blog:
Exchange Online: „Mailbox External Recipient Rate Limit“ kommt nicht
Warum das Limit (zum Glück) scheiterte
Der Rückzug ist primär ein Eingeständnis fehlender Alternativen. Das technische Problem liegt in der Diskrepanz zwischen Sicherheitsanforderung und User-Workflow:
- Fehlender Ersatz: Microsoft konnte keine benutzerfreundliche Alternative für den „Graubereich“ zwischen individueller E-Mail und Massenversand bereitstellen.
- Hürden bei Azure Communication Services (ACS): Die logische Ausweichroute, ACS bzw. Email Communication Services (ECS), erfordert technische Implementierung und separate Kostenstrukturen. Einem Marketing-Mitarbeiter, der gewohnt ist, via Outlook Newsletter an Partner zu senden, ist dieser Weg versperrt.
- HVE-Pivot: Die High-Volume Email (HVE) Lösung wurde strategisch neu ausgerichtet und fokussiert sich primär auf interne Applikations- und Geräte-Kommunikation (Scanner, LOB-Apps), nicht auf den externen Massenversand durch User.
Dadurch entstand eine Sackgasse: Wäre das Limit durchgesetzt worden, wären legitime Business-Workflows ohne funktionierenden Workaround gegen die Wand gefahren.
PhinIT | Microsoft führt das External Recipient Rate (ERR) Limit ein:
Microsoft 365 | Empfänger Limit und Mail-Last clever bewältigen
Was bleibt bestehen?
Dass Microsoft die „Handbremse“ für externe Empfänger (das geplante 2.000er Limit) gelöst hat, bedeutet keinesfalls, dass Exchange Online nun für unlimitierten Massenversand offensteht. Die Schutzmechanismen der Plattform greifen weiterhin, um die IP-Reputation von Microsoft 365 zu sichern und Spam-Wellen durch kompromittierte Accounts zu verhindern.
Admins müssen verstehen: Der Wegfall des neuen Limits ändert nichts an den bestehenden Service Limits, die fest in der Exchange-Architektur verankert sind. Werden diese überschritten, blockiert Exchange den weiteren Versand sofort – oft mit schmerzhaften Folgen für den betroffenen User (Sperre für 24 Stunden).
wichtigste Limits im Überblick
| Limit | Wert | Beschreibung |
| Empfängerlimit pro Tag (Recipient Rate Limit) | 10.000 Empfänger | Maximale Anzahl an Empfängern (intern + extern), die ein einzelnes Postfach in einem 24-Stunden-Fenster anschreiben darf. Wird das Limit erreicht, kann der User erst nach Ablauf der Zeit wieder senden. |
| Empfänger pro Mail (Recipient Limit) | 500 Empfänger | Maximale Anzahl im „An“, „Cc“ und „Bcc“ Feld einer einzigen E-Mail. Größere Verteiler müssen über Gruppen oder Distribution Lists gelöst werden. |
| Nachrichtenrate (Message Rate Limit) | 30 pro Minute | Ein Schutz gegen Amok laufende Scripte oder Malware. Wer schneller sendet, landet in der Warteschlange (Throttling) oder wird temporär blockiert. |
| Verteilerlisten-Größe (Distribution Group Limit) | 100.000 Mitglieder | Maximale Größe einer statischen Verteilerliste (gespeichert im Shared Address Book). |
- Microsoft Learn | Exchange Online-Begrenzungen – Service Descriptions
Tenant-Level Limit
Besonders tückisch ist das Tenant-level External Recipient Rate Limit, das oft vergessen wird. Dies ist keine starre Zahl, sondern ein dynamischer Wert für deine gesamte Organisation. Microsoft berechnet hierbei eine Obergrenze für ausgehende E-Mails basierend auf der Anzahl deiner lizenzierten Plätze und dem Alter des Tenants.
Die Gefahr: Wenn ein einzelner User durch einen Newsletter-Versand dieses organisationsweite Limit sprengt, kann im schlimmsten Fall der E-Mail-Versand für alle Benutzer im Unternehmen gestört werden, da die IP-Reputation des Tenants leidet oder Microsoft den Tenant in den „Restricted Mode“ versetzt.
Alternativen (oder doch nicht?)
Technisch betrachtet wäre Azure Communication Services (ACS) die korrekte Architektur-Antwort gewesen: Du trennst Massenversand (Bulk) sauber vom regulären User-Traffic, um die IP-Reputation deines Tenants zu schützen.
Das Praxis-Problem: ACS ist ein reines Entwickler-Werkzeug (API) ohne Frontend. Es fehlt schlicht der „Senden-Button“ für deine Fachabteilung. Ein Marketing-Manager kann keine JSON-Payloads an eine API schicken. Da auch die Preview für High Volume Email (HVE) mittlerweile strategisch auf Maschinen-Kommunikation (SMTP für Drucker/Scanner) statt auf User-Versand fokussiert wurde, blieb Microsoft keine Wahl: Ohne funktionale Brücke für den Power-User musste das Limit fallen.
Einschätzung & Ausblick
Microsofts Entscheidung ist ein Sieg der operativen Realität über theoretische Sicherheitskonzepte. Es ist selten, dass Redmond eine angekündigte Security-Hardening-Maßnahme komplett streicht. Das zeigt deutlich, wie massiv das Kunden-Feedback gewesen sein muss.
Empfehlung: Du kannst deine bestehenden Verteiler-Workflows vorerst unverändert lassen. Behalte jedoch die Roadmap im Auge! Microsoft hat angekündigt, an „smarteren Ansätzen“ als ACS zu arbeiten.
Das Thema ist also nicht vom Tisch, sondern nur vertagt.
Hinterlasse jetzt einen Kommentar