Ende von Basic Auth SMTP bei Microsoft Exchange Online: Zeitplan, Fehler 550 5.7.30 und Migrationsanleitung

Seit 2019 entfernt Microsoft schrittweise die Basic-Authentifizierung (Benutzername + Passwort) aus seinen Exchange-Online-Protokollen. EAS, POP, IMAP, EWS, PowerShell: Alle wurden Ende 2022 auf Modern Auth migriert. Die letzte Bastion war SMTP AUTH Client Submission, das Protokoll, das von Multifunktionsdruckern, Versandskripten und Geschäftsanwendungen zum Senden von E-Mails über smtp.office365.com auf Port 587 verwendet wird.

Im April 2024 kündigte Microsoft das Ende dieser letzten Bastion an. Nach mehreren Verschiebungen (September 2025, dann März 2026) gewährt der überarbeitete Zeitplan vom Januar 2026 eine zusätzliche Frist, aber die Botschaft bleibt klar: Basic Auth SMTP wird abgeschaltet, und jede Organisation muss ihre Migration planen.

Dieser Artikel beschreibt den genauen Zeitplan, die betroffenen Systeme, die fünf verfügbaren Alternativen und eine konkrete Migrations-Checkliste.

Was ist Basic Auth SMTP und warum ist es ein Problem?

Die Basic-Authentifizierung für SMTP funktioniert einfach: Der Client codiert Benutzername und Passwort in Base64 und übermittelt sie dem Server im Befehl AUTH LOGIN oder AUTH PLAIN. Auch wenn die Verbindung per TLS (STARTTLS auf Port 587) verschlüsselt ist, sind die Credentials wiederverwendbar, ohne Ablaufdatum und ohne zweiten Faktor.

C: AUTH LOGIN
S: 334 VXNlcm5hbWU6
C: dXNlckBjYXB0YWluZG5zLmNvbQ==
S: 334 UGFzc3dvcmQ6
C: bW90ZGVwYXNzZQ==
S: 235 2.7.0 Authentication successful

Dieser Mechanismus birgt drei wesentliche Risiken:

OAuth 2.0 löst alle drei Probleme: Tokens sind temporär (standardmäßig 60 Minuten), widerrufbar, an einen bestimmten Scope (SMTP.Send) gebunden und kompatibel mit MFA und Conditional Access.

SMTP AUTH Client Submission vs SMTP Relay

Es ist wichtig, zwei Versandmechanismen über Exchange Online zu unterscheiden:

Die Abschaltung von Basic Auth betrifft ausschließlich Client Submission. SMTP-Relays basierend auf IP-Adressen (Option 2 der Microsoft-Dokumentation) sind nicht betroffen.

Vollständiger Zeitplan der Abschaltung

Der Zeitplan wurde mehrfach überarbeitet. Hier die konsolidierte Timeline vom 19. Februar 2026:

Der Fehler 550 5.7.30

Nach der Deaktivierung erhält jeder Client, der eine Basic-Authentifizierung versucht:

550 5.7.30 Basic authentication is not supported for Client Submission.

Dieser Fehler ist eine permanente Ablehnung (Code 5xx). Der sendende Server wird keinen erneuten Zustellversuch unternehmen. Die E-Mails werden nicht in eine Warteschlange gestellt: Sie gehen sofort verloren.

Wer ist betroffen?

Jede Anwendung oder jedes Gerät, das E-Mails über smtp.office365.com oder smtp-legacy.office365.com mit Benutzername und Passwort versendet, ist betroffen.

Typischerweise betroffene Systeme

Wie identifizierst du Absender mit Basic Auth?

Microsoft hat den SMTP-AUTH-Bericht im Exchange Admin Center (EAC) im Oktober 2024 aktualisiert, um Basic-Auth-Verbindungen von OAuth-Verbindungen zu unterscheiden.

1. Melde dich bei admin.exchange.microsoft.com an
2. Navigiere zu Berichte > Nachrichtenfluss > SMTP-Auth-Clientbericht
3. Filtere nach Authentifizierungstyp, um die Absender mit Basic Auth zu isolieren

