Es ist die letzte Bastion der Basic Authentication in Exchange Online. Für IMAP, POP, EWS und MAPI hat Microsoft die Passwort-Anmeldung bereits im Oktober 2022 abgeschaltet, nur bei SMTP AUTH durfte sie bisher bleiben. Damit ist bald Schluss: Ende Dezember 2026 deaktiviert Microsoft Basic Auth für SMTP AUTH in bestehenden Tenants standardmässig. Neue Tenants ab Januar 2027 bekommen sie gar nicht mehr, und im zweiten Halbjahr 2027 folgt das endgültige, unwiderrufliche Enddatum. Wer Geräte oder Skripte betreibt, die sich mit Benutzername und Passwort per SMTP an Exchange Online anmelden, sollte jetzt handeln, auch wenn sich die Frist reaktivieren lässt.
Worum es genau geht
SMTP AUTH, auch «authenticated client SMTP submission» genannt, ist das Protokoll, mit dem Anwendungen und Geräte E-Mails zur Verarbeitung an Exchange Online übergeben, typischerweise über TCP-Port 587. Wichtig ist die Unterscheidung: SMTP AUTH unterstützt zwei Anmeldeverfahren, die veraltete Basic Authentication (Benutzername plus Passwort) und die moderne Authentifizierung via OAuth. Abgeschaltet wird nur Basic Auth. SMTP AUTH als solches bleibt bestehen, sofern die anmeldende Anwendung auf OAuth umgestellt ist.
Betroffen ist ausschliesslich Exchange Online. An SMTP-Anmeldungen gegen einen lokalen Exchange Server (auch im Hybrid) ändert sich nichts – sofern die Geräte wirklich gegen den lokalen Server einliefern. Viele Hybrid-Umgebungen senden heute schon direkt gegen «smtp.office365.com», und diese Verbindungen sind sehr wohl betroffen.
Warum Microsoft Basic Auth abschaltet
Basic Authentication sendet Benutzername und Passwort bei jeder Verbindung mit. Das macht sie anfällig für Passwort-Spray- und Replay-Angriffe und verhindert wirksame mehrstufige Authentifizierung.
Genau darum hat Microsoft ab Oktober 2022 Basic Auth für die meisten Protokolle entfernt. SMTP AUTH war damals die bewusste Ausnahme, weil unzählige Drucker, Scanner und Fachanwendungen darauf angewiesen sind. Diese Ausnahme läuft nun aus. OAuth löst das Problem, indem sich Anwendungen über kurzlebige Token statt über ein dauerhaft gültiges Passwort anmelden.Der Zeitplan im Überblick
Der Weg dorthin war lang und mehrfach verschoben. Ursprünglich sollte Basic Auth für SMTP AUTH bereits im September 2025 fallen, danach war eine gestaffelte Ablehnung ab dem 1. März 2026 bis 100 Prozent am 30. April 2026 geplant. Beides wurde nach Kundenrückmeldungen gecancelt. Das ist der aktuelle, am 27. Januar 2026 bestätigte Stand:
| Termin | Was passiert |
|---|---|
| Bis Ende Dezember 2026 | Unverändert: Bestehende Tenants können Basic Auth mit SMTP AUTH weiter nutzen. |
| Ende Dezember 2026 | Microsoft deaktiviert Basic Auth für SMTP AUTH in bestehenden Tenants standardmässig. Admins können den Block vorübergehend wieder aufheben und Basic Auth reaktivieren. |
| Ab Januar 2027 | Neu erstellte Tenants können Basic Auth mit SMTP AUTH gar nicht mehr verwenden, nur noch OAuth. |
| Zweites Halbjahr 2027 | Microsoft kündigt das endgültige Enddatum an. Danach ist Basic Auth für SMTP AUTH nicht mehr verfügbar, auch keine Reaktivierung mehr. |
Die Reaktivierbarkeit Ende 2026 ist ein Sicherheitsnetz, kein Freibrief. Sie verschafft nur Zeit, um die eigentliche Umstellung zu Ende zu bringen.
Wer ist betroffen?
Typische Kandidaten in der Praxis:
- Multifunktionsdrucker und Scanner mit «Scan-to-Mail»
- Fachanwendungen (ERP, CRM, Ticketsysteme, Business Central/NAV), die Benachrichtigungen versenden
- Monitoring-, Backup- und Alarmierungssysteme
- Selbst geschriebene Skripte, etwa PowerShell mit «Send-MailMessage» und hinterlegten Zugangsdaten
- Alte Web- und Formularanwendungen, die per SMTP versenden
Gerade Drucker und seit Jahren laufende Skripte geraten in Vergessenheit. Genau die fallen als Erste aus, wenn Basic Auth wegfällt.
Schritt 1: Eigene Nutzung im Tenant finden
Bevor man etwas umstellt, muss man wissen, wer überhaupt Basic Auth per SMTP nutzt. Zwei Blickwinkel helfen.
Erstens die Konfiguration: Welche Postfächer haben SMTP AUTH überhaupt aktiviert? Die organisationsweite Einstellung und der Postfach-Status lassen sich per PowerShell auslesen:
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
Get-CASMailbox -ResultSize unlimited |
Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } |
Format-Table Identity, SmtpClientAuthenticationDisabled
Zweitens die tatsächliche Nutzung, und hier lohnen sich zwei Quellen. Die Entra-Anmeldeprotokolle (Entra Admin Center, Überwachung, Anmeldeprotokolle) mit dem Filter «Clientanwendung = SMTP» (in der Microsoft-Dokumentation «Authenticated SMTP» genannt) zeigen pro Konto und Quell-IP, wer sich per SMTP AUTH anmeldet, inklusive Erfolg oder Fehlschlag. Ob dabei Basic Auth oder bereits OAuth zum Einsatz kommt, verraten sie aber nicht eindeutig.
Genau das zeigt der SMTP AUTH Clients Report im Exchange Admin Center (Berichte, Nachrichtenfluss): Die Spalte «Authentication Protocol» weist pro Einlieferung aus, ob Basic Auth (TlsAuthLogin) oder Modern Auth (XOAUTH2) verwendet wurde. Damit ist dieser Report die präziseste Quelle, um Systeme zu identifizieren, die noch auf Basic Auth angewiesen sind – die Entra-Logs liefern ergänzend das «Wer und woher». Zu beachten: Die Protokoll-Spalte ist eine junge Ergänzung, ihre Daten bauen sich laut Hinweis im Admin Center erst über 90 Tage auf. Wer den Report zum ersten Mal öffnet, sieht die Unterscheidung also möglicherweise noch unvollständig.
In unserem Tenant ist der Befund erwartungsgemäss eindeutig: «No data available for given query» – keine einzige SMTP-AUTH-Einlieferung. Der Report bestätigt damit auf dem dritten Weg, was Konfiguration und Anmeldeprotokolle bereits gezeigt haben.
Der SMTP AUTH Clients Report im Exchange Admin Center: keine Einlieferungen, und der Hinweis auf die neue Spalte «Authentication Protocol» (Datenaufbau über 90 Tage).
Wie das in der Praxis aussieht, zeigt der Blick in unseren eigenen produktiven Tenant. Die organisationsweite Einstellung ist dort bereits gesetzt («SmtpClientAuthenticationDisabled : True»), und trotzdem fördert der Check etwas zutage: Ein einzelnes Postfach hat eine explizite Ausnahme auf Postfachebene, darf SMTP AUTH mit Basic Auth also weiterhin nutzen. Die restlichen 22 Postfächer erben die Organisationseinstellung.
Der Check im produktiven Tenant: organisationsweit deaktiviert, aber ein Postfach mit expliziter Ausnahme.
Genau solche vergessenen Ausnahmen sind der Punkt, an dem es interessant wird. Ob die Ausnahme noch gebraucht wird, verrät der Abgleich mit den Anmeldeprotokollen. In unserem Fall ist der Befund eindeutig: Sowohl bei den interaktiven als auch bei den nicht-interaktiven Anmeldungen liefert der Filter «Clientanwendung = SMTP» über den letzten Monat kein einziges Ergebnis, «No sign-ins found». Niemand und nichts meldet sich in diesem Tenant noch per SMTP AUTH an, auch das Konto mit der Ausnahme nicht.
Interaktive Anmeldungen, Filter «Clientanwendung = SMTP», letzter Monat: keine Treffer.
Wichtig, auch hier prüfen: Geräte- und Skript-Anmeldungen erscheinen im nicht-interaktiven Reiter. Ebenfalls keine Treffer.
Damit ist die Ausnahme nachweislich ungenutzt, und intern erinnert sich niemand an einen aktiven Einsatzzweck. Dann gehört sie entfernt, das Postfach fällt zurück auf die Organisationseinstellung:
Set-CASMailbox -Identity "Max Muster" -SmtpClientAuthenticationDisabled $null
Die anschliessende Kontrolle bestätigt das Aufräumen: keine Ausnahmen mehr, alle 23 Postfächer erben die organisationsweite Deaktivierung. Damit ist der Tenant vollständig sauber, und zwar belegt statt vermutet.
Nachher: Ausnahme zurückgesetzt, die Kontrolle zeigt 0 Ausnahmen, alle Postfächer auf Organisationseinstellung.
Achtung beim 30-Tage-Fenster: Die Anmeldeprotokolle zeigen je nach Lizenz nur 7 bis 30 Tage. Ein Gerät, das seltener sendet (etwa ein Quartalsreport), taucht darin nicht auf. Vor dem Entfernen einer Ausnahme lohnt sich deshalb die Rückfrage beim betroffenen Benutzer oder Systemverantwortlichen.
So sieht der Zielzustand aus, hier in unserem zweiten Tenant: keine einzige Ausnahme, alle Postfächer erben die organisationsweite Deaktivierung.
Der Zielzustand: SMTP AUTH organisationsweit deaktiviert, null Ausnahmen, alle Postfächer auf Organisationseinstellung.
Zeigt der eigene Tenant hingegen «SmtpClientAuthenticationDisabled : False» oder finden sich in den Anmeldeprotokollen aktive SMTP-Anmeldungen, dann gilt es, diese Konten und die dahinterliegenden Geräte und Skripte zu identifizieren und auf eine der folgenden Alternativen umzustellen.
Schritt 2: Die passende Alternative wählen
OAuth für SMTP AUTH. Der direkte Nachfolger. Das Gerät oder die Anwendung meldet sich weiterhin per SMTP an Port 587 an, aber mit einem OAuth-Token statt Passwort. Voraussetzung ist eine App-Registrierung in Entra ID mit der passenden Berechtigung und ein Gerät bzw. eine Software, die OAuth für SMTP unterstützt. Bei Fachanwendungen und Druckern entscheidet der Hersteller, ob und wann das kommt, hier lohnt die frühe Nachfrage.
PowerShell-Skripte umstellen. Für viele Skripte mit «Send-MailMessage» und Basic Auth bieten sich die Graph-Cmdlets «Send-MgUserMail» oder «Send-MgUserMessage» aus dem Microsoft Graph PowerShell SDK an. Diese authentifizieren sich per OAuth (App-only oder delegiert) und benötigen kein hinterlegtes Passwort mehr. Graph ersetzt SMTP aber nicht eins zu eins: Wo ein Skript auf SMTP-Verhalten angewiesen ist (eigene Header, Relay-Logik), kann SMTP AUTH mit OAuth die einfachere Migrationsvariante sein als die komplette Portierung auf Graph.
SMTP-Relay über einen Connector. Geräte, die kein OAuth können, müssen sich nicht zwingend authentifizieren. Über einen eingehenden Connector in Exchange Online, der auf einer festen öffentlichen IP oder einem Zertifikat basiert, lässt sich unauthentifiziertes Relay einrichten. Das ersetzt SMTP AUTH vollständig, verlangt aber eine statische IP und sauberes Absender-Handling.
High Volume Email (HVE). Für interne Massenmails (Benachrichtigungen an viele interne Empfänger) hat Microsoft HVE eingeführt, seit dem 31. März 2026 allgemein verfügbar. Microsoft plant für HVE einen Support von Basic Auth bis September 2028 und bietet damit zusätzlichen Migrationsspielraum für interne Mail-Workloads. Wichtig dabei: Der Spielraum gilt für Basic Auth innerhalb von HVE, auch dort steht der Umstieg auf OAuth am Ende an.
Azure Communication Services Email. Für anwendungsgenerierte E-Mails in grossem Umfang, entkoppelt vom Postfach, bietet sich ACS Email an. Sinnvoll, wenn eine Anwendung ohnehin umgebaut wird.
Ausweichen auf einen anderen SMTP-Dienst. Lässt sich ein altes Gerät gar nicht modernisieren, bleibt der Weg, Exchange Online aus der Kette zu nehmen und einen externen SMTP-Dienst oder einen lokalen Server zu nutzen. Auch lokale OAuth-Proxys, die Basic Auth auf OAuth übersetzen, kursieren, sind aber ungetestetes Terrain.
Schritt 3: SMTP AUTH gezielt abschalten
Unabhängig von der Frist gilt: SMTP AUTH sollte nur dort aktiv sein, wo es wirklich gebraucht wird. Microsoft empfiehlt, es organisationsweit zu deaktivieren und nur einzelne Postfächer freizuschalten.
Organisationsweit abschalten:
Set-TransportConfig -SmtpClientAuthenticationDisabled $true
Für ein einzelnes Postfach gezielt erlauben (überschreibt die Org-Einstellung):
Set-CASMailbox -Identity scanner@contoso.com -SmtpClientAuthenticationDisabled $false
Der Wert «$null» pro Postfach bedeutet, dass die Organisationseinstellung greift. So bleibt die Angriffsfläche klein, und man weiss jederzeit genau, welche Konten SMTP AUTH überhaupt nutzen dürfen.
Fazit
Basic Auth für SMTP AUTH ist die letzte Passwort-Anmeldung, die in Exchange Online noch übrig ist, und auch sie verschwindet. Der Stichtag Ende Dezember 2026 ist zwar reaktivierbar, aber das endgültige Aus kommt im zweiten Halbjahr 2027. Die Arbeit dazwischen ist immer dieselbe: die eigene Nutzung inventarisieren, pro Anwendung die passende Alternative wählen (OAuth, Connector-Relay, HVE oder Ersatz) und SMTP AUTH überall sonst abschalten. Wie beim EWS-Retirement liegt das Risiko nicht bei Microsoft, sondern bei den seit Jahren vergessenen Druckern und Skripten.
Wer bei der Analyse des eigenen Tenants oder der Umstellung Unterstützung braucht: Ich helfe gerne weiter. Meine E-Mail-Adresse steht in den Kontaktdaten dieses Blogs.
Quellen
- Exchange Team Blog: Exchange Online to retire Basic auth for Client Submission (SMTP AUTH)
- Exchange Team Blog: Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline (27.01.2026)
- Microsoft Learn: Enable or disable authenticated client SMTP submission (SMTP AUTH) in Exchange Online
- Microsoft Learn: Authenticate an IMAP, POP or SMTP connection using OAuth
- Microsoft Learn: SMTP AUTH clients report in the new EAC
- Office 365 for IT Pros: Microsoft Delays Retirement of Basic Authentication for SMTP AUTH







Keine Kommentare:
Kommentar veröffentlichen