Eigentlich wollte Microsoft in Exchange Online die Unterstützung für die Basisauthentifizierung mit Client-Übermittlung (SMTP AUTH) bereits im September 2025 einstellen. Dann hieß es, dass die Einstellung zwischen 1. März 2026 bis zum 30. April 2026 schrittweise einstellen. Dieses Datum ist nun nach Kunden-Feedback erneut kassiert worden. Bis Dezember 2026 bleibt alles beim Alten.
Ursprünglicher Zeitplan zur Abschaltung
Ich hatte im Juli 2024 erstmals im Blog-Beitrag Exchange Online: Basisauthentifizierung für Client-Übermittlung (SMTP AUTH) endet Sept. 2025 über Microsofts Pläne zur Abschaltung der Basisauthentifizierung mit Client-Übermittlung (SMTP AUTH) berichtet.
Hintergrund ist, dass es sich bei Basic Auth um eine veraltete Authentifizierungsmethode handelt, die Benutzernamen und Kennwörter im Klartext (allerdings i.d.R. über TLS verschlüsselt) über das Netzwerk sendet. Dies macht diese Methode laut Microsoft anfällig für den Diebstahl von Zugangsdaten, Phishing und Brute-Force-Angriffe.
1. Plan zur Abschaltung Sept. 2025
Microsoft hat nach eigenen Angaben bereits im Jahr 2019 mit einem mehrjährigen Prozess zur Deaktivierung von Basic Auth in Exchange Online begonnen. Dieser Prozess wurde Ende 2022 abgeschlossen, wobei Client Submission (SMTP AUTH) die einzige Ausnahme darstellt.
Im Juli 2024 teilte Microsoft dann mit, auch Basic Auth aus der Client Client-Übermittlung (SMTP AUTH) zu entfernen. Nach September 2025 sollten Anwendungen und Geräte nicht mehr in der Lage sein, Basic Auth als Authentifizierungsmethode zu verwenden. Die Anwendungen und Geräte sollten spätestens ab diesem Zeitpunkt OAuth verwenden, wenn sie SMTP AUTH zum Senden von E-Mails benutzen.
2. Plan zur Abschaltung auf März 2026 verschoben
Im Artikel Exchange Online to retire Basic auth for Client Submission (SMTP AUTH) hieß es später, dass man in Exchange Online die Unterstützung für die Basisauthentifizierung mit Client-Übermittlung (SMTP AUTH) schrittweise einstellen werde. Beginnend mit einem geringen Prozentsatz an abgelehnten Übermittlungen für alle Tenants sollte die Abschaltung am 1. März 2026 beginnen und am 30. April 2026 mit 100 % abgelehnten Übermittlungen enden. Im Artikel findet sich aber eine gelb hinterlegte Meldung:
Update 1/27/2026: We have revised the timeline for this deprecation. Please see our new post Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline to read more.
Neue Termine zur SMTP AUTH-Abschaltung
Nun hat Microsoft die obigen Termine nach Feedback seiner Kunden erneut über den Haufen geworfen. Ich bin über nachfolgenden Post auf diese Terminverschiebung gestoßen, die Microsoft im Techcommunity-Beitrag Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline zum 27. Januar 2026 bekannt gegeben hat.
Das Microsoft 365-Team schreibt dort, dass viele Kunden weiterhin mit echten Herausforderungen bei der Modernisierung älterer E-Mail-Workflows konfrontiert seien. Diese Kunden benötigen ausreichend Zeit, um praktikable, sichere Alternativen einzuführen.Daher passt Microsoft erneut den Zeitplan für die Abschaffung der SMTP-AUTH-Basisauthentifizierung in Exchange Online an.
- Bis Dezember 2026: Das Verhalten der SMTP-AUTH-Basisauthentifizierung bleibt unverändert.
- Ende Dezember 2026: Die SMTP-AUTH-Basisauthentifizierung wird für bestehende Mandanten standardmäßig deaktiviert. Administratoren können sie bei Bedarf weiterhin aktivieren.
- Für neue Exchange Online Tenants, die nach Dezember 2026 erstellt werden, wird OAuth die unterstützte Authentifizierungsmethode und die SMTP-AUTH-Basisauthentifizierung standardmäßig nicht mehr verfügbar sein.
Microsoft will dann in der zweiten Hälfte des Jahres 2027 das endgültige Datum für die Entfernung der SMTP-AUTH-Basisauthentifizierung bekannt geben. Frage an die Leserschaft: Ist das überhaupt noch ein Thema, oder seid ihr längst auf OAuth gewechselt?
MVP: 2013 – 2016
Da sitzen die auf einem Berg von Telemetrie-Daten und haben so tolle KI und wissen offenbar immer noch nicht, was Ihre Kundschaft (nicht) will. Das bedeutet drei Dinge:
1. Entweder ist das ganze Telemetrie-Gaggelfax komplett sinnfrei
2. oder deren Auswertungen und KI Ergebnisse
3. oder das Management schlicht inkompetent und agiert jenseits der Realitäten
Unsinn, die sehen das es noch weit verbreitet eingesetzt wird.
Falsch!
4. Microsoft ist es sch…egal, was die Kundschaft will.
Die drücken ihren Kram überall rein, ohne Rücksicht, ob die Kundschaft das will oder nicht.
Beispielsweise Copilot, Recall, immer neue Bloatware in Windows 11, etc. etc.
Und die Oberen von Microsoft reagieren mit Unverständnis oder sind sogar sauer, wenn man deren aufgedrängten Kram nicht will und nicht nutzt.
Sie wissen schon, daß es eingesetzt wird, verstehen aber nicht wirklich, warum es die Kunden tun.
SMTP ist eines der ältesten Protokolle des Internet – auf alle Fälle älter als HTTP.
Mails automatisiert zu versenden ist eine der verbreitetsten und am einfachsten zu realisierenden Funktionen vernetzter Geräte.
Erschwerend kommt hinzu, daß die meisten Geräte diese Mails nicht regelmäßig, sondern nur unter bestimmten Bedingungen versenden. Eine USV meldet sich beispielsweise nur, wenn der Akku gealtert ist – und natürlich bei Stromausfall. Ein RAID-Controller nur, wenn eine Platte defekt ist. Es reicht also nicht, den Mailverkehr der letzten Tage zu prüfen um alle potentiellen Sender zu identifizieren.
Viele Geräte haben auch ihre wirtschaftliche Lebensdauer noch nicht erreicht, obwohl der Herstellersupport weitgehend eingestellt wurde. Bei uns etwa die Telefonanlage, die Brandmeldeanlage und die Alarmanlage. Wird im Prinzip noch gewartet, aber es macht sich keiner mehr die Mühe, am Kern der SMTP-Funktionalität zu rühren.
Oder die allseits beliebten Abteilungsdrucker mit Scan-Funktion, die die Dokumente per Mail verschicken.
Microsoft hat hier wie an vielen anderen Stellen (TCP/IP, HTTP) auch ein Standardprotokoll übernommen, gekapert und durch eigene Erweiterungen verschlimmbessert. Es ist ja schön und richtig, daß ein Büro-PC Mails per modern Authentication verschickt, das kann man gleich mit Teams und Sharepoint vereinheitlichen.
Nur gerät aus dem Fokus, daß eben nicht nur PCs Mails verschicken. Gerade automatisierte Workflows (wie die kürzlich thematisierte E-Rechnung, aber z.B. auch Dokumentenmanagement- und ERP-Systeme) tun das, oft weit abseits von Microsoft-Lösungen z.B. in Java implementiert.
Für uns bestand der primäre Fluchtweg darin, Mails nicht direkt an Microsoft zu schicken, sondern über einen zwischengeschalteten Mailserver. Firewalls bieten oft die Möglichkeit, als SMTP-Relay zu funktionieren und haben oft noch erweiterte Filterfunktionen. Auf alle Fälle werden sie noch lange SMTP AUTH bieten.
Selbst haben wir diese Firewall bei Microsoft als "Connector" mit zertifikatsbasierter Authentifizierung definiert, so daß die Mails, welche letztendlich wirklich den Microsoft-Kosmos erreichen müssen, auch an die Microsoft-Server zugestellt werden können.
SMTP gab es schon vor dem Internet .
Die SMTP Auth Methoden sind halt großteils veraltet. Weil sie nur den Client Authentifizieren aber nicht den Server.
Schon klar, aber bei SMTP über UUCP ergab sich die Authentifizierung über die zugrundeliegende Verbindung, z.B. per Telefon.
SMTP hatte ursprünglich gar keine Authentifizierung, weil jeder an eine erreichbare Adresse Mails sensen konnte (vergleichbar mit einem Briefkasten, in den auch jeder etwas einwerfen kann). Erst die großen SPAM-Wellen in Verbindung mit gefälschten Absendern machten eine Authentifizierung des Senders (Client) überhaupt notwendig.
Im Prinzip ist die Situation vergleichbar mit der Abschaltung älterer Mobilfunkstandards wie 2G/3G, auch hier werden Anlagen mit eigentlich langer Lebensdauer (ich hatte oben für uns schon Telefonanlage, Brandmeldeanlage und Alarmanlage genannt, bei Autos mit e-Call ist die Situation vermutlich bald ähnlich) vorzeitig zu Elektronikschrott.
Exchange Online erzwingt TLS für SMTP AUTH-Verbindungen. Damit werden Anmeldedaten nicht im Klartext übertragen. Es gibt andere Gründe, warum das Verfahren unsicher ist.
Du hast Recht mit dem Einwand, der übertragene Datensatz ist TLS-verschlüsselt – ich habe es im Text angepasst.
Gibt ja leider noch Software welche nicht mit OAuth arbeitet und M365 Mailkonten was ganz neues ist.
Hoffe das diese was ändern, sonst Brauch es ein Plan B damit diese weiterhin mails über SMTP versenden können.
Alternative, nen C-Panel Hosting, oder Mail Adresse hinterlegen als IMAP und so konfigurieren das dies neben der M365 Instant Mails versenden kann.
Alternativ: Connector für den Versand und die Einlieferung über eine statische IP-Adresse einrichten.
Ich habe das mal mit einem Inbound-Connector getestet und er wollte partout nicht nach extern senden, nur nach intern hat funktioniert. Mails nach extern wurden gar nicht erst von EXO angenommen, da sie im Message-Trace nicht zu finden waren.
Habe ich etwas übersehen oder geht es nach extern grundsätzlich nicht auf diese Art?
doch nach extern funktioniert, aber du musst einen Trust in O365 einrichten oder authentifizieren, eines von beidem.
Bei mir laufen HA Cluster aus postfix servern als internes SMTP relay, was dann die Mails nach O365 leitet, funktioniert sehr gut und man kann endlich onPrem den Exchange loswerden inkl. einen Haufen Lizenzen und Arbeitszeit sparen.
Wir haben als internes SMTP relay hMailServer (statt Exchange on-premises). Damit kann man auch aus dem Exchange-Online-Tenant nach extern versenden.
ja, nur ist hMailServer von der Entwicklung her schon seit Jahren tot und hinkt auch technologisch stark hinterher. Oder hat sich daran etwas geändert?
Ist halt dann nur eine Frage der Zeit bis es damit dann Mal Probleme gibt.
Bzgl. fehlender Weiterentwicklung hast Du absolut recht. Ist halt weit einfacher zu konfigurieren als Dein postfix.
Und im Moment tut es noch ;-)
hMailserver habe ich gemocht, aber er kommt in die Jahre. Bei uns ist es im Moment der in den Sophos Firewalls integrierte EXIM.
@Fritz: Wir lieben es noch ;-)
Dann war die statische IP Adresse nicht im Connector eingetragen von der man aus die Mails versenden will, solange diese nicht eingetragen ist, können Mails nur intern versendet werden.
Die statische public IP müsste korrekt gewesen sein. Habe es auf einem MFP getestet und die internen Empfänger wurden via EXO bedient. Diese konnte ich auch im Message-Trace sehen. Nur die externen sind dort nicht zu sehen.
Ich vermute wie ARC4 oben ausführt, braucht man eine Authentifizierung für externen Versand oder aber evtl. funken andere Connectoren (für den normalen Emailversand) dazwischen.
Danke euch für den Input.
Grundsätzlich geht es definitiv, machen wir auch.
Bei der Konfiguration muß man sich aber an die Anleitung von MS halten und die (durchaus vorhandenen) Fehlerprotokolle lesen. Eine statische externe IP isd von Vorteil, alternativ geht es auch zertifikatsbasiert. DNS-Einträge nicht vergessen.
Microsoft bietet lustiger Weise mit dem HVE ja eine Möglichkeit weiterhin SMTP einzusetzen. Kostet halt und nur intern.
Alternativ bietet sich ein oAuth Relay an: https://tech-support.koeln/de/blog/loesung-fuer-legacy-geraete-ohne-smtp-oauth-ab-september-2025
Ein wesentlicher Teil dürften Geräte wie ältere Multifunktionsgeräte sein, die nur SMTP AUTH, wohl mit STARTTLS, können, und die nicht mehr auf OAuth umgerüstet werden können, ohne sie zu ersetzen. Das dürfte Microsoft in der Telemetrie durchaus sehen, und hier muß man natürlich abwägen, ob es sinnvoll ist, diese Geräte vom Mailversand abzuklemmen.
solche Geräte sind Teils sowieso schon wegen uralter Ciphers raus.
Die können dann zwar TLS 1.2 aber nur mir Ciphers die idR nicht mehr unterstützt werden.
Da sind wir wieder bei den Abschreibungszeiträumen. 5-7 Jahre sind für so ein Gerät, das neu gerne mal 5-10k plus Support kostet, durchaus üblich. Alternativ Miete bzw. Leasing, das paßt aber auch nicht jedem ins Geschäftsmodell.
Wir nutzen für alte Drucker und Anwendungen ohne Graph-Schnittstelle SMTP2GO oder Resend.
HVE ist meines Erachtens nach der von Microsoft angedachte Weg, künftig "legacy SMTP" weiterzubehalten.
Ich habe bereits HVE bei Kunden getestet. Hier ein paar Erkenntnisse, die vielleicht dem einen oder anderen helfen:
– Es wird dafür ein normaler User in Entra erzeugt, der dann eine Basisauthentifizierung durchführt und den man daher auch in seiner Conditional Access Policy bedenken/excluden muss (bzw. Security Defaults funktionieren nicht!)
– Neuer SMTP Hostname: smtp-hve.office365.com
– Mailversand nach extern funktioniert nicht – nur zu Konten innerhalb der Organisation
– Bisher ist es (noch?) kostenlos, weil Preview
– Große Mails mit Attachments über 10 MB werden scheinbar nicht unterstützt, ich habe auch keinen Weg gefunden das Limit aufzuheben. Alle üblichen Exchange-Limits greifen hier nicht. Somit eignet es sich nicht gut als Ersatz für Scan2Mail auf Druckern.
– Die Alternative ohne die o.g. Beschränkungen sind die Azure Communication Services
Gute Infos zu HVE gibts hier: https://www.frankysweb.de/exchange-online-massenmails-mit-hve-high-volume-e-mail/
Scan2Mail finde ich nicht wirklich immer gut. Besser ist es, für jeden Benutzer eine eigene Anmeldung vorzusehen, und die Scans in einem Benutzerordner zu parken. Aber MFPs, die diese Art von Integration in ein Active Directory oder Entra ID oder anderes können, können dann wohl meist auch OAuth.
Scan to file ist auch nur eine mäßig gute Idee, weil die zugrundeliegenden Protokolle (wie etwa SMB) einem noch schnelleren Wandel unterliegen. Und Scan to FTP will vermutlich niemand mehr. Zudem entstehen dabei gerne auch immer weiter wachsende allwissende Datenmüllhalden (nicht wirklich ein Problem des Protokolls, aber es begünstigt entsprechende Faulheit der Benutzer).
Das geht ganz einfach wenn das Ziel pro User nur 100MB oder so groß ist ;)
"Pro User" ist schon mal ein guter Ansatz. Schlimmer sind die Geräte mit nur einem Knopf "Scannen!", die alles in ein Sammelverzeichnis werfen und jeder dann alle Scans sehen kann.
100MB ist sehr knapp für mehrseitige Dokumente, bei uns sind es 1G und ein Aufbewahrungszeitraum von 2 Stunden.
OAuth ist einfacher und sicherer. Alter Krempel ist nicht unbedingt zielführend…
@ Günther Born:
Bei uns ist das Exchange Online Portal (Nur das, Rest geht normal) extrem langsam. Sind nur wir betroffen oder betrifft das noch andere Tenants?
Unser ERP-System hat es inzwischen auch geschafft, OAuth (funktionsfähig) einzubauen. Der Rest läuft inzwischen (soweit erforderlich) als SMTP Auth über den NoSpamProxy als Relay.
An uns liegt die erneute Verschiebung also nicht ;)
Auf OAuth sind wir nicht gewechselt, da wir SMTP AUTH nur für Maschinenaccounts (Kennwort vergessen vom CMS, USV, etc.) nutzten. An Standorten mit hohem Mailaufkommen läuft jetzt ein SMTP Relay, das direkt zustellt. Ist natürlich Aufwand, was Reputation und Spam-Filter angeht und erfordert ne feste IP wo man Reverse DNS setzen kann. Den ganzen Rest haben wir auf Azure Communication Services umgestellt. Da zahlt man zwar für die einzelnen Nachrichten aber ist günstiger als die bislang genutzte Exchange Kiosk Lizenz wenn kaum Mails entstehen, und on prem fällt kein Adminaufwand an.
Finde es geil, wie Microsoft TLS abgesichertes SMTP als Sicherheitsrisiko ermittelt hat.
Aber die Tatsache, dass deren neue Outlook App fleißig POP/IMAP/SMTP Zugangsdaten ungefragt in der Cloud speichert, ist absolut Okay 🤣
Ich muss einfach noch mal fragen: Haben die sie nicht mehr alle oder sind wir es, die mittlerweile einfach kollektiv verblödet sind und das mit uns machen lassen?!?
Ja.