SMTP AUTH in Exchange Online: Ende Dezember aus, Endtermin 2027

/01Was Ende Dezember 2026 passiert — und was nicht

SMTP AUTH ist der Weg, auf dem Geräte und Programme sich bei Exchange Online anmelden, um Mails zu versenden: Server smtp.office365.com, Port 587, Benutzername und Kennwort eines Postfachs. Typische Nutzer sind Multifunktionsgeräte mit „Scan to Mail", Fachanwendungen, die Rechnungen oder Tickets mailen, Monitoring-Systeme und Skripte. Der Standard, mit dem sie sich anmelden, heißt Basic Authentication: Benutzername und Kennwort gehen bei jeder Verbindung mit, und das Gerät speichert sie.

Genau diese Anmeldeform ändert Microsoft. Der Exchange-Team-Blog hat dazu am 27. Januar 2026 einen aktualisierten Zeitplan veröffentlicht, der am 29. Januar nachgeführt wurde. Die Kernaussagen, wörtlich nah an der Quelle: Bis Dezember 2026 bleibt das Verhalten unverändert. Ende Dezember 2026 wird Basic Authentication für SMTP AUTH für bestehende Tenants standardmäßig ausgeschaltet („disabled by default"), und Administratoren können sie bei Bedarf weiterhin einschalten. Für Tenants, die nach Dezember 2026 entstehen, ist sie standardmäßig nicht verfügbar; als unterstützte Methode nennt der Beitrag dort OAuth. In der zweiten Jahreshälfte 2027 will Microsoft das endgültige Entfernungsdatum bekannt geben.

Was daraus nicht folgt, ist ebenso wichtig, weil die Meldung in der Praxis gern verkürzt wird. Ende Dezember ist kein harter Schnitt: Es ist ein geänderter Standard, den ein Administrator wieder umstellen kann. Es ist auch nicht das Ende von SMTP AUTH überhaupt, denn SMTP AUTH mit OAuth bleibt ausdrücklich unterstützt. Und es betrifft nicht jede Art, mit Exchange Online Mail zu versenden: SMTP-Relay über einen Connector, Direct Send und High Volume Email sind eigene Verfahren mit eigenen Regeln, sie stehen im Abschnitt /04 nebeneinander.

Zwei Randbedingungen aus der Microsoft-Dokumentation gehören dazu. Erstens: Für Organisationen, die nach Januar 2020 angelegt wurden, ist SMTP AUTH ohnehin standardmäßig ausgeschaltet; die Ankündigung betrifft also vor allem ältere Tenants. Zweitens: Sind in Microsoft Entra ID die Sicherheitsstandards („security defaults") aktiv, ist SMTP AUTH schon heute abgeschaltet; wer es nutzen will, muss sie deaktivieren, was Sie nur mit einer sauberen Ersatzabsicherung tun sollten.

/02Zeitachse: Wie der Termin gewandert ist

Wer die Meldung zum ersten Mal liest, trifft auf ältere Beiträge mit anderen Daten. Das ist kein Widerspruch, sondern die Folge von zwei Verschiebungen. Wir haben sie aus den Beiträgen des Exchange-Teams zusammengestellt (Stand 5. November 2026):

Ob die frühere Planung für März und April 2026 formal aufgehoben ist, steht nirgends in einem Satz; wir lesen sie als überholt, weil der Nachtrag im alten Beitrag selbst auf den neuen verweist und die neue Planung ausdrücklich Dezember 2026 nennt. Wer sich auf Schlagzeilen von Anfang des Jahres bezieht, sollte das Datum im Original nachlesen.

Eine praktische Folgerung: Die Daten sind Stand heute, aber sie haben sich schon zweimal bewegt. Bauen Sie Ihre Umstellung deshalb nicht auf den letzten möglichen Tag. Die Umstellung eines Scanners ist keine Frage von Minuten, wenn der Hersteller ein Firmware-Update braucht.

/03Wer im Betrieb SMTP AUTH nutzt — und wie Sie das finden

Die Frage ist nicht „Nutzen wir SMTP AUTH?", sondern „Wer?". In kleinen und mittleren Betrieben sind es fast immer dieselben Verdächtigen:

• Multifunktionsgeräte und Scanner mit „Scan to Mail", oft von einem Dienstleister vor Jahren eingerichtet und seitdem nicht angefasst.
• Fachanwendungen wie Warenwirtschaft, Buchhaltung, Ticketsystem oder Zeiterfassung, die Belege und Benachrichtigungen verschicken.
• Monitoring und Backup, die Alarme per Mail senden.
• Skripte und Aufgaben auf Servern, vom Wartungsskript bis zum Berichtsversand.
• Web-Formulare in Content-Management-Systemen, die über ein Postfach versenden.
• Altgeräte: eine Telefonanlage, ein Faxserver, eine Alarmanlage.

Ein häufig übersehener Fall ist der eigene Mailserver. Wer noch einen Exchange 2016 oder 2019 im Haus hat, nutzt ihn oft als Relay für genau diese Geräte; er nimmt ihre Mails an und leitet sie weiter. Fällt der Server weg, braucht das Relay ein neues Zuhause. Wie der Server abzubauen ist, steht im Beitrag zum ESU-Ende von Exchange 2016 und 2019; der Relay-Punkt gehört auf dieselbe Liste.

Was Microsoft zum Finden bereitstellt

Das Exchange-Team hat 2024 angekündigt, den Bericht „SMTP AUTH Clients Submission" im Exchange Admin Center so zu erweitern, dass er zeigt, ob Basic Authentication oder OAuth zur Übermittlung benutzt wird. Der genaue Pfad der Oberfläche ändert sich; wir haben ihn nicht geprüft und beschreiben deshalb den Bericht nur. Verlässlich lässt sich dagegen der Konfigurationsstand abfragen. Die folgenden Befehle stammen aus der Microsoft-Dokumentation und liefern, wo SMTP AUTH ausdrücklich ein- oder ausgeschaltet ist:

# Mit Exchange Online verbinden (Modul ExchangeOnlineManagement)
Connect-ExchangeOnline

# 1. Organisationsweite Einstellung: False = SMTP AUTH ist an
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

# 2. Postfächer mit ausdrücklicher Freigabe (False = an)
$Users = Get-CASMailbox -ResultSize unlimited
$Users | where {$_.SmtpClientAuthenticationDisabled -eq $false}

# 3. Postfächer mit ausdrücklicher Sperre (True = aus)
$Users | where {$_.SmtpClientAuthenticationDisabled -eq $true}

# 4. Postfächer ohne eigenen Wert: gilt die Organisationseinstellung
$Users | where {$_.SmtpClientAuthenticationDisabled -eq $null}

Hinweis zur Prüfung: Diese Befehle sind nicht getestet, weil uns für den Artikel kein Mandant zur Verfügung stand; die Syntax entspricht der Microsoft-Dokumentation (Stand 7. Oktober 2026). Probieren Sie sie in einem Testlauf, bevor Sie Ergebnisse weiterverwenden.

Zur Deutung: SmtpClientAuthenticationDisabled kennt drei Zustände. True heißt aus, False heißt an, und ein leerer Wert heißt: Die Organisationseinstellung gilt. Der Wert am Postfach hat Vorrang vor dem Wert der Organisation. Steht die Organisation auf False und das Postfach leer, ist SMTP AUTH also an — die Liste der Postfächer mit ausdrücklichem False ist dann nur ein Teil der Wahrheit.

Die Konfiguration sagt aber nur, was möglich ist, nicht, was benutzt wird. Die zweite Quelle ist deshalb der Gegencheck am Gerät: Wer in der Weboberfläche des Scanners smtp.office365.com mit Port 587 oder 25 eingetragen findet, nutzt SMTP AUTH. Legen Sie eine Liste an: Gerät, Standort, Postfach, Hersteller, Firmware, Wunschziel.

/04Die Wege im Vergleich: Client-Übermittlung, Relay, Direct Send, High Volume Email

Microsoft beschreibt vier Verfahren, mit denen Geräte und Anwendungen über Microsoft 365 Mail versenden. Die Tabelle fasst die Anforderungen aus der Dokumentation (Stand 5. Oktober 2026) zusammen:

Zwei Zeilen daraus verdienen Aufmerksamkeit. Die letzte: Das Ende von Basic Authentication bei SMTP AUTH trifft nur die erste Spalte. Wer sein Gerät auf Relay oder High Volume Email umstellt, umgeht die Frage, statt sie zu lösen — das ist erlaubt und oft der klügste Weg, aber es ist ein Plattformwechsel mit eigenen Pflichten. Die Zeile „Grenzen": Bei der Client-Übermittlung zählen 30 Nachrichten je Minute; ein Scanner, der einen Stapel Belege als einzelne Mails versendet, kann in diese Grenze laufen.

Microsoft selbst rät bei Direct Send zur Zurückhaltung: „Most customers don't need to use Direct Send", und das Unternehmen arbeitet an einer Option, Direct Send standardmäßig abzuschalten. Wir sehen das genauso. Direct Send ist ein offener Eingang ohne Anmeldung; er schützt nur, was die Absenderprüfung durchsetzt — SPF, DKIM und DMARC im DNS Ihrer Domäne. Wer ihn offen lässt, riskiert Phishing im Namen der eigenen Domäne. Wie Sie das sauber aufsetzen, steht im Beitrag zu SPF, DKIM und DMARC 2026.

/05Fachanwendungen und Skripte: OAuth oder Graph

Für Programme, die Sie selbst konfigurieren oder deren Hersteller es kann, ist OAuth der vorgesehene Weg. Das Prinzip: Statt Kennwort schickt die Anwendung ein Zugriffstoken, das nach kurzer Zeit abläuft und nur für diese Anwendung und diesen Zweck gilt. Es lässt sich zudem mit Mehr-Faktor-Anmeldung und mit Conditional Access verbinden, was bei Basic Authentication laut Microsoft nicht einfach oder gar nicht möglich ist.

Zwei Varianten kennt die Dokumentation. Bei der delegierten Anmeldung meldet sich ein Benutzer an, die Anwendung erhält den Bereich https://outlook.office.com/SMTP.Send. Bei der Dienstanmeldung ohne Benutzer (Client-Credentials-Fluss) bekommt die Anwendung die Berechtigung SMTP.SendAsApp, der Bereich lautet https://outlook.office365.com/.default, und der Administrator registriert den Dienstprinzipal in Exchange. Für Skripte und unbeaufsichtigte Fachanwendungen ist die zweite Variante die richtige:

# Registrierung der Anwendung in Exchange (Client-Credentials-Fluss), Syntax laut Learn
Connect-ExchangeOnline -Organization <TenantId>
New-ServicePrincipal -AppId <ApplicationId> -ObjectId <ObjectId-der-Unternehmensanwendung>
Add-MailboxPermission -Identity "versand@example.de" -User <ServicePrincipal-Id> -AccessRights FullAccess
# Soll als anderer Absender gesendet werden: zusätzlich Add-RecipientPermission (SendAs)

Beachten Sie die Besonderheit der Dokumentation: Für die Rechtevergabe braucht es die Objekt-ID der Unternehmensanwendung, nicht die der App-Registrierung; die falsche ID führt zu einem Anmeldefehler. Die Anwendung bekommt außerdem Vollzugriff auf das Postfach, das sie nutzt — legen Sie dafür ein dediziertes Postfach an und keines, in dem echte Mails liegen.

Das Token transportiert die Anwendung im Format SASL XOAUTH2. Wer eigenen Code schreibt, kann die Zeichenkette selbst bilden. Wir haben die Kodierung gegen das Beispiel in der Microsoft-Dokumentation geprüft: Das Skript unten liefert exakt den dort genannten Wert.

# Zugangsdaten für SASL XOAUTH2 (Python 3) -- Format laut Microsoft Learn
import base64

def xoauth2(user, access_token):
    raw = f"user={user}\x01auth=Bearer {access_token}\x01\x01"
    return base64.b64encode(raw.encode()).decode()

print(xoauth2("test@contoso.onmicrosoft.com",
              "EwBAAl3BAAUFFpUAo7J3Ve0bjLBWZWCclRC3EoAA"))
# dXNlcj10ZXN0QGNvbnRvc28ub25taWNyb3NvZnQuY29tAWF1dGg9QmVhcmVyIEV3QkFBbDNCQUFV
# RkZwVUFvN0ozVmUwYmpMQldaV0NjbFJDM0VvQUEBAQ==   (Ausgabe in einer Zeile)

Der zweite Weg ist die Microsoft Graph API: Die Dokumentation nennt sendMail als Alternative zu SMTP für authentifizierten Mailversand. Er verlangt mehr Programmieraufwand, ist aber unabhängig vom SMTP-Protokoll und dessen Beschränkungen. Fragen Sie den Hersteller Ihrer Fachanwendung nach beidem, bevor Sie selbst bauen: „Unterstützt die Anwendung OAuth für SMTP, und ab welcher Version?" ist eine Frage, die der Support in der Regel schnell beantwortet. Eine ausweichende Antwort ist selbst eine Antwort.

Ein weiterer Termin liegt nahe: Für Fachanwendungen, die Exchange Online über EWS ansprechen, beginnt am 1. April 2027 die endgültige Entfernung. Wer ohnehin mit dem Hersteller spricht, sollte beide Fragen in einem Termin klären; den Stand dazu haben wir im Beitrag EWS-Abschaltung in Exchange Online zusammengefasst.

/06Geräte mit Benutzername und Kennwort: High Volume Email oder Relay

Viele Drucker und Scanner kennen kein OAuth. Für sie sieht Microsoft zwei Auswege vor, die ohne das Ende von Basic Authentication auskommen.

High Volume Email

High Volume Email (HVE) ist ein eigener Dienst für Geräte und Anwendungen, die intern senden. Er arbeitet mit eigenen HVE-Konten ohne Postfach, Endpunkt smtp.hve.mx.microsoft, Port 587 mit Pflicht-TLS. Das Konto authentifiziert sich mit Kennwort oder mit OAuth. Wichtig für die Umstellung: HVE-Konten können sich auch anmelden, wenn SMTP AUTH im Tenant ausgeschaltet ist, weil HVE einen eigenen Endpunkt nutzt. Für ein Gerät, das nur Benutzername und Kennwort kann, ist HVE also ein Weg, der durch die Änderung im Dezember nicht berührt wird.

Die Grenzen laut Dokumentation: nur Empfänger im eigenen Tenant, bis zu 50 Empfänger je Nachricht, 10 MB je Nachricht, höchstens 100 HVE-Konten je Tenant. Ein Scanner, der an Kunden mailt, scheidet damit aus. Der Dienst wird nach Verbrauch abgerechnet, über Microsoft 365 Pay-as-you-go mit einem Azure-Abonnement: 0,000042 US-Dollar je zugestelltem Empfänger, das sind 42 US-Dollar je Million. Verteilerlisten werden vor der Zählung aufgelöst.

SMTP-Relay über einen Connector

Das Relay arbeitet ohne Postfach und ohne Anmeldung am Postfach: Ein eingehender Connector in Exchange Online erkennt das Gerät an einem TLS-Zertifikat oder an einer festen öffentlichen IP-Adresse. Das Gerät sendet an den MX-Endpunkt Ihrer Domäne, Port 25. Es kann an interne und externe Empfänger senden und mit jeder Absenderadresse einer akzeptierten Domäne. Der Preis: ein SPF-Eintrag, der die IP-Adresse berücksichtigt, eine statische, nicht mit anderen geteilte Adresse (sofern kein Zertifikat genutzt wird), und die Gewissheit, dass die Mails nicht in „Gesendete Elemente" landen. Von Diensten in fremden Clouds wie Azure aus ist das Relay nicht nutzbar. Außerdem rät die Dokumentation, einen vorhandenen, unterstützten eigenen Mailserver für das Relay zu bevorzugen, weil er leichter zu konfigurieren ist; ein Exchange 2016 oder 2019 gehört nach dem Oktober 2026 nicht mehr dazu.

/07Überbrücken: SMTP AUTH wieder einschalten

Ein Gerät, das sich bis Ende Dezember nicht umstellen lässt, braucht eine Brücke. Die Ankündigung sagt dazu nur: Administratoren können Basic Authentication wieder einschalten. Die Schritte stehen in der allgemeinen Dokumentation zu SMTP AUTH. Sinnvoll ist die Freigabe je Postfach statt für die ganze Organisation, weil der Postfachwert Vorrang hat:

# Für ein einzelnes Postfach einschalten (Postfachwert gilt vor Organisationswert)
Set-CASMailbox -Identity scanner@example.de -SmtpClientAuthenticationDisabled $false

# Auf die Organisationseinstellung zurückstellen
Set-CASMailbox -Identity scanner@example.de -SmtpClientAuthenticationDisabled $null

# Organisationsweit aus- oder einschalten (aus = $true, an = $false)
Set-TransportConfig -SmtpClientAuthenticationDisabled $true

Diese Befehle sind, wie die anderen PowerShell-Beispiele, nicht getestet und folgen der Microsoft-Dokumentation. Wichtiger als die Syntax ist die Frage, was die Brücke trägt. Drei Regeln, die wir anwenden:

• Ein Postfach je Gerät oder Anwendung. Das Kennwort steht im Gerät; geht es verloren oder wird es missbraucht, ist der Schaden auf dieses Postfach begrenzt. Das Postfach hat sonst keine Funktion und kein Postfachrecht außer dem Senden.
• Absender festlegen. Soll das Gerät als anderer Absender senden als das anmeldende Postfach, braucht das anmeldende Konto das Recht „Senden als"; ohne das kommt die Rückmeldung 5.7.60.
• Datum eintragen. Die Brücke ist befristet, weil Microsoft das Endedatum für die zweite Jahreshälfte 2027 ankündigt. Wer sie ohne Datum einrichtet, hat im Herbst 2027 dieselbe Aufgabe unter Zeitdruck.

Was die Ankündigung offenlässt: ob eine ausdrücklich gesetzte Postfacheinstellung die Umstellung Ende Dezember unverändert übersteht. Die Beschreibung spricht nur von „disabled by default". Wir würden deshalb nicht darauf bauen, dass ein vorab gesetztes False hält. Planen Sie einen Test nach der Umstellung ein und halten Sie die Befehle zum Wiedereinschalten bereit — am besten als Runbook, nicht im Kopf einer einzelnen Person.

Eine ehrliche Einschätzung zur Sicherheit: Bei Basic Authentication lässt sich keine zusätzliche Hürde wie die Mehr-Faktor-Anmeldung vorschalten. Die Microsoft-Dokumentation zur Abschaltung von Basic Authentication begründet das Ende damit, dass Zugangsdaten leichter abzugreifen sind und dass die Durchsetzung von Mehr-Faktor-Anmeldung dabei nicht einfach oder nicht möglich ist. Ein Postfach mit SMTP-Kennwort im Scanner ist ein Konto, das Angreifer finden wollen. Behandeln Sie es entsprechend: langes Zufallskennwort, kein Zugriff auf andere Postfächer, Anmeldungen in der Überwachung. Gehören die Anmeldeprotokolle schon in ein SIEM, gehört dieses Konto dazu. Taucht es plötzlich mit Anmeldungen aus fremden Netzen auf, ist das ein Fall für den Vorfallprozess, nicht für die Ablage.

/08Wo es hakt: Absender, TLS, Port 465, Security Defaults

Die typischen Fehlerbilder bei der Umstellung stehen fast alle in der Dokumentation, nur an vier verschiedenen Stellen:

• Port und TLS: Client-Übermittlung und HVE verlangen TLS 1.2 oder 1.3. Ein Gerät, das nur Port 465 anbietet oder TLS 1.2 nicht kann, funktioniert laut Dokumentation nicht: Wer standardmäßig Port 465 vorschlägt, unterstützt die geforderten TLS-Versionen nicht. Das trifft vor allem ältere Scanner. Für sie bleiben Relay mit IP-Authentifizierung oder ein Gerätetausch.
• Absenderadresse: Weicht die Absenderadresse vom Konto ab, das sich anmeldet, fehlt das Recht „Senden als" — Meldung „Client doesn't have permissions to send as this sender".
• Security Defaults und Authentifizierungsrichtlinie: Sind die Sicherheitsstandards aktiv oder sperrt eine Authentifizierungsrichtlinie Basic Authentication für SMTP, funktioniert das Gerät auch dann nicht, wenn SMTP AUTH im Postfach eingeschaltet ist.
• Relay und Spam-Prüfung: Beim Relay und bei Direct Send gelten Spam-Prüfungen; verdächtige Mails können gefiltert werden. Der SPF-Eintrag mit der richtigen IP ist keine Kür.
• Nachrichten, die nicht ankommen: Die Client-Übermittlung speichert in „Gesendete Elemente", Relay und HVE nicht. Wer die Kopie als Nachweis nutzt, merkt die Lücke nicht sofort.
• Altlasten: Ein Windows Server mit IIS-SMTP-Dienst ist laut Dokumentation als Relay zu Microsoft 365 nicht unterstützt; Windows Server 2022 ist die letzte Version mit diesem Dienst.

Der letzte Punkt trifft alte Notlösungen: Mancher Betrieb hat vor Jahren einen kleinen Windows-Server als Sammelrelais aufgesetzt. Er läuft, und niemand weiß mehr, warum. Dann ist die Umstellung die Gelegenheit, die Mailwege einmal zu zeichnen: Quelle, Weg, Ziel, Anmeldung.

/09Entscheidung und Plan bis Silvester

Die Entscheidung folgt dem Gerät und dem Zielkreis der Mails, nicht einem Standard für alle:

Wann der Aufwand für Sie nicht anfällt: wenn Ihr Tenant nach Januar 2020 entstanden ist (dort ist SMTP AUTH ohnehin aus), wenn Ihre Postfächer nicht in Exchange Online liegen oder wenn ein Gerät schon über einen eigenen Relay-Server mailt. Und wann Exchange Online selbst die falsche Wahl für den Massenversand ist: bei Newslettern und Marketing-Mails an externe Empfänger. Microsoft nennt für interne und externe Mails Azure Communication Services Email, für externe Massenmails sind spezialisierte Dienste die bessere Wahl; HVE ist ausdrücklich nur für interne Empfänger gedacht.

Eine Reihenfolge für die Wochen bis Silvester:

• Woche 1 (ab 10. November): Befehle aus /03 laufen lassen, Geräteliste anlegen, Hersteller anschreiben.
• Woche 2 und 3: Zielweg je Gerät festlegen. Das Azure-Abonnement für HVE und die Connectoren für das Relay vorbereiten; SPF anpassen.
• Bis Anfang Dezember: Ein Gerät je Typ umstellen und einen Monat beobachten: kommen Scan-Mails an, auch mit Anhang, auch an externe Adressen?
• Mitte Dezember: Rest umstellen. Geräte, die nicht umgestellt werden können, mit befristeter Brücke einplanen.
• Nach dem Jahreswechsel: Prüfen, ob die Umstellung gegriffen hat; Brücken mit Datum in den Kalender. Der Vorgang bleibt offen, bis Microsoft das Endedatum 2027 nennt.

Zum Schluss ein Wort zur Einordnung. Das Thema ist ein Beispiel für die Art von Betriebsaufgabe, die keinen Alarm auslöst, bis sie ausfällt: Niemand sieht, dass die Scan-Mails am 2. Januar nicht mehr ankommen, bis die Buchhaltung anruft. Wer die Mailwege dokumentiert hat, liest die Ankündigung des Herstellers in fünf Minuten. Wer sie nicht hat, muss sie erst rekonstruieren. Bei Hybridumgebungen mit eigenem Exchange und Exchange Online kommt hinzu, dass zwei Systeme Absender sein können — dort lohnt sich die Zeichnung doppelt.

/10Häufige Fragen