- High Volume Email (HVE) ist seit dem 31. März 2026 allgemein verfügbar in Exchange Online und ermöglicht den Massenversand interner Mails über dedizierte HVE-Accounts – ohne Recipient Rate Limit.
- Die Kosten liegen bei 42 USD pro eine Million Empfänger (Abrechnung startet am 1. Juni 2026), HVE-Accounts brauchen keine Lizenz – für die meisten Organisationen ist das praktisch kostenlos.
- HVE unterstützt OAuth und Basic Auth (bis September 2028) und eignet sich für LOB-Apps, IT-Alerting, HR-Systeme und Geräte wie Scanner, aber nicht für externen Versand oder Marketing.
Ihr kennt das vermutlich: Irgendwo im Tenant gibt es eine Shared Mailbox, die eigentlich für den Helpdesk gedacht war, aber inzwischen auch als Absender für die Gehaltsabrechnungen der HR-Software herhalten muss. Oder ein On-Prem Exchange, den eigentlich niemand mehr will, der aber noch als SMTP-Relay für Scanner und Monitoring-Mails am Leben gehalten wird. Und wehe, das Recipient Rate Limit greift – dann trudeln die Alerts aus dem Monitoring erst drei Stunden später ein.
Microsoft hat mit High Volume Email (HVE) jetzt ein Feature in Exchange Online gebracht, das genau dafür gemacht ist. Seit dem 31. März 2026 ist es allgemein verfügbar, nach knapp zwei Jahren Public Preview. Schauen wir uns an, was dahintersteckt.
Was ist High Volume Email eigentlich?
Im Kern ist HVE ein eigener Dienst innerhalb von Exchange Online, der automatisierte Massen-Mails an interne Empfänger ermöglicht – und zwar ohne die normalen Sendelimits. Statt reguläre User-Mailboxen oder Shared Mailboxes dafür zu missbrauchen, legt ihr dedizierte HVE-Accounts an. Die sind ein spezieller Typ Mail-User, brauchen keine Lizenz und laufen über einen eigenen SMTP-Endpunkt (smtp-hve.office365.com, Port 587, TLS).
Der entscheidende Punkt: Es gibt kein Recipient Rate Limit für HVE-Accounts. Die üblichen 10.000 Empfänger pro Tag, die bei normalen Mailboxen gelten, spielen hier keine Rolle. Nachrichten bleiben komplett innerhalb der Microsoft-Infrastruktur, eure Compliance- und Security-Policies greifen also ganz normal weiter.
Was HVE nicht ist: ein Newsletter-Tool, eine Marketing-Plattform oder ein Ersatz für Drittanbieter wie Mailchimp. Es gibt keine Templates, kein Engagement-Tracking, keine Kampagnen-Verwaltung. HVE ist für operative, interne Kommunikation gebaut. Nicht mehr, nicht weniger.
Für welche Szenarien ist das gedacht?
Mal ganz praktisch: HVE macht Sinn, wenn Anwendungen oder Geräte in eurem Unternehmen regelmäßig größere Mengen E-Mails an interne Empfänger verschicken müssen. Das kann vieles sein – HR-Systeme, die Gehaltsabrechnungen oder Onboarding-Infos verteilen. Monitoring-Tools wie SCOM oder Zabbix, die Alerts und Statusberichte rausschicken. LOB-Apps, die Workflow-Benachrichtigungen oder Genehmigungsanfragen per Mail auslösen. Scanner und Drucker mit Scan-to-Mail. Oder automatisierte Security-Alerts aus eurem Monitoring oder eurem eurer XDR-Lösung.
Wenn ihr aktuell dafür einen On-Prem Exchange als SMTP-Relay betreibt, eine Shared Mailbox zweckentfremdet oder einen Drittanbieter-Relay nutzt – dann lohnt sich ein Blick auf HVE.
Was kostet der Spaß?
Microsoft rechnet nutzungsbasiert ab. 42 US-Dollar pro eine Million Empfänger. Abgerechnet wird nach tatsächlich aufgelösten Empfängern – eine Mail an eine Verteilerliste mit 500 Mitgliedern zählt also als 500 Empfänger.
Um das mal einzuordnen: Ein Unternehmen, das täglich 10.000 interne Benachrichtigungen verschickt, landet bei rund 300.000 Empfängern im Monat. Kosten: etwa 1,3 Cent. Das ist im Grunde kostenlos. Selbst bei 100.000 Mails pro Tag seid ihr bei rund 130 USD im Monat – für die meisten Organisationen also wirklich kein Thema.
Wichtig: Die Abrechnung startet erst am 1. Juni 2026. Bis dahin läuft eine kostenlose Einführungsphase. Ihr könnt also jetzt schon loslegen und testen, ohne dass Kosten anfallen.
Was ihr vor dem Rollout wissen solltet
Ein paar Einschränkungen, die ihr auf dem Schirm haben solltet:
Nur interne Empfänger. HVE kann ausschließlich an Empfänger innerhalb eures Tenants senden. Die Möglichkeit für externen Versand hat Microsoft Mitte 2025 entfernt. Wer externe Massen-Mails braucht, soll auf Azure Communication Services (ACS) ausweichen. Finde ich auch nachvollziehbar. Damit ist klar abgegrenzt, wofür welcher Dienst da ist.
Maximal 50 Empfänger pro einzelner Nachricht. Klingt erstmal wenig, aber HVE ist ja für automatisierte Systeme gedacht. Die verschicken in der Regel sowieso personalisierte Einzelmails oder arbeiten die Empfänger in Batches ab.
Bis zu 100 HVE-Accounts pro Tenant. Mehr als genug. Legt am besten pro Anwendung oder Gerätegruppe einen eigenen Account an – das macht die Nachverfolgung über die HVE-Reports im EAC deutlich einfacher.
Kein Sent-Items-Ordner. HVE-Accounts speichern keine gesendeten Nachrichten. Für die Nachvollziehbarkeit nutzt ihr die HVE-Reports im Exchange Admin Center oder Message Trace.
Authentifizierung: OAuth und Basic Auth
HVE unterstützt sowohl OAuth als auch Basic Auth. Microsoft hat zugesichert, dass Basic Auth für HVE bis September 2028 erhalten bleibt – und das ist auch gut so, weil viele Geräte und ältere LOB-Apps schlicht kein OAuth können. Fragt mal euren Drucker-Hersteller, wann der OAuth-Support kommt. Die Antwort wird euch wahrscheinlich nicht begeistern.
Trotzdem: Wer die Wahl hat, sollte auf OAuth setzen. Token-basierte Authentifizierung, kein Passwort im Klartext, granulare Berechtigungen – das ist einfach die bessere Basis. HVE unterstützt sowohl Application- als auch Delegated Permissions.
Eine Sache, das gerne übersehen wird: Wenn ihr Security Defaults in Entra ID aktiviert habt, ist Basic Auth komplett deaktiviert – und damit auch HVE mit Basic Auth. Ihr müsst dann entweder auf OAuth umstellen oder Security Defaults deaktivieren und stattdessen Conditional Access Policies verwenden. In dem Fall solltet ihr eure HVE-Accounts gezielt von Policies ausschließen, die Legacy Auth blockieren. Am besten über eine eigene Entra-ID-Gruppe für HVE-Accounts – das hält die Ausnahmen sauber und übersichtlich.
Schnellstart: So richtet ihr HVE ein
Die Einrichtung ist wirklich unkompliziert. Im Exchange Admin Center geht ihr auf Mail flow → High Volume Email, klickt auf Add an HVE account, vergebt Display Name, E-Mail-Adresse und Passwort. Das war's.
Per Exchange Online PowerShell geht's noch schneller:
# HVE-Account erstellen
$pw = Read-Host "Passwort eingeben" -AsSecureString
New-MailUser -HVEAccount -Name "Scanner Erdgeschoss" -Password $pw -PrimarySmtpAddress "[email protected]"
# Alle HVE-Accounts im Tenant anzeigen
Get-MailUser -HVEAccount
Die SMTP-Settings für eure Apps und Geräte:
- Server: smtp-hve.office365.com
- Port: 587
- TLS/StartTLS: Aktiviert
- Credentials: HVE-Account (Basic Auth oder OAuth)
Ein Tipp: Benennt eure HVE-Accounts sprechend, z.B. hve-scanner_erdgeschoss@, hve-monitoring@, hve-scanner-og2@. Dann seht ihr im Reporting sofort, welche App wie viel Volumen erzeugt – und könnt bei Problemen gezielt eingreifen.
HVE vs. SMTP Client Submission vs. SMTP Relay
Kurz zur Einordnung, weil das gerne durcheinandergeworfen wird:
SMTP Client Submission (Port 587, User-Credentials) bleibt sinnvoll für Geräte oder Apps, die als bestimmter User senden und wo das Volumen innerhalb der normalen Limits bleibt.
SMTP Relay (Port 25, IP-basiert über Connector) ist der richtige Weg, wenn ihr auch an externe Empfänger senden müsst und feste IPs habt.
HVE ist die Wahl, wenn ihr hohe Volumina an interne Empfänger braucht und die bestehenden Limits nicht reichen – oder wenn ihr endlich den On-Prem Exchange loswerden wollt, der nur noch als Relay rumsteht.
Und was ist mit den Legacy-Geräten?
Jetzt kommt der Haken, über den erstaunlich wenig geschrieben wird: HVE setzt TLS und Authentifizierung voraus. Das ist aus Security-Sicht absolut richtig. Aber wenn ihr in die Realität vieler Umgebungen schaut, habt ihr da Drucker, die kein TLS können. Scanner, die nur Plain SMTP auf Port 25 sprechen. ERP-Systeme, die seit 15 Jahren unverändert ihren SMTP-Relay ansprechen. Und einen Etikettendrucker in der Produktion, der nicht mal weiß, was ein Passwort ist.
Für genau dieses Szenario haben wir die itelio SMTP-Relay Appliance gebaut. Die steht als gehärtete Linux-VM in eurer Infrastruktur, nimmt Mails von euren Legacy-Systemen so entgegen, wie diese es können – also bei Bedarf auch ohne TLS, ohne Auth, Plain SMTP auf Port 25 – und leitet sie über die Microsoft Graph API sicher an Exchange Online weiter. Authentifiziert über eine Entra ID Enterprise App, nicht über Benutzerpasswörter.
Wenn ihr da Interesse habt, meldet euch gern ganz formlos bei uns.
HVE und die SMTP-Relay Appliance schließen sich nicht gegenseitig aus. Im Gegenteil: HVE ist die richtige Lösung für moderne Anwendungen, die OAuth oder zumindest Basic Auth beherrschen und hohe Volumina intern verschicken. Die Appliance deckt alles ab, was HVE nicht kann. Legacy-Geräte ohne TLS-Support, Geräte in abgeschotteten VLANs, oder Szenarien, in denen ihr eine zentrale Stelle für Monitoring und Troubleshooting eures gesamten Application-Mailflows braucht.
Fazit
HVE löst ein Problem, das viele Exchange-Admins seit Jahren mit Workarounds umgehen mussten. Keine zweckentfremdeten Shared Mailboxes mehr, kein On-Prem-Relay das nur aus diesem einen Grund noch existiert – zumindest für moderne Anwendungen, die TLS und Authentifizierung beherrschen.
Für alles, was darunter fällt – und das ist in vielen Umgebungen mehr als man denkt – braucht es eine Lösung, die die Lücke zwischen Legacy-Welt und Cloud schließt.
Nutzt die kostenlose Phase bis Juni 2026, um HVE in eurem Tenant zu testen und eure Anwendungen schrittweise umzustellen. Und schaut euch parallel an, welche eurer Geräte und Systeme HVE überhaupt ansprechen können – und welche nicht.
Ihr wollt eure Mail-Flow-Architektur aufräumen und wissen, welche Kombination aus HVE und Relay-Lösung in eurem Fall Sinn macht? Meldet euch bei uns – wir schauen uns das gemeinsam an.
.jpeg)
