Exchange Online: Basisauthentifizierung für Client-Übermittlung (SMTP AUTH) endet Sept. 2025

Exchange Logo[English]Ich nehme mal ein Thema in den Blog auf, welches bereits im April 2024 durch Microsoft kund getan wurde, aber noch nicht allzu viel Aufmerksamkeit erfahren hat. Ein Leser hatte mich bereits vor einiger Zeit auf das Thema hingewiesen. Microsoft wird in  Exchange Online die Unterstützung für die Basisauthentifizierung mit Client Submission (SMTP AUTH) im September 2025 endgültig einstellen. Wer dieses Feature verwendet, hat also noch ein Jahr Zeit, zu reagieren.


Anzeige

Blog-Leser Florian R. hatte mich bereits Mitte April 2024 in einer E-Mail mit dem Betreff "smtp auth / office 365" kontaktiert und angemerkt "mich wundert dass es hier von keinen Artikel gibt". Gleichzeitig schickte er mir einen Link auf den Techcommunity-Beitrag Exchange Online to retire Basic auth for Client Submission (SMTP AUTH) vom 15. April 2024, in dem Microsoft das Ende der Basisauthentifizierung für Client-Übermittlung (SMTP AUTH) ankündigt.

Ende der Unterstützung im Sept. 2025

Microsoft wird in Exchange Online die Unterstützung für die Basisauthentifizierung mit Clientübermittlung (SMTP AUTH) im September 2025 dauerhaft entfernen. Nach diesem Zeitpunkt werden Anwendungen und Geräte nicht mehr in der Lage sein, Basic Auth als Authentifizierungsmethode zu verwenden. Die Anwendungen und Geräte müssen spätestens ab diesem Zeitpunkt OAuth verwenden, wenn sie SMTP AUTH zum Senden von E-Mails benutzen.

Microsoft schreibt, dass man bereits im Jahr 2019 mit einem mehrjährigen Prozess zur Deaktivierung von Basic Auth in Exchange Online begonnen habe. Dieser Prozess wurde Ende 2022 abgeschlossen, wobei Client Submission (SMTP AUTH) die einzige Ausnahme darstellt. Microsoft wird jetzt Basic Auth aus Client Submission entfernen.

Der Hintergrund für diesen Schritt: Basic Auth ist eine veraltete Authentifizierungsmethode, die Benutzernamen und Kennwörter im Klartext über das Netzwerk sendet. Dies macht sie anfällig für den Diebstahl von Zugangsdaten, Phishing und Brute-Force-Angriffe. Um den Schutz unserer Kunden und ihrer Daten zu verbessern, werden wir Basic auth von Client Submission (SMTP AUTH) abschaffen und unsere Kunden dazu ermutigen, moderne und sicherere Authentifizierungsmethoden zu verwenden.


Anzeige

Fahrplan zur Umstellung

Microsoft bereitet die Abschaltung in mehreren Schritten vor, so dass Administratoren auf diese Änderung reagieren können. Hier der Fahrplan zur Umstellung.

  • Im September 2024 wird der SMTP AUTH-Bericht zur Clientübermittlung im Exchange-Administrationszentrum aktualisiert. Dann wird angezeigt, ob Basic Auth oder OAuth zur Übermittlung von E-Mails an Exchange Online verwendet wird.
  • Im Januar 2025 will Microsoft einen Message Center-Post an Tenants senden, die Basic Auth mit Client Submission (SMTP AUTH) verwenden. Im Post wird auf die bevorstehende Änderung hingewiesen.
  • Im August 2025, etwa 30 Tage vor der Deaktivierung der Basisauthentifizierung, wird Microsoft einen weiteren Message Center-Post an Tentants senden, die noch die Basisauthentifizierung mit Clientübermittlung (SMTP AUTH) verwenden.

Im September 2025 endet dann die Unterstützung für Basic Auth mit den Client Submission (SMTP AUTH)-Endpunkten:

  • smtp.office365.com
  • smtp-legacy.office365.com