Jede Zeile zeigt die Absenderadresse, die Anzahl der Nachrichten und den verwendeten Authentifizierungstyp.

Alternative 1: OAuth 2.0 für SMTP AUTH

Dies ist die von Microsoft empfohlene Lösung für Clients und Anwendungen, die OAuth-Tokens verarbeiten können.

Voraussetzungen

1. Eine Anwendung registrieren in Microsoft Entra (Azure AD)
2. Die Berechtigung SMTP.Send (interaktiver Flow) oder SMTP.SendAsApp (Application Flow) hinzufügen
3. Admin-Consent des Tenants einholen

Zwei mögliche Flows

SMTP-Sitzung mit OAuth

Der Client verwendet den SASL-Mechanismus XOAUTH2:

C: AUTH XOAUTH2 dXNlcj1hbGVydHNAY2FwdGFpbmRucy5jb20BYXV0aD1CZWFyZXIgZXl
KMGVYQUlPaUpLVjFRaUxDSmhiR2NpT2lKU1V6STFOaUo5Li4uAQE=
S: 235 2.7.0 Authentication successful

Der Base64-Token codiert user=alerts@captaindns.com gefolgt vom Bearer Token OAuth. Der Token läuft nach 60 Minuten ab; der Client muss die Erneuerung über den Refresh Token verwalten.

Einschränkungen

• Multifunktionsdrucker und IoT-Geräte unterstützen OAuth in der Regel nicht
• Erfordert eine App-Registrierung in Entra ID
• Der Client-Credentials-Flow erfordert die Registrierung eines Service Principals in Exchange Online per PowerShell

Alternative 2: High Volume Email (HVE)

Der HVE-Dienst ist für den internen Massenversand von Anwendungen und Geräten konzipiert.

Wann HVE verwenden?

HVE eignet sich, wenn:

• Das Gerät OAuth nicht unterstützt (MFP, IoT)
• Die E-Mails ausschließlich intern sind (Alarme, Benachrichtigungen, Scan-to-Email an Postfächer des Tenants)
• Das Volumen hoch ist (kein Rate-Limit für Empfänger)

HVE-Konto erstellen

Über das EAC: Nachrichtenfluss > High Volume Email (Preview) > HVE-Konto hinzufügen.

Oder per PowerShell:

New-MailUser -HVEAccount -Name "Scanner Alerts" -PrimarySmtpAddress "scanner-alerts@captaindns.com"

Achtung: HVE befindet sich in der Public Preview. Microsoft behält sich das Recht vor, den Dienst auszusetzen. Weise HVE-Konten keine Lizenz zu.

Alternative 3: Azure Communication Services Email

Azure Communication Services (ACS) Email ermöglicht den internen und externen Versand über eine REST-API oder SDKs (.NET, Python, JavaScript, Java).

ACS ist relevant für Cloud-native Anwendungen, die ein SDK integrieren können. Für physische Geräte (Drucker, Scanner), die nur SMTP sprechen, ist es nicht geeignet.

Alternative 4: On-Premises SMTP-Relay

Für Organisationen mit hybrider Konfiguration (Exchange Online + Exchange Server On-Premises) bleibt das lokale SMTP-Relay eine Option.

Funktionsweise

1. Die Geräte (MFP, IoT, Skripte) senden an den lokalen Exchange Server über Port 25 (Anonymous Relay)
2. Der Receive Connector ist so konfiguriert, dass er Verbindungen aus einem internen IP-Netzwerk akzeptiert
3. Der lokale Exchange Server leitet über den Send Connector an Exchange Online weiter

Konfiguration des Receive Connectors

