Microsoft 365 „535 5.7.139 Authentication unsuccessful“: so behebst du es

Was das bedeutet

Deine Anwendung, Website, dein Drucker oder Skript hat sich mit Microsoft 365 (smtp.office365.com) verbunden, um eine E-Mail zu senden, und versucht, sich mit Benutzername und Passwort anzumelden. Microsoft hat den Login abgelehnt. Der Fehler kommt während des SMTP-Dialogs zurück, bevor irgendeine E-Mail gesendet wird. Die häufigsten Varianten sind:

535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant.
535 5.7.139 Authentication unsuccessful, the user credentials were incorrect.
535 5.7.139 Authentication unsuccessful, user is locked by your organization's security defaults policy.
535 5.7.139 Authentication unsuccessful, the request did not meet the criteria to be authenticated successfully.

Der Text nach dem Komma sagt dir, welche Einstellung den Login blockiert hat, lies ihn also genau. Diese Art der Anmeldung zum Senden von E-Mails heißt SMTP AUTH (oder „authenticated client submission“), meist auf Port 587.

Warum das passiert

• SMTP AUTH ist ausgeschaltet für die ganze Organisation (Tenant) oder für dieses Postfach. Microsoft empfiehlt, es ausgeschaltet zu lassen und nur für die Konten zu aktivieren, die es brauchen, und hat es in Tenants, die es nicht genutzt haben, bereits abgeschaltet.
• Die Sicherheitsstandards sind aktiv (Security defaults) in Microsoft Entra ID. Laut Microsoft-Dokumentation ist SMTP AUTH bei aktivierten Sicherheitsstandards deaktiviert, selbst wenn du es für ein Postfach einschaltest.
• Die Standardauthentifizierung ist blockiert durch eine Authentifizierungsrichtlinie oder eine Richtlinie für bedingten Zugriff (Conditional Access), die „Legacy-Authentifizierung“ sperrt. Die Meldung sagt dann meist, dass die Anfrage „did not meet the criteria“.
• Falsche Zugangsdaten oder MFA. Ein falsches oder abgelaufenes Passwort oder ein durch Multi-Faktor-Authentifizierung geschütztes Konto kann sich nicht mit einem einfachen Passwort anmelden. App-Kennwörter funktionieren mit der Standardauthentifizierung nicht mehr.
• Das Konto hat kein nutzbares Postfach: keine Exchange-Online-Lizenz oder ein freigegebenes Postfach, dessen Anmeldung gesperrt ist.

Das Ende der Standardauthentifizierung

Microsoft schafft die Standardauthentifizierung (Basic authentication, also einfacher Benutzername und Passwort) für SMTP AUTH ab. Der Zeitplan hat sich mehrfach verschoben. Zum Zeitpunkt des Schreibens sagt die letzte Ankündigung von Microsoft (Januar 2026), dass das Verhalten bis Dezember 2026 unverändert bleibt; Ende Dezember 2026 wird die Standardauthentifizierung für SMTP AUTH bei bestehenden Tenants standardmäßig deaktiviert, Admins können sie aber wieder einschalten, und ein endgültiges Abschaltdatum wird in der zweiten Jahreshälfte 2027 bekanntgegeben. Prüfe im Exchange-Team-Blog die aktuellen Daten. Die langfristige Lösung ist OAuth 2.0 („moderne Authentifizierung“).

So prüfst du es

1. Kopiere den vollständigen Fehler aus dem Log deiner Anwendung. Der Teil nach „Authentication unsuccessful“ zeigt auf die Ursache.
2. Prüfe in Exchange Online PowerShell die Einstellungen der Organisation und des Postfachs:

   Connect-ExchangeOnline
   Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
   Get-CASMailbox -Identity app@yourdomain.com | Format-List SmtpClientAuthenticationDisabled

   True heißt deaktiviert. Beim Postfach bedeutet ein leerer Wert „der Einstellung der Organisation folgen“.
