Microsoft schaltet SMTP AUTH mit Basic Authentication im September 2025 ab

SMTP AUTH mit Basic Authentication begegnet mir in Exchange Online regelmäßig. Meist steckt ein unscheinbares Multifunktionsgerät dahinter, eine ältere Fachanwendung oder ein kleines PowerShell-Skript, das brav mit Benutzername und Passwort seine E-Mails verschickt. In vielen Tenants, die ich mir ansehe, läuft dieser Mechanismus noch unbemerkt im Hintergrund, obwohl Basic Auth für die übrigen Exchange-Protokolle schon seit Ende 2022 abgeschaltet ist. Im April 2024 hat Microsoft nun auch für diesen letzten Rest ein festes Enddatum genannt: Im September 2025 ist endgültig Schluss (Exchange Online to retire Basic Auth for Client Submission (SMTP AUTH)). Wer sich bisher nicht um Alternativen gekümmert hat, sollte das jetzt nachholen.

Vor allem Scanner, Altanwendungen und Skripte hängen noch an Basic Auth

Die üblichen Kandidaten sind schnell ausgemacht. Da wären Scanner und Multifunktionsdrucker, die Dokumente direkt per E-Mail verschicken, ältere Line-of-Business-Anwendungen, die ihre Berichte per Mail versenden, und allerlei Skripte, die noch das gute alte Send-MailMessage-Cmdlet verwenden. Lange Zeit hieß die Devise „Hauptsache, es läuft“, und SMTP AUTH mit Basic Auth war über Jahre der bequemste Weg. Microsoft rät zwar schon länger dazu, frühzeitig auf moderne Authentifizierung oder andere Versandwege umzusteigen. Im Projektalltag fehlte dafür aber oft die Zeit, das Budget oder schlicht das Bewusstsein dafür, wie groß das Risiko tatsächlich ist.

Für jeden Anwendungsfall gibt es einen passenden Ersatz

Die letzten Inseln mit SMTP AUTH und Basic Authentication gehören also gezielt auf den Prüfstand. Welcher Ansatz passt, hängt vom jeweiligen Einsatzzweck ab:

• OAuth für SMTP AUTH: SMTP AUTH funktioniert inzwischen auch mit OAuth 2.0. Das ist sicherer, allerdings unterstützt es noch nicht jedes Gerät und jede Anwendung.
• High Volume Email (Preview): Für große Versandmengen, etwa Rechnungen oder Systemmeldungen, testet Microsoft gerade diesen neuen Dienst.
• Direct Send oder SMTP-Relay: Viele Multifunktionsgeräte lassen sich auf Direct Send umstellen (ohne Authentifizierung, der Absender muss intern sein) oder auf einen SMTP-Relay-Connector mit fester IP-Adresse (Anleitung).
• Azure Communication Services: Moderne Anwendungen sind auf dieser Plattform gut aufgehoben, zumal sie sich problemlos in Azure-basierte Workloads einfügt.

In jedem Fall sollte man Anforderungen und technische Möglichkeiten einzeln prüfen. Für den Scanner reicht häufig Direct Send, bei Anwendungen mit externen Empfängern wird es in der Regel aufwendiger. Für den Einstieg empfehle ich die offizielle Dokumentation zur Client-Übermittlung per SMTP AUTH.

Der SMTP-AUTH-Bericht zeigt, welche Konten noch betroffen sind

In größeren Tenants ist es erfahrungsgemäß gar nicht so einfach, alle verbliebenen Nutzer von SMTP AUTH mit Basic Authentication ausfindig zu machen. Hilfreich ist dabei der SMTP-AUTH-Clients-Report, den Microsoft im Exchange Admin Center unter „Berichte“ bereitstellt. Er listet die Konten auf, die sich in den letzten Wochen noch per Basic Auth angemeldet haben. In meinen Projekten bin ich auf diese Weise schon auf so manchen vergessenen Dienst gestoßen. Darüber hinaus rate ich dazu, SMTP AUTH tenantweit und, wo möglich, auch pro Postfach zu deaktivieren. Das erledigt zum Beispiel dieser Befehl:

Set-TransportConfig -SmtpClientAuthenticationDisabled $true

Danach ist die Funktion global gesperrt. Einzelne Ausnahmen lassen sich pro Postfach wieder freischalten. Rechnen Sie allerdings damit, dass manche Geräte ziemlich kryptische Fehlermeldungen ausgeben, sobald SMTP AUTH nicht mehr funktioniert.

Ich empfehle dringend, vor der Deaktivierung das Reporting durchzugehen und festzuhalten, welche Geräte oder Dienste betroffen sind. Andernfalls steht womöglich plötzlich der Rechnungslauf oder die Scan-to-Mail-Funktion still, und das merkt meist erst jemand im laufenden Betrieb.

Ein Flussdiagramm zeigt die möglichen Sendepfade

Damit das Ganze anschaulicher wird, habe ich die verschiedenen SMTP-Sendepfade in einer kleinen Übersicht zusammengestellt. Das folgende Mermaid-Flussdiagramm stellt beispielhaft die klassische SMTP AUTH mit Basic Authentication den Alternativen OAuth und Direct Send gegenüber:

flowchart TD
    Device["Gerät / App"] --> AuthBasic["SMTP AUTH Basic Auth"]
    Device --> AuthOAuth["SMTP AUTH OAuth"]
    Device --> DirectSend["Direct Send"]
    AuthBasic --> ExO["Exchange Online"]
    AuthOAuth --> ExO
    DirectSend --> ExO
    ExO --> Recipient["Empfänger"]

Abbildung: Mögliche Wege für den E-Mail-Versand über Exchange Online

Die Umstellung gelingt umso entspannter, je früher sie beginnt

In der Praxis erlebe ich häufig, dass die Abschaltung von Basic Auth für SMTP AUTH unterschätzt wird. Das liegt vor allem daran, dass das Verfahren so unauffällig im Hintergrund arbeitet. Ganz gleich, ob es um Scanner, Skripte oder kleine Anwendungen geht: Wer jetzt untätig bleibt, wird im September 2025 böse überrascht. Es lohnt sich, das Thema aktiv anzugehen und die vorhandenen Möglichkeiten tatsächlich zu nutzen. Meine Projekte haben mir gezeigt, dass der Umstieg umso reibungsloser verläuft, je früher man sich von Basic Authentication trennt, und die Sicherheit steigt dabei spürbar. Wer ohnehin gerade Microsoft-365-Workloads modernisiert, nimmt SMTP AUTH am besten gleich mit auf die To-do-Liste.

Weitere Hinweise zur sicheren E-Mail-Konfiguration in Exchange Online finden Sie in meinem Beitrag zu SPF, DKIM und DMARC.