Nach dem 31. Dezember 2026 kann der Versand eines Druckers über smtp.office365.com scheitern, wenn er sich weiterhin mit Benutzername und Kennwort anmeldet. In Rollouts bleiben vor allem Scanner, Überwachungssysteme und selten laufende Stapelprozesse lange unentdeckt. Kurze Tests reichen nicht. Eine SMTP-AUTH-Migration ist deshalb erst abgeschlossen, wenn eine 90-Tage-Auswertung keinen unbekannten Basic-Auth-Client mehr zeigt, weil Monats- und Quartalsprozesse in kürzeren Zeiträumen fehlen können.
Was ändert sich für SMTP AUTH Ende 2026?
Bis zum 31. Dezember 2026 ändert sich für bestehende Exchange-Online-Organisationen zunächst nichts. Danach ist Basic Auth für SMTP AUTH standardmäßig deaktiviert; neue Organisationen erhalten die veraltete Anmeldung nicht mehr als Standardoption. OAuth bleibt für SMTP AUTH verfügbar, sofern die Organisation und das betreffende Postfach SMTP AUTH zulassen.
Der frühere Zeitplan mit einer vollständigen Abschaltung bis April 2026 ist überholt. Eine endgültige Entfernung folgt nicht automatisch Anfang 2027. Der Termin dafür soll in der zweiten Jahreshälfte 2027 bekannt gegeben werden, sodass die technische Vorbereitung mit einer vollständigen Inventur beginnt.
SMTP AUTH Clients Report für die Inventur nutzen
Im Exchange Admin Center öffnest du den SMTP AUTH Clients Report unter Reports > Mail Flow. Der Berichtszeitraum umfasst 90 Tage, damit auch selten genutzte Geräte und Anwendungen erscheinen. Der Filterwert TlsAuthLogin kennzeichnet Basic Auth; bei moderner Authentifizierung weist der Bericht OAuth aus, während das SMTP-Verfahren auf dem Client XOAUTH2 heißt.
Der Export enthält Absenderadressen, Nachrichtenaufkommen und verwendete TLS-Versionen. Eine Arbeitsliste ergänzt für jeden Eintrag die verantwortliche Fachkraft sowie den Namen der Anwendung oder des Geräts. Auch das Empfängerprofil gehört hinein: Direct Send eignet sich nur für interne Empfänger, während externe Zustellung einen anderen Versandweg verlangt.
- Jeder Eintrag wird einer verantwortlichen Fachkraft und einer Anwendung oder einem Gerät zugeordnet
- Die Liste dokumentiert das Versandvolumen, den Netzwerkstandort, den Port und die TLS-Version
- Das Empfängerprofil unterscheidet zwischen interner und externer Zustellung
- Unbekannte Absender bleiben bis zur technischen Zuordnung in der Arbeitsliste
Wiederkehrende Exporte, API-Abfragen und Fehlerprotokolle lassen sich mit PowerShell nach denselben Regeln verarbeiten. Der PowerShell-Aufbaukurs behandelt dafür Funktionen, Fehlerbehandlung und automatisierte Abläufe. Die vervollständigte Arbeitsliste liefert anschließend die Daten für die technische Klassifizierung.
Drucker, Scanner und Anwendungen klassifizieren
Multifunktionsdrucker und Scanner unterscheiden sich erheblich bei OAuth-Unterstützung, STARTTLS und den verfügbaren TLS-Versionen. Weitere Systemklassen sind Monitoring-Systeme, ERP-Software, Fachanwendungen und automatische Benachrichtigungsdienste. Für jedes System werden die OAuth-Fähigkeit, der Empfängertyp und der Netzwerkpfad einzeln erfasst.
| Systemklasse | Technische Prüfung | Möglicher Zielweg |
|---|---|---|
| Aktuelle Anwendung | Eine OAuth-Bibliothek und TLS 1.2 sind vorhanden | SMTP AUTH mit XOAUTH2 oder eine Mail-API |
| Drucker oder Scanner | Das Gerät unterstützt TLS, aber kein OAuth | SMTP Relay über einen Connector |
| Reiner interner Versender | Es werden keine externen Empfänger benötigt | Direct Send |
| Veraltetes Gerät | OAuth und unterstützte TLS-Versionen fehlen | Austausch oder lokaler SMTP-Relayserver als Übergang |
Ein OAuth-fähiger Client kann direkt mit Exchange Online oder einer Mail-API arbeiten. Fehlt diese Unterstützung, entscheiden das Empfängerprofil und der Netzwerkpfad zwischen SMTP Relay und Direct Send.
OAuth, Microsoft 365 Printer SMTP Relay oder Direct Send?
OAuth passt zu Anwendungen, die Tokens verarbeiten können. Geräte ohne OAuth senden über einen Connector; Direct Send bleibt auf interne Empfänger beschränkt. Hohe Versandmengen benötigen einen dafür vorgesehenen Dienst und eine Prüfung der aktuellen Grenzwerte.
SMTP AUTH mit XOAUTH2
Aktuelle Anwendungen verwenden für Client SMTP Submission den Endpunkt smtp.office365.com, Port 587, STARTTLS und XOAUTH2. Individuell entwickelte Cloud-Anwendungen können stattdessen Microsoft Graph mit Mail.Send nutzen. Client SMTP Submission ist auf 10.000 Empfänger pro Tag und 30 Nachrichten pro Minute begrenzt, weshalb Systeme mit höheren Versandmengen einen anderen Weg benötigen.
Relay, Direct Send und High Volume Email
Ein Microsoft 365 Printer SMTP Relay führt Drucker und Scanner ohne OAuth über einen Exchange-Online-Connector. Der Connector authentifiziert die Verbindung über ein TLS-Zertifikat oder eine feste öffentliche IP-Adresse. Direct Send verwendet den MX-Endpunkt der Microsoft-365-Domäne auf Port 25 und erreicht ausschließlich Empfänger innerhalb der eigenen Organisation.
High Volume Email kommt nur infrage, wenn der Dienst im Tenant verfügbar ist und seine aktuellen Grenzwerte zum Empfängerprofil passen. Ein lokaler SMTP-Relayserver kann mehrere Altgeräte bündeln, bleibt aber eine Übergangslösung mit eigenem Betriebs- und Sicherheitsaufwand. Der ausgewählte Versandweg bestimmt damit die folgende Berechtigungs- und Connector-Konfiguration.
Den Zielweg absichern
Eine OAuth-Anwendung erhält nur die Berechtigung, die ihr Versandweg benötigt. Delegierte SMTP-Verbindungen verwenden den Scope https://outlook.office.com/SMTP.Send. App-only-Verbindungen benötigen SMTP.SendAsApp, einen Exchange-Online-Service-Principal und Zugriff auf die vorgesehenen Postfächer.
Zertifikate oder Client-Secrets gehören in einen geschützten Schlüsselspeicher. Der Erneuerungsprozess hält das Ablaufdatum, die verantwortliche Fachkraft und einen Funktionstest fest. Beim SMTP Relay müssen der Zertifikatsname oder die öffentliche Ausgangsadresse zu den Connector-Bedingungen passen.
Direct Send wird mit dem MX-Endpunkt auf Port 25 konfiguriert und darf keine externen Empfänger adressieren. Für SMTP AUTH lässt sich der Dienst auf Organisationsebene deaktivieren und nur für benötigte Postfächer freischalten. Die folgenden Befehle setzen dieses Muster für ein Beispielpostfach um:
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
Set-TransportConfig -SmtpClientAuthenticationDisabled $true
Set-CASMailbox -Identity smtp-sender@contoso.com -SmtpClientAuthenticationDisabled $false$true blockiert SMTP AUTH auf Organisationsebene für Basic Auth und OAuth, sofern keine Postfachausnahme besteht. Der Wert $false am Postfach lässt beide Verfahren auf dieser Konfigurationsebene zu, weshalb eine Authentication Policy Basic Auth zusätzlich blockieren muss. Security Defaults und weitere Authentifizierungsrichtlinien können SMTP AUTH ebenfalls beeinflussen.
Abhängigkeiten von TLS 1.0 oder TLS 1.1 werden vor der Umstellung beseitigt. Erst wenn der Client TLS 1.2 verwendet und die Berechtigungen stimmen, beginnt der Pilot unter kontrollierten Bedingungen.
Pilot und Testplan kontrolliert ausführen
Eine separate Testidentität verhindert Änderungen an bestehenden Versandkonten während der Konfiguration. Für SMTP AUTH kann das ein Testpostfach sein; Relay und Direct Send verwenden eine eigene Absenderadresse aus einer akzeptierten Domäne. Der Testplan enthält einen internen Empfänger und, sofern der Versandweg dies unterstützt, einen externen Empfänger.
Der Test erfasst die Zustellung, die sichtbare Absenderidentität, die SPF- und DKIM-Ergebnisse sowie die ausgehandelte TLS-Version. Message Trace zeigt, ob Exchange Online eine angenommene Nachricht weitergeleitet, umgeleitet oder später abgewiesen hat. Verbindungsfehler vor der Annahme erscheinen dagegen nur in den Protokollen des Clients oder Relayservers.
Negative Tests umfassen einen unberechtigten Relay-Versuch und eine externe Nachricht über Direct Send, die erwartungsgemäß scheitert. Vor der Produktionsänderung dokumentiert ein Rollback die vorherigen Connector-, Postfach- und Anwendungseinstellungen. Abweichungen aus dem Pilot grenzen anschließend die Fehlerquelle ein.
Fehler bei der SMTP-AUTH-Migration beheben
Fehlt eine Testnachricht trotz bekanntem Versandzeitpunkt vollständig in Message Trace, hat Exchange Online sie wahrscheinlich nicht angenommen. OAuth-Fehler entstehen häufig durch einen falschen Scope, abgelaufene Zugangsdaten, einen fehlenden Service Principal oder deaktiviertes SMTP AUTH am Postfach. Manche älteren SMTP-Bibliotheken unterstützen AUTH XOAUTH2 nicht, obwohl das Betriebssystem OAuth-Tokens abrufen kann.
| Befund | Prüfung |
|---|---|
550 5.7.30 weist Basic Auth für Client Submission zurück |
Der Client muss XOAUTH2 verwenden oder auf einen anderen Versandweg wechseln |
| Die OAuth-Anmeldung schlägt fehl | Tokenberechtigung, Zugangsdaten, Service Principal und SMTP-AUTH-Mailboxeinstellung werden geprüft |
| Der Connector lehnt Relay-Nachrichten ab | Zertifikatsname, öffentliche IP-Adresse, akzeptierte Domäne und TLS-Vorgabe werden abgeglichen |
Der SMTP AUTH Clients Report zeigt während der Umstellung, ob TlsAuthLogin zurückgeht und OAuth zunimmt. Das Seminar Exchange Online für Messaging-Administratoren behandelt Mail Flow, DNS, Exchange Online PowerShell und Message Trace in einer Testumgebung. Erst wenn alle verbleibenden Basic-Auth-Verbindungen zugeordnet sind, folgt die Abschaltung.
Basic Auth deaktivieren und das Ergebnis überwachen
Eine Exchange Online Authentication Policy mit deaktiviertem AllowBasicAuthSmtp blockiert Basic Auth, ohne XOAUTH2 grundsätzlich abzuschalten. Parallel bleibt SmtpClientAuthenticationDisabled auf Organisationsebene auf $true; nur Postfächer mit einem benötigten OAuth-Client erhalten die Ausnahme $false. Alle anderen Postfächer können dann kein SMTP AUTH verwenden.
SMTP-Berichte, Message Trace sowie Geräte- und Anwendungsprotokolle zeigen unerwartete Versandfehler. Nach einem weiteren 90-Tage-Zeitraum dürfen keine Verbindungen mit TlsAuthLogin mehr erscheinen. Nicht mehr benötigte Postfachausnahmen werden entfernt, während verbleibende Ausnahmen einen eigenen Ablaufplan erhalten.
Befristete Ausnahmen absichern und entfernen
Bestehende Exchange-Online-Organisationen können Basic Auth nach der standardmäßigen Deaktivierung vorübergehend wieder aktivieren, solange die Funktion noch nicht endgültig entfernt ist. Diese Rückfalloption ersetzt keine Migration. App-Passwörter lösen das Problem ebenfalls nicht, weil sie weiterhin Basic Auth verwenden.
- Weise jeder Ausnahme eine verantwortliche Person und ein verbindliches Ablaufdatum zu
- Nutze ein separates Versandkonto ohne interaktive Aufgaben
- Beschränke den Netzwerkzugriff auf die bekannte Anwendung oder das bekannte Gerät
- Überwache Anmeldungen und Versandfehler des Kontos mit eigenen Alarmen
- Hinterlege einen Austauschplan für das Gerät oder die Anwendung und kontrolliere den Abschlusstermin
Basic Auth bleibt nach Ende 2026 nur als zeitlich begrenzte Rückfalloption verfügbar. Lege jetzt eine 90-Tage-Arbeitsliste an, die jeden unbekannten Absender einer verantwortlichen Fachkraft zuordnet.