In fast jedem Unternehmen gibt es sie: das Multifunktionsgerät mit Scan-to-Mail, die Fachapplikation, die Rechnungen verschickt, das Monitoring, das Alarme meldet, und das PowerShell-Skript, das nachts einen Bericht versendet. Viele davon nutzen SMTP AUTH mit Benutzername und Passwort gegen Exchange Online. Das funktioniert – ist aber ein Sicherheitsrisiko und hat ein Ablaufdatum.
Dieser Artikel zeigt die Alternativen, erklärt, warum Microsoft Graph mit Zertifikat in den meisten Fällen der sauberste Weg ist, und wie Sie auch Geräte anbinden, die nur SMTP sprechen.
Warum der klassische SMTP-Relay zum Problem wird
- Passwörter an vielen Orten: Die Zugangsdaten des Versandkontos stehen im Webinterface des Druckers, in Konfigurationsdateien und in Skripten. Wer eines dieser Systeme kompromittiert, kann im Namen des Unternehmens Mails versenden.
- MFA-Ausnahmen: Damit SMTP AUTH funktioniert, wird das Konto oft von Conditional Access oder MFA ausgenommen. Genau solche Ausnahmen werden gezielt angegriffen.
- Kein Überblick: Häufig weiss niemand mehr, welche Systeme welches Konto verwenden. Ein Passwortwechsel legt dann unbemerkt Prozesse lahm.
- Auslaufende Technik: Microsoft baut Basic Auth für SMTP AUTH in Exchange Online schrittweise ab. Prüfen Sie den aktuellen Zeitplan im Microsoft 365 Message Center – und planen Sie die Umstellung, bevor sie erzwungen wird.
Die Optionen im Überblick
| Variante | Funktionsweise | Geeignet für | Einschränkungen |
|---|---|---|---|
| Connector-Relay | Gerät sendet per SMTP an den MX-Endpunkt Ihres Tenants; ein Inbound Connector erkennt es an der statischen öffentlichen IP oder am Zertifikat | Mehrere Geräte an einem Standort mit fester IP | Statische IP nötig, IP muss ins SPF, jedes System hinter dieser IP kann senden |
| Direct Send | Gerät sendet ohne Anmeldung an den MX-Endpunkt | Nur Empfänger im eigenen Tenant | Keine Authentifizierung, missbrauchsanfällig, kann in Exchange Online abgeschaltet werden |
| SMTP AUTH mit OAuth | Client meldet sich per OAuth (XOAUTH2) an smtp.office365.com an | Applikationen und neuere Geräte mit OAuth-Unterstützung | Viele Geräte und ältere Applikationen unterstützen es nicht |
Microsoft Graph sendMail | Applikation sendet über die Graph-API mit App-Registrierung und Zertifikat | Skripte, eigene Applikationen, SMTP-Bridges | Applikation muss Graph sprechen oder eine Bridge nutzen |
Für Skripte und Applikationen, die Sie selbst kontrollieren, ist Graph meist die beste Wahl. Für Geräte ohne OAuth-Unterstützung bleibt der Connector-Relay oder eine lokale Bridge, die SMTP entgegennimmt und über Graph weiterleitet.
Graph sendMail mit Zertifikat: der saubere Weg
Der Versand über Graph basiert auf einer App-Registrierung in Entra ID. Die Applikation meldet sich mit einem Zertifikat an und sendet über den Endpunkt POST /users/{postfach}/sendMail. Die Vorteile:
- Kein Passwort: Die Anmeldung erfolgt mit einem Zertifikat, dessen privater Schlüssel das System nicht verlässt. Client Secrets sind möglich, aber nur zweite Wahl – sie sind letztlich wieder Passwörter.
- Keine MFA-Ausnahme für Benutzerkonten: Es meldet sich keine Person an, sondern die Applikation. Für Workload-Identitäten lassen sich eigene Regeln festlegen.
- Nachvollziehbar: Die Anmeldungen der Applikation erscheinen in den Entra-Anmeldeprotokollen für Service Principals.
- DMARC-konform: Die Mail wird von Exchange Online versendet und mit dem DKIM-Schlüssel Ihrer Domain signiert.
Ein Haken: Die Anwendungsberechtigung Mail.Send erlaubt in Entra ID das Senden im Namen jedes Postfachs im Tenant. Ohne Einschränkung ist eine solche App ein ideales Werkzeug für Angreifer. Die Berechtigung muss deshalb zwingend auf die Versandpostfächer begrenzt werden.
Achtung: Eine App mit tenantweitem Mail.Send ohne Einschränkung kann sich als Geschäftsleitung, Buchhaltung oder jede andere Person ausgeben. Prüfen Sie bestehende App-Registrierungen auf solche Berechtigungen.
Zugriff auf bestimmte Postfächer einschränken
Exchange Online bietet dafür zwei Mechanismen. Die ältere Application Access Policy (New-ApplicationAccessPolicy) beschränkt eine App auf die Mitglieder einer mail-aktivierten Sicherheitsgruppe. Microsoft empfiehlt heute RBAC for Applications: Die Berechtigung wird direkt in Exchange Online vergeben und über einen Management Scope auf bestimmte Postfächer begrenzt.
Connect-ExchangeOnline
# Service Principal der Enterprise App in Exchange Online registrieren
New-ServicePrincipal -AppId "<Application-ID>" -ObjectId "<Object-ID der Enterprise App>" -DisplayName "Graph Mail Relay"
# Scope: nur Postfächer mit CustomAttribute10 = GraphMailSend
New-ManagementScope -Name "Scope-GraphMailRelay" -RecipientRestrictionFilter "CustomAttribute10 -eq 'GraphMailSend'"
Set-Mailbox -Identity "scanner@example.ch" -CustomAttribute10 "GraphMailSend"
# Senderecht nur innerhalb dieses Scopes vergeben
New-ManagementRoleAssignment -App "<Object-ID der Enterprise App>" -Role "Application Mail.Send" -CustomResourceScope "Scope-GraphMailRelay"
# Prüfen: darf die App für dieses Postfach senden?
Test-ServicePrincipalAuthorization -Identity "<Object-ID der Enterprise App>" -Resource "scanner@example.ch"
Wichtig: Bei RBAC for Applications wird Mail.Send nicht zusätzlich in Entra ID mit Admin-Consent vergeben. Berechtigungen aus beiden Quellen addieren sich – eine tenantweite Freigabe in Entra ID hebelt den Scope aus.
Tipp: Verwenden Sie für Geräte und Applikationen dedizierte Versandpostfächer, etwa scanner@ oder noreply@. Shared Mailboxes benötigen dafür keine Lizenz und lassen sich sauber einem Scope zuordnen.
Geräte, die nur SMTP sprechen: eine lokale Bridge
Viele Multifunktionsgeräte und ältere Applikationen können weder OAuth noch Graph. Ersetzen lassen sie sich selten kurzfristig. Hier hilft eine kleine lokale Bridge: ein Dienst im internen Netz, der Mails per SMTP entgegennimmt und über Graph weiterleitet.
- Entgegennahme: Die Bridge akzeptiert SMTP nur aus definierten internen Netzen oder von bestimmten IP-Adressen, etwa dem Drucker-VLAN. Sie ist nie aus dem Internet erreichbar.
- Weiterleitung: Graph akzeptiert in
sendMailauch eine komplette MIME-Nachricht (Base64-kodiert). Die Bridge muss die Mail also nicht zerlegen, sondern reicht sie weitgehend unverändert durch. - Absender-Kontrolle: Die Bridge lässt nur erlaubte Absenderadressen zu und sendet ausschliesslich über die im Scope freigegebenen Postfächer.
- Grosse Anhänge: Scans können gross werden. Für Anhänge über wenigen Megabyte ist der Weg über einen Entwurf mit Upload-Session nötig – das muss die Bridge beherrschen.
- Betrieb: Zertifikat mit Ablaufüberwachung, Logging der versendeten Mails, Warteschlange für den Fall, dass Graph vorübergehend nicht erreichbar ist.
Für solche Bridges gibt es Open-Source-Projekte und kommerzielle Produkte. Oft reicht aber ein schlanker, selbst betriebener Dienst, der genau die benötigten Funktionen abdeckt und sich im eigenen Netz kontrollieren lässt.
Checkliste für die Umstellung
Checkliste
- Alle Systeme erfassen, die per SMTP AUTH senden (Anmeldeprotokolle und SMTP-AUTH-Berichte in Exchange Online helfen dabei)
- Pro System den Weg festlegen: Graph direkt, SMTP AUTH mit OAuth, Connector-Relay oder Bridge
- Dedizierte Versandpostfächer anlegen
- App-Registrierung mit Zertifikat statt Client Secret einrichten
- Senderecht über RBAC for Applications auf die Versandpostfächer begrenzen, keine tenantweite Freigabe in Entra ID
- Mit
Test-ServicePrincipalAuthorizationprüfen, dass andere Postfächer gesperrt sind - SPF, DKIM und DMARC für die Absenderdomain kontrollieren
- Zertifikatsablauf überwachen und Erneuerung dokumentieren
- Nach der Umstellung SMTP AUTH für die betroffenen Konten deaktivieren und alte Passwörter entfernen
Die Umstellung ist selten technisch schwierig. Aufwendig ist meist die Bestandsaufnahme – herauszufinden, welches Gerät mit welchem Konto sendet. Wer das einmal sauber erfasst hat, gewinnt nicht nur Sicherheit, sondern auch einen dokumentierten Überblick über alle automatisierten Mailflüsse im Unternehmen.