Automatisierung22. September 20266 Min. Lesezeit

SMTP-Relay ablösen: Mails aus Geräten und Applikationen über Microsoft Graph senden

Drucker, Fachapplikationen und Skripte versenden oft noch über SMTP mit Benutzername und Passwort. Microsoft baut Basic Auth dafür ab. So stellen Sie auf Microsoft Graph um – sicher und auf einzelne Postfächer begrenzt.

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

VarianteFunktionsweiseGeeignet fürEinschränkungen
Connector-RelayGerät sendet per SMTP an den MX-Endpunkt Ihres Tenants; ein Inbound Connector erkennt es an der statischen öffentlichen IP oder am ZertifikatMehrere Geräte an einem Standort mit fester IPStatische IP nötig, IP muss ins SPF, jedes System hinter dieser IP kann senden
Direct SendGerät sendet ohne Anmeldung an den MX-EndpunktNur Empfänger im eigenen TenantKeine Authentifizierung, missbrauchsanfällig, kann in Exchange Online abgeschaltet werden
SMTP AUTH mit OAuthClient meldet sich per OAuth (XOAUTH2) an smtp.office365.com anApplikationen und neuere Geräte mit OAuth-UnterstützungViele Geräte und ältere Applikationen unterstützen es nicht
Microsoft Graph sendMailApplikation sendet über die Graph-API mit App-Registrierung und ZertifikatSkripte, eigene Applikationen, SMTP-BridgesApplikation 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 sendMail auch 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-ServicePrincipalAuthorization prü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.

Nils Lappenbusch

Nils Lappenbusch

Founder & Technology Architect, Lappenbusch

Schreibt hier über Probleme, die in echten Projekten auftreten: Microsoft 365, Security, Automatisierung und digitale Systeme. Hängen Sie gerade an genau diesem Thema? Dann lösen wir es gemeinsam, von der Diagnose bis zur Umsetzung.

Kontakt aufnehmen

Wo steckt Ihr Projekt gerade fest?

Erzählen Sie uns in 30 Minuten, worum es geht. Sie bekommen eine ehrliche Einschätzung und einen konkreten nächsten Schritt, auch wenn dieser nicht bei uns liegt.