Die Microsoft Cloud kann keine Massenmails! ...Oder etwa doch...?

E-Mail ist nach wie vor ein weit verbreitetes Kommunikationsmittel - auch wenn ihm der Rang mittlerweile von Sofortnachrichten-Lösungen wie Teams, Slack, uvm. abgelaufen wird. In vielen Unternehmen kommen hierfür Exchange Server, Exchange Online oder auch eine Kombination aus den beiden (sogenannte Hybridbereitstellung) zum Einsatz.

Irgendwann kann der Bedarf für einen Massenversand von E-Mails entstehen. Beispiele hierfür sind:

• Marketing-Kampagnen
• Einladungen zu Veranstaltungen
• Umfragen
• Newsletter

Die Problematik mit Massenmails

Hierbei werden Mails in kurzer Zeit an eine Vielzahl von Empfängern (vier- bis fünfstellige Anzahl, eventuell sogar mehr) gesendet. Dies erzeugt eine sehr hohe Last auf dem sendenden System. Auf der anderen Seite erkennen zentrale Sicherheitssysteme solche Aktionen gern als Spam-Angriffe. Das stellt die Betreiber der Versender-Infrastruktur vor besondere Herausforderungen.

Da Exchange Online ein Multi-Mandanten-System ist, muss Microsoft sicherstellen, dass Probleme einzelner Kunden nicht zu einer Beeinträchtigung aller Kunden führen. Daher gibt es einige Obergrenzen hinsichtlich Versand und Leistung. In der Vergangenheit führte dies daher stets zur Aussage: "Wenn Du Massenmails senden musst, brauchst Du ein Dritthersteller-Produkt oder einen lokalen Exchange Server." Ist dies immer noch so? Wir wollen sehen!

Warum Exchange Server eine Lösung sein kann

Sofern im Unternehmen noch ein aktueller (d.h. Subscription Edition, SE) Exchange Server existiert und weiterhin betrieben werden kann, könnte dieser für einen Massenversand eingesetzt werden.

Ein Exchange Server bietet eine sehr hohe Flexibilität, was die Anbindung von Systemen und den Versand angeht:

• Applikationen und Systeme können entweder mit oder ohne Authentifizierung E-Mails versenden (wobei authentifizierter Versand stets zu empfehlen ist).
• Es kann die (mittlerweile als unsicher geltende) Basisauthentifizierung bereitgestellt werden, die immer noch von einigen Applikationen und Systemen als einzige Methode unterstützt wird.
• E-Mails können sowohl an interne als auch an externe Empfänger gesendet werden.
• Grenzwerte können individuell konfiguriert oder auch deaktiviert werden.
• Die Hardwareausstattung des Servers kann flexibel an wachsende Anforderungen angepasst werden.

Sofern kein lizenzierter oder aktueller Exchange Server vorliegt, ist vom Aufbau eines Exchange Servers rein für den E-Mail-Versand eher abzuraten. Ein Exchange Server erzeugt einigen Wartungsaufwand und zusätzliche Komplexität. Hier mögen dann andere Lösungen und ggf. auch Dritthersteller-Produkte wie z.B. Postfix besser geeignet sein.

Massenmails in der Microsoft Cloud

Es herrscht nach wie vor die Ansicht, dass Massenmails in der Microsoft Cloud nicht möglich sind. Wenn man sich die aktuell verfügbaren Möglichkeiten und Begrenzungen anschaut, mag man jedoch ggf. zu einem anderen Schluss kommen. Schauen wir uns diese einmal an.

Exchange Online

Wie bereits erwähnt, ist Exchange Online ein Multi-Mandanten-System. Daher muss Microsoft dafür Sorge tragen, dass alle Kunden gleichwertig versorgt werden und sich nicht gegenseitig beeinträchtigen können. Daher gibt es einige technische Limitierungen. Ebenso gibt es Sicherheitserwägungen, die zu Einschränkungen bei den verfügbaren Zugriffsmethoden führen. Diese werden in den folgenden Kapiteln näher beschrieben.

Sendegrenzen

Eine vollständige Übersicht aller Begrenzungen enthält der folgende Artikel: Exchange Online-Begrenzungen - Service Descriptions | Microsoft Learn. Daraus sollen an dieser Stelle nur die Sendegrenzen betrachtet werden, die für einen Massenversand relevant sind. Diese sind wie folgt über alle Lizenzpakete hinweg einheitlich definiert (Stand: Juli 2026):

Aus dieser Tabelle wird ersichtlich, dass ein Massenversand von E-Mails zumindest in kleinerem Umfang und mit zusätzlichen Maßnahmen grundsätzlich möglich ist. Beispielsweise könnte der Versand wie folgt aufgeteilt werden, wenn die Gesamtzahl bei angenommenen 50.000 Mails liegt:

• 10 Durchläufe pro Tag mit jeweils 1.000 Empfängern
• Durchläufe für 5 Tage wiederholen

Ein solches Vorgehen eignet sich jedoch nur dann, wenn es kein Problem darstellt, dass die Empfänger die Mails nicht alle gleichzeitig erhalten. Ist dies erforderlich, eignet sich Exchange Online nicht als Lösung.