Sobald Basic auth dauerhaft deaktiviert ist, erhalten alle Clients oder Anwendungen, die eine Verbindung über Basic auth mit Client Submission (SMTP AUTH) herstellen, diese Antwort:

550 5.7.30 Basic authentication is not supported for Client Submission.

Microsoft gibt im Support-Dokument den Hinweis auf das Dokument Authenticate an IMAP, POP or SMTP connection using OAuth, um Clients, die OAuth unterstützen, umzustellen. Kunden, die weiterhin Basic Auth mit Client Submission (SMTP AUTH) verwenden müssen, finden im Beitrag Exchange Online to retire Basic auth for Client Submission (SMTP AUTH) Hinweise auf Alternativen. Das Support-Dokument enthält weitere Details, u.a. für Kunden, die ein hohe E-Mail-Aufkommen haben.


Anzeige

Dieser Beitrag wurde unter Cloud, Mail, Sicherheit abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

26 Antworten zu Exchange Online: Basisauthentifizierung für Client-Übermittlung (SMTP AUTH) endet Sept. 2025

  1. Luzifer sagt:

    Naja April 2024 kommuniziert, Spetember 2025 endgültig umgesetzt, wer das nicht gebacken kriegt…sollte für solche Systeme nicht verantwortlich sein!

    • J. sagt:

      Da muss ich dir zumindest teilweise widersprechen. Das ist kein Problem der Admins, sondern der verwendeten Branchensoftware und der dortigen Entwickler und Verantwortlichen. Unsere Branchensoftware kann gegenwärtig m. W. auch kein OAuth – und da die seitens des Herstellers bereits abgekündigt ist (allerdings eigentlich mit einer längeren Frist als 2025), wird sich das vermutlich auch nicht mehr ändern. Wechsel auf die Nachfolgelösung ist für Anfang bis Mitte 2025 geplant – aber wie das bei solchen Projekten üblich ist, ist das halt der Bestcase, wenn alles nach Plan läuft. Kann klappe, aber wenn nicht bleibt da nicht mehr so ganz viel Puffer.

  2. Stefan (AT) sagt:

    „Toll". Na, HVE scheint das zu sein was wir brauchen. Ist schon bekannt ob das nach der Preview was kosten wird oder wird es wie die shared-Mailboxen einfach ohne Lizenz genutzt?

    • MaxM sagt:

      @Stefan (AT): HVE wird nach dem Preview kostenpflichtig sein:
      "HVE uses a transactional model based on the number of emails sent. For the public preview, the cost will be free but limited to 100,000 recipients per day per tenant."

  3. MaxM sagt:

    Als Alternativen werden im MS-Artikel aufgezählt:
    1) HVE (kostenpflichtig und limitiert für externe Emails)
    2) ACS (kostenpflichtig)
    3) "If you have an Exchange Server on-premises in a hybrid configuration, you can use Basic auth to authenticate with the Exchange Server on-premises or configure the Exchange Server on-premises with a Receive connector that Allow anonymous relay on Exchange servers".

    IMHO hat MS vergessen, dass es noch die Option 3 gibt:
    https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365#option-3-configure-a-connector-to-send-emails-using-microsoft-365-or-office-365-smtp-relay

    Damit kann ein beliebiger SMTP-Relay-Host (hMailServer, Postfix, Windows server SMTP daemon …) über einen Inbound Organization Connector Emails für interne UND externe Empfänger an ExchangeOnline einliefern.

    • Stefan (AT) sagt:

      Wohl dem der eine statische IP hat und nocht hinter CGnat sitzt, leider gerade bei kleinen Kunden keine Seltenheit. Bin mal auf die Preise gespannt. Für Scans wird es halt sonst smb-scan-to-folder.

    • 8ball sagt:

      Wird die Option 3 bleiben?

      Ich habe einen Kunden der eine ERP Software nutzt, wo man keine TLS Verschlüsselung aktivieren kann.

      Da wird der Exchange Online Connector genutzt und verschickt über Port25 und nutzt als smtp server **mail.protection.outlook.com

      • MaxM sagt:

        @8ball: Da man bei einem ExO INBOUND connector gar nicht angibt, ob TLS verwendet wird oder nicht – das macht ja der sendende Host – glaube ich, dass man auch weiterhin ohne TLS Emails an seinen ExO-Tenant übergeben kann.

  4. Haarlos sagt:

    Ich behaupte mal, dass viele dies nun umstellen müssen. Auch ich muss an zwei Stellen daran arbeiten (zumindest ein wenig was).
    Das WordPress-Plugin WP Mail SMTP unterstützt dies nur in der Pro-Variante, da die kostenfreie Version nur SMTP per Kennwort und Mail anbietet.
    Typo3, welches m. E. viel zu umständlich ist, braucht hierfür auch wieder eine Extension…
    Ein paar weitere Systeme, fernab von Webservern, kommen sicherlich auch dazu.

    Etwas Arbeit kommt da auf, wenn auch nicht besonders viel.

    Oder werfe ich hier was gewaltig durcheinander?

  5. Stefan (AT) sagt:

    Gibt es eigentlich freie Mailserver die man als Relay einsetzen kann welche oauth2 unterstützen? Hmailserver kanns mal nicht, der abgekündigte SMTP-Server in Windows Server 2019/2022 auch nicht 🤔

    • MaxM sagt:

      @Stefan (AT): Warum muss der Relay-Mailserver OAUTH können? Dieser Server relayed über Port 25 mit einer statischen public IP und/oder einem Zertifikat an ExchangeOnline (via Connector). Die einlieferenden Hosts können mit Benutzer/Kennwort oder anonym beim Relay-Mailserver ihre Emails abgeben. Wozu also OAUTH?

      • Stefan (AT) sagt:

        Ohne statische IP geht der Connector ja nicht und so hätte man ein Relay das intern einfaches Relay ohne Verschlüsselung und auth macht )für alte MFP) und nach extern outh2 nutzt. Warum gibts sowas nicht? SynologY verschickt seine Statusmails per oauth2, Veeam zb auch.

    • DW sagt:

      Ich denke Postfix + XOAUTH2 sollte das möglich sein. Hab es praktisch aber bisher noch nicht eingerichtet.

  6. Anonymous sagt:

    Soweit ich das verstanden habe, geht es um OAuth2. Und damit bekommen wir dann zusätzlich Spass, da die Konzerne ihre OAuth2-Implementationen gerne 'optimieren', d.h. vom RFC abweichen. Klassische Verschlimmbesserung! :(

  7. yoyobo sagt:

    Ich regle das bei mir gerne so, dass ich entweder auf der primären Domain im Webhosting des Kunden Postfächer anlege und dann den SPF entsprechend ergänze (insgesamt nicht so super wegen DKIM und so, geht aber auch) oder dass ich eine Subdomain fürs Mailing via SMTP nutze. Also bspw. scanner@devices.kunde.tld . Die ist dann komplett unabhängig vom M365 und für Benachrichtigungen, Mails vom Scanner etc. reicht das voll aus. Für Mails von einer Warenwirtschaft ist das in der Regel natürlich nicht so passend.

    • Martin S. sagt:

      Mach ich auch so.

    • MaxM sagt:

      @yoyobo: Wenn die Domain @devices.kunde.tld von M365 unabhängig ist, wie sendet dann der Scanner seine Emails? Schlägt er den MX record des externen Empfänger nach und versendet dann direkt mit einer statischen public IP an den Email-Host des externen Empfängers?

      • yoyobo sagt:

        @MaxM:
        Ich nutze einfach den Mailing-Dienst des Webhosters. Meistens bezahlt man den sowieso. Die Mails gehen dann einen längeren Weg, aber es funktioniert in der Regel problemlos.

  8. Jan sagt:

    Dass man derzeit komplett unverschlüsselte Sendeconnectoren/Smarthosts benutzen kann, bleibt dagegen?

    • MaxM sagt:

      @Jan:
      Du spielst darauf an, dass man bei einem Sende-Connector die Security Restrictions "Always use TLS to secure the connection (recommended)" bis heute abwählen kann?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.