New-ReceiveConnector -Name "Anonymous Relay" `
  -TransportRole FrontendTransport `
  -Usage Custom `
  -Bindings 0.0.0.0:25 `
  -RemoteIPRanges 192.168.1.0/24 `
  -PermissionGroups AnonymousUsers

Vor- und Nachteile

Alternative 5: Microsoft Graph API

Für Skripte und Anwendungen bietet die Graph API den Endpoint /users/{id}/sendMail, der SMTP vorteilhaft ersetzt.

curl -X POST "https://graph.microsoft.com/v1.0/users/alerts@captaindns.com/sendMail" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "message": {
      "subject": "Alerte monitoring",
      "body": {"contentType": "Text", "content": "Le serveur DNS est indisponible."},
      "toRecipients": [{"emailAddress": {"address": "ops@captaindns.com"}}]
    }
  }'

Graph API ist ideal als Ersatz für PowerShell-Skripte (Send-MailMessage ist deprecated) und Serveranwendungen. Für Hardware-Geräte, die nur SMTP ausführen können, ist es nicht geeignet.

Vergleichstabelle der Alternativen

Migrations-Checkliste

Auswirkungen auf Zustellbarkeit und Sicherheit

Die Abschaltung von Basic Auth hat keinen Einfluss auf SPF, DKIM oder DMARC. Diese E-Mail-Authentifizierungsprotokolle funktionieren auf DNS-Ebene und bleiben unabhängig von der SMTP-Authentifizierungsmethode.

Die Migration bietet jedoch eine Gelegenheit, deine Sicherheitslage zu stärken:

• MFA überall: OAuth ermöglicht es, Multi-Faktor-Authentifizierung für interaktive Sendekonten durchzusetzen
• Widerrufbare Tokens: Im Gegensatz zu einem kompromittierten Passwort, das bis zur Änderung gültig bleibt, läuft ein OAuth-Token automatisch ab
• Conditional Access: Du kannst den SMTP-Versand auf bestimmte IP-Bereiche, konforme Geräte oder bestimmte Zeiten beschränken
• Granulare Überwachung: OAuth-Verbindungen sind in den Entra-ID-Logs nachvollziehbar, mit Details zur Anwendung und zum verwendeten Scope

Diese Maßnahme von Microsoft fügt sich in einen breiteren Trend ein. Google und Yahoo haben bereits 2024 verschärfte Authentifizierungsanforderungen für Massenversender eingeführt. Die Absicherung des SMTP-Versandkanals ist die logische Fortsetzung.

Glossar

• Basic Auth: Authentifizierungsmethode, die Benutzername und Passwort Base64-codiert überträgt. Kein inhärenter Schutz gegen Replay-Angriffe.
• OAuth 2.0: Autorisierungsprotokoll auf Basis temporärer Tokens. Unterstützt MFA und Conditional Access.
• SASL XOAUTH2: SASL-Mechanismus zur Übertragung eines OAuth-2.0-Tokens in einer SMTP-, IMAP- oder POP-Sitzung.
• Client Submission: Authentifizierte SMTP-Versandmethode über smtp.office365.com (Port 587). Der Absender authentifiziert sich mit Credentials.
• SMTP Relay: SMTP-Versandmethode basierend auf der Quell-IP-Adresse, ohne Credentials. Nutzt einen eingehenden Exchange-Online-Connector.
• HVE (High Volume Email): Microsoft-365-Dienst für internen Massenversand über smtp-hve.office365.com. Public Preview.
• Microsoft Entra: Neuer Name von Azure Active Directory. Verwaltet App-Registrierungen, Berechtigungen und OAuth-Tokens.
• Service Principal: Anwendungsidentität in Exchange Online, erforderlich für den Client-Credentials-OAuth-Flow.
• MFA: Multi-Faktor-Authentifizierung. Mit Basic Auth unmöglich, mit OAuth 2.0 nativ unterstützt.

Quellen

• Exchange Online to retire Basic auth for Client Submission (SMTP AUTH) - Exchange Team Blog, April 2024
• Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline - Exchange Team Blog, Januar 2026
• Deprecation of Basic authentication in Exchange Online - Microsoft Learn
• Authenticate an IMAP, POP or SMTP connection using OAuth - Microsoft Learn
• Manage High Volume Email for Microsoft 365 - Microsoft Learn