Geschätzte Lesezeit: 5 Minuten
Microsoft dreht bei Exchange Online weiter an der Sicherheitsschraube: Basic Authentication (Benutzername/Passwort) für den Client Submission / SMTP AUTH-Versand wird schrittweise ausgemustert. Viele Anwendungen, Scanner, ERP/CRM-Systeme oder Legacy-Skripte hängen jedoch noch an genau diesem Mechanismus – oft unbemerkt, bis plötzlich Mails nicht mehr rausgehen.
Wichtig: In vielen Hinweisen und Hersteller-Texten kursiert noch „Ende April 2026“ als Stichtag. Microsoft hat die Timeline aber aktualisiert. Laut aktuellem Exchange-Team-Update bleibt das Verhalten zunächst unverändert; Ende Dezember 2026 soll SMTP AUTH Basic Authentication dann standardmäßig deaktiviert werden (mit Admin-Option zur Reaktivierung, je nach Tenant-Situation). (TECHCOMMUNITY.MICROSOFT.COM)
Das ändert nichts an der Kernaussage: Wer heute noch SMTP AUTH mit Basic Auth nutzt, sollte umstellen – nicht „irgendwann“, sondern planbar und testbar, bevor es im Betrieb kracht.
Was ist betroffen – und warum trifft es so viele?
„SMTP“ ist nicht gleich „SMTP“:
- SMTP AUTH (Client Submission): Typischerweise Port 587, authentifiziert mit Benutzerkonto (früher oft Basic Auth). Das ist der Klassiker für Apps/Devices. Genau hier wird Basic Auth abgekündigt. (TECHCOMMUNITY.MICROSOFT.COM)
- SMTP Relay (Port 25, IP-gebunden): Kann je nach Setup weiter funktionieren, ist aber ein anderes Modell (Netzwerk-/IP-Vertrauen statt User-Login).
- Microsoft Graph API: Versand über HTTPS mit modernen Tokens (Entra ID). Das ist die strategisch empfohlene Richtung für Applikationen.
Der Haupttreiber ist klar: Passwortbasierte Protokoll-Logins sind ein Einfallstor (Credential Stuffing, Legacy Clients, fehlende MFA-Fähigkeit). Moderne Authentifizierung über Microsoft Entra ID (OAuth 2.0) ist deutlich besser kontrollierbar.
Die drei realistischen Migrationspfade
1) Microsoft Graph API (empfohlen für Anwendungen)
Wenn du die Kontrolle über die Anwendung hast (Code/Integration anpassbar), ist Graph meist die sauberste Lösung: Versand per API, Auth per OAuth, keine offenen SMTP-Ports nötig.
Technisch läuft’s auf sendMail hinaus. (Microsoft Learn)
Vorteile
- Moderne Authentifizierung (OAuth2) über Entra ID
- Versand über HTTPS (Firewall-freundlich)
- Gute Steuerbarkeit (App-Registrierung, Zertifikate/Secrets, Conditional Access)
Nachteile
- Code-/Integrationsanpassungen notwendig
- Governance wichtig: „Mail.Send“ ist mächtig (siehe Security-Abschnitt)
2) SMTP AUTH mit OAuth 2.0 (wenn SMTP bleiben muss)
Wenn ein Gerät oder ein Legacy-System zwingend SMTP spricht, ist „SMTP + OAuth2“ die Zwischenlösung. Microsoft dokumentiert explizit, wie IMAP/POP/SMTP mit OAuth authentifiziert werden. (Microsoft Learn)
Vorteile
- SMTP bleibt, Auth ist modern (Token statt Passwort)
- Häufig kompatibel mit Enterprise-Setups
Nachteile
- Manche Geräte/Software können OAuth2 für SMTP nicht (oder nur mit Updates/Workarounds)
- Rollout kann je nach Vendor zäh werden
3) High Volume Email (HVE) für spezielle Szenarien (z. B. Geräte, interne Massenmails)
Microsoft bietet mit High Volume Email (HVE) einen Dienst (Public Preview/regelmäßig Änderungen möglich), der für bestimmte Volumen-/Geräte-Szenarien interessant sein kann. Einschränkungen (u. a. Zielgruppen/Versandprofil) sind zu beachten. (Microsoft Learn)
Merke: HVE ist kein „Graph-Ersatz“, sondern eher eine Option für konkrete Spezialfälle (z. B. Applikationen/Scanner), wenn Graph nicht passt.
Praxis: So gehst du sauber vor (Migrations-Checkliste)
Schritt 1: Bestand aufnehmen (ohne Ratespiel)
- Wo wird Mailversand genutzt? (Apps, Cronjobs, ERP, Websites, Ticketsysteme, Scanner/MFP, Monitoring)
- Welche Versandwege? (SMTP AUTH Port 587, Relay Port 25, Drittanbieter-SMTP)
- Welche Absenderadressen? (Shared Mailbox, User-Mailbox, Funktionspostfach)
Tipp: Häufig findet man alte SMTP-Credentials in:
- CMS-Configs (WordPress/Joomla/Shopware)
- CI/CD-Variablen
- Windows Task Scheduler / Linux Cron
- AppSettings / Secrets Stores
Schritt 2: Zielbild wählen (Graph vs. SMTP OAuth)
Eine simple Entscheidungslogik:
- Du kannst Code ändern? → Graph API
- Du kannst Code nicht ändern, aber System kann OAuth2 für SMTP? → SMTP OAuth
- Gerät/Legacy kann weder Graph noch OAuth2-SMTP sinnvoll? → Relay/HVE prüfen (je nach Rahmenbedingungen)
Schritt 3: Entra ID App-Registrierung sauber aufsetzen (für Graph)
Für Graph brauchst du in der Regel:
- App Registration in Entra ID
- Authentifizierung (Zertifikat empfohlen, Secret nur wenn nötig)
- API Permissions
Für sendMail ist die Berechtigung zentral: Mail.Send. (Microsoft Learn)
Security-Hinweis: Mail.Send ist nicht „nur ein Häkchen“
Gerade bei serverseitigem Versand greifen Teams oft zu Application Permissions (App sendet ohne angemeldeten Benutzer). Das ist bequem, aber: „Mail.Send (Application)“ kann je nach Konfiguration E-Mails als beliebiger Benutzer versenden – das ist ein massiver Hebel bei Missbrauch. (Office 365 for IT Pros)
Best Practices
- Wenn möglich: Delegated Permissions mit Service-User und klarer Policy
- Wenn Application Permissions nötig:
- Zertifikatsbasierte Auth bevorzugen
- Zugriff und Absender strikt begrenzen (Governance/RBAC, getrennte App je Use Case)
- Monitoring/Alerting auf ungewöhnliche Versandmuster
Mini-Migrationsplan für den Betrieb (ohne Downtime)
- Parallelbetrieb aufbauen: Graph-Versand implementieren, SMTP noch nicht abschalten
- Testfälle definieren: interne/externe Empfänger, Anhänge, HTML, Reply-To, BCC, große Mails
- Pilot: einzelne Systeme umstellen, Logs prüfen
- Rollout: Rest umstellen, Credentials entfernen
- Härtung: Secrets rotierten, Conditional Access prüfen, Dokumentation finalisieren
Fazit
Der Umstieg ist kein „nice to have“, sondern ein planbarer Pflichttermin. Auch wenn Microsoft die Deadline rund um SMTP AUTH Basic Authentication zuletzt angepasst hat, ist die Richtung eindeutig: Passwortbasierter SMTP-Login hat in modernen Tenant-Sicherheitsmodellen keine Zukunft. (TECHCOMMUNITY.MICROSOFT.COM)
Wer heute strukturiert auf Microsoft Graph API oder zumindest SMTP OAuth2 migriert, gewinnt nicht nur Sicherheit, sondern auch Kontrolle: sauberer Identitätslayer (Entra ID), bessere Nachvollziehbarkeit und weniger „versteckte“ SMTP-Passwörter in Konfigurationsdateien.
- PHP (z. B. Joomla/WordPress) → Graph Versand
- .NET/PowerShell Job → Graph Versand
- Legacy-App/Scanner → SMTP OAuth2 oder HVE/Relay-Entscheidungspfad

Sei der Erste, der das kommentiert
Kommentare sind geschlossen, allerdings sind Trackbacks und Pingbacks möglich.