Zugriffsmethoden

Exchange Online bietet mehrere Wege an, um E-Mails aus Applikationen und Systemen zu versenden. Diese werden im Detail im folgenden Artikel beschrieben: Einrichten eines Multifunktionsgeräts oder einer Anwendung zum Senden von E-Mails mit Microsoft 365 oder Office 365 | Microsoft Learn

Die folgende Tabelle fasst die wichtigsten Kriterien zusammen:

Die Tabelle macht klar, dass sich für den Massenversand an externe Empfänger nur die Methode "SMTP-Clientübermittlung" eignet. Alle anderen Methoden unterstützen entweder keinen Massenversand oder ausschließlich an interne Empfänger.

Sofern die geltenden Grenzwerte und die damit verbundenen zusätzlichen Schritte als tragbar eingestuft werden, kann die SMTP-Clientübermittlung für den Massenversand eingesetzt werden. Das sendende System sollte jedoch hierfür bereits die moderne Authentifizierung mittels OAuth/Graph unterstützen. Dies stellt sicher, dass der Versand auch nach der Abschaltung von SMTP AUTH weiterhin funktioniert.

Konfiguration der SMTP-Clientübermittlung

Für die SMTP-Clientübermittlung sind grob zusammengefasst die folgenden Schritte durchzuführen:

• Lizenziertes Postfach (bei Verwendung von SMTP AUTH) oder freigegebenes Postfach (bei Verwendung von Graph) bereitstellen
  • Bei Verwendung eines lizenzierten Postfachs:
    • Per-Benutzer-MFA für Benutzerkonto aktivieren (Per-user multifactor authentication - Microsoft Entra admin center)
    • MFA-Methode registrieren (My Account)
    • Benutzerkonto aus Regeln des bedingten Zugriffs ausnehmen (ansonsten kann kein App-Kennwort erstellt werden)
    • App-Kennwort erstellen (My Sign-Ins | Security Info | Microsoft.com)
  • Bei Verwendung eines freigegebenen Postfachs:
    • App-Registrierung in Entra ID hinzufügen, keine Graph-Berechtigungen vergeben! (App-Registrierungen - Microsoft Entra Admin Center)
    • E-Mail-aktivierte Sicherheitsgruppe in Exchange Online erstellen und freigegebenes Postfach hinzufügen (Active groups - Exchange admin center)
    • Über Exchange Online PowerShell einen Verwaltungsbereich erstellen
    • Über Exchange Online PowerShell ein Dienstprinzipal erstellen und mit App-Registrierung verknüpfen
    • Über Exchange Online PowerShell eine Rollenzuweisung erstellen und hier die notwendigen Zugriffsrechte erteilen
  • Applikation bzw. System entsprechend der gewählten Authentifizierungsmethode konfigurieren (SMTP-Host: smtp.office365.com, Port 25)

Azure Communication Services

Die Microsoft Cloud beschränkt sich nicht nur auf Microsoft 365. Den viel größeren Bereich stellt Microsoft Azure dar. Hierbei handelt es sich grob vereinfacht um ein Rechenzentrum in der Cloud. Es lassen sich hier genauso wie in einem lokalen Rechenzentrum Infrastruktur-Komponenten wie Netzwerke, virtuelle Maschinen, Speicher, usw. bereitstellen.

Darüber hinaus können eine Vielzahl von Diensten bereitgestellt werden, die unterschiedlichste Funktionen bereitstellen. Auf diese Weise muss nicht erst eine virtuelle Maschine aufgebaut, konfiguriert und gewartet werden. Stattdessen wird einfach der gewünschte Dienst - beispielsweise ein Webserver, eine Container-Plattform oder ein Schlüsseltresor - bereitgestellt und kann direkt verwendet werden. Die Wartung der zugrundeliegenden Plattform erfolgt durch Microsoft.

Einer dieser Dienste ist Azure Communication Services (ACS). Dieser Dienst kann u.a. dazu genutzt werden, eine zentrale Plattform für den SMS- und E-Mail-Versand bereitzustellen. Er bietet darüber hinaus noch weitere Funktionen für direkte Kommunikation via Telefon und Sofortnachrichten wie Teams und Whatsapp.

ACS mag eine Überlegung wert sein, falls die in Exchange Online bestehenden Grenzen sowie die damit verbundenen zusätzlichen Schritte als nicht ausreichend bzw. umsetzbar eingestuft werden. Für den Aufbau wird ein Azure-Abonnement benötigt. Dieses kann entweder von Microsoft direkt oder genauso wie Microsoft 365-Lizenzen über einen CSP-Partner bezogen werden.

Sendegrenzen

Für ACS gibt es ebenfalls Obergrenzen. Allerdings liegen diese speziell für E-Mails weit höher als in Exchange Online. Eine vollständige Übersicht aller Grenzen kann hier eingesehen werden: Dienstgrenzwerte für Azure Communication Services - An Azure Communication Services article | Microsoft Learn

Die folgende Tabelle zeigt die Begrenzungen für den E-Mail-Versand für benutzerdefinierte Domänen (also beispielsweise eigene Domänen des Unternehmens, nicht von Azure bereitgestellte Domänen):

Darüber hinaus gibt es die folgenden Größenbeschränkungen:

Das mag zunächst merkwürdig anmuten, da mit diesen Werten kein Massenversand möglich ist. Hierbei handelt es sich jedoch um Startwerte, die jeweils über eine Supportanfrage bei Microsoft erhöht werden können. Microsoft beschreibt die Gründe für dieses Vorgehen in dem folgenden Artikel: Kontingenterhöhung für E-Mail-Domänen - An Azure Communication Services concept document | Microsoft Learn

Auch hier soll verhindert werden, dass ein System oder gar Microsoft Azure auf einer Liste von Spamabwehr-Anbietern landet. Dementsprechend wird durch eine schrittweise Anhebung der Grenzen sichergestellt, dass das Absendersystem weiterhin als vertrauenswürdig eingestuft wird. Sendet ein neues System plötzlich sehr viele Mails, wird sonst typischerweise davon ausgegangen, dass es sich um einen Spamversand handelt.

Auf diese Weise lassen sich die Grenzwerte wie folgt erhöhen:

• Bis zu 1-2 Millionen E-Mails pro Stunde
• Bis zu 30 MB Nachrichtengröße
• Unbegrenzte Anzahl an Empfängern

Die Nutzung von ACS wird verbrauchsorientiert abgerechnet:

• 0,00022€ pro gesendeter E-Mail
• 0,00011€ pro MB

Zugriffsmethoden

ACS unterstützt für den Verbindungsaufbau die folgenden Methoden:

Idealerweise verwenden Applikationen und Systeme ein Dienstprinzipal, welches über eine App-Registrierung bereitgestellt wird. Für die Authentifizierung ist die Verwendung eines Zertifikats empfohlen, da ein Clientgeheimnis im Prinzip ein Kennwort ist und damit als potenziell unsicher gilt.

Für Applikationen und Systeme, die dies nicht unterstützen, kann alternativ auch eine klassische Authentifizierung über Benutzernamen und Kennwort bereitgestellt werden. Die Authentifizierung erfolgt im Hintergrund ebenfalls über eine App-Registrierung, das Kennwort wird über ein Clientgeheimnis bereitgestellt.

Bereitstellung der Azure Communication Services

Für die Bereitstellung von ACS sind grob zusammengefasst die folgenden Schritte durchzuführen:

• Ressourcengruppe für die Aufnahme der einzelnen Bestandteile des Dienstes anlegen
• Nacheinander aus dem Marketplace die folgenden Dienste bereitstellen: Marketplace - Microsoft Azure
  • Communication Services
  • Email Communication Services
• App-Registrierung in Entra ID erstellen (ohne spezifische Berechtigungen)
• App-Registrierung über IAM auf Communication Services berechtigen (Berechtigungen: Einrichten der SMTP-Authentifizierung zum Senden von E-Mails - An Azure Communication Services article | Microsoft Learn)
• Clientgeheimnis für anzubindende Applikation erstellen
• Neu erstellten Email Communication Service aufrufen
  • Gewünschte Versanddomäne hinzufügen und SPF und DKIM nach Anforderung einrichten
  • Versanddomäne aufrufen und eine Absenderadresse hinzufügen
• Neu erstellten Communication Service aufrufen
  • Versanddomäne verbinden (die Validierung von SPF und DKIM muss vollständig erfolgreich sein!)
  • Für SMTP-Clientübermittlung ggf. einen SMTP-Benutzernamen hinzufügen
• Applikation bzw. System mit den notwendigen Daten konfigurieren (SMTP-Host: smtp.azurecomm.net, Port 587 oder 25)

Gegenüberstellung der Lösungen

Welche Lösung ist nun in welchem Nutzungsszenario die beste? Die folgende Tabelle zeigt hierfür einige Kriterien auf, die als Entscheidungshilfe dienen können:

Ein besonderes Thema ist die Handhabung von E-Mail-Signaturen. Wenn das Unternehmen der Anforderung unterliegt, dass sämtliche ausgehenden E-Mails mit einer Signatur ausgestattet sein müssen, kann dies evtl. ein Ausschlusskriterium für ACS sein. Es kommt hierbei dann auf die Möglichkeiten des absendenden Systems an.

Welche Alternativen gibt es?

Die Lösung SendGrid des Herstellers Twilio ist eine gute Alternative, wenn nicht zwingend eine Microsoft-Lösung oder eine lokal bereitgestellte Lösung zum Einsatz kommen muss. Sie ermöglicht einen massenhaften E-Mail-Versand unter Beachtung von SPF und DKIM, ein automatische Anfügen von Unternehmenssignaturen, und einiges mehr.

Hat Dir dieser Artikel gefallen? Lass es andere wissen!

• Share on LinkedIn
• Share on Bluesky
• Share on Facebook
• Email this Page
• Share on Reddit