3. Geh im Microsoft 365 Admin Center zu Users > Active users, wähle das Konto und dann Mail > Manage email apps und sieh dir Authenticated SMTP an.
4. Prüfe im Microsoft Entra Admin Center, ob die Sicherheitsstandards aktiviert sind und ob eine Conditional-Access-Richtlinie die Legacy-Authentifizierung blockiert. Die Anmeldeprotokolle von Entra zeigen den fehlgeschlagenen Versuch und die Richtlinie, die ihn blockiert hat.
5. Teste von Hand mit swaks (du siehst die genaue Antwort des Servers):

   swaks --server smtp.office365.com --port 587 --tls \
     --auth LOGIN --auth-user app@yourdomain.com --auth-password 'your-password' \
     --from app@yourdomain.com --to you@example.com

Antwortet der Server stattdessen, dass du dich vor MAIL FROM authentifizieren musst, meldet sich dein Tool gar nicht an: siehe 530 5.7.57 Client not authenticated.

So behebst du es

Beste Option: stell die App auf OAuth 2.0 um

Unterstützt deine Anwendung die Anmeldung per „Microsoft 365 / OAuth“, nutze sie. Microsoft dokumentiert, wie du eine App in Microsoft Entra ID registrierst und OAuth mit SMTP AUTH verwendest. In nodemailer übergibst du zum Beispiel ein Access Token statt eines Passworts:

const transporter = nodemailer.createTransport({
  host: 'smtp.office365.com',
  port: 587,
  secure: false,       // STARTTLS on port 587
  requireTLS: true,
  auth: { type: 'OAuth2', user: 'app@yourdomain.com', accessToken: token }
});

Für deinen eigenen Code umgeht der Versand über die Microsoft Graph API (sendMail) SMTP AUTH komplett.

Wenn du vorerst bei einem Passwort bleiben musst

1. Aktiviere SMTP AUTH nur für das Postfach, das sendet, nicht für die ganze Organisation:

   Set-CASMailbox -Identity app@yourdomain.com -SmtpClientAuthenticationDisabled $false

2. Sind die Sicherheitsstandards aktiv, bleibt SMTP AUTH blockiert. Die Alternative ist, die Sicherheitsstandards durch Conditional-Access-Richtlinien zu ersetzen (dafür braucht es eine Entra-ID-P1-Lizenz), die für Menschen weiterhin MFA verlangen, dieses eine Dienstkonto aber zulassen. Denk über die Auswirkungen auf die Sicherheit nach, bevor du das änderst.
3. Nutze ein eigenes Postfach mit einem langen, einmaligen Passwort, einer Lizenz und ohne MFA-Abfrage, und stell sicher, dass die App Port 587 mit STARTTLS verwendet (Port 465 mit implizitem TLS ist nicht das, was Microsoft für diesen Endpunkt dokumentiert).
4. Änderungen wirken nicht sofort: Lass etwas Zeit verstreichen (oft bis zu einer Stunde), bevor du erneut testest.

Geräte, die kein OAuth können

Alte Drucker und Scanner unterstützen oft nur ein Passwort. Statt SMTP AUTH können sie über einen SMTP-Relay-Connector (von einer festen öffentlichen IP) oder per Direct Send an deinen MX-Endpunkt senden. Beide Optionen werden im Leitfaden zu 5.7.57 verglichen.

Prüfe, ob es behoben ist

• Sende aus der Anwendung eine E-Mail an die einmalige Adresse auf der Startseite von Delivmail. Kommt sie an, funktioniert der Login; der Bericht zeigt außerdem, ob SPF, DKIM und DMARC für deine Domain über Microsoft 365 bestehen. Ist das nicht der Fall, folge SPF, DKIM und DMARC für Microsoft 365.
• Sende dann eine echte E-Mail an den Empfänger, der sie hätte erhalten sollen.
• Plane den Umstieg auf OAuth jetzt, damit die Änderung bei der Standardauthentifizierung die App später nicht lahmlegt.