Website-Mails mit Microsoft 365: OAuth statt Basic Auth

Das Formular kann über das Hosting, einen gesonderten Versanddienst oder ein Firmenpostfach senden. Auch Benachrichtigungen einer Webanwendung und Bestätigungen an Interessenten können unterschiedliche Verbindungen nutzen. Beginnen Sie deshalb bei den tatsächlichen Nachrichten: Welche Funktion löst sie aus, welches System versendet sie und wer soll sie erhalten?

Die SMTP-AUTH-Dokumentation bestätigt, dass das Protokoll sowohl OAuth als auch Basisauthentifizierung unterstützt. Organisations- und Postfacheinstellungen sowie Sicherheitsrichtlinien wirken zusammen. Ein sichtbarer SMTP-Schalter beantwortet daher nicht allein, ob eine bestimmte Anmeldung funktioniert. Lassen Sie die zuständige Administration die vorhandene Konfiguration einordnen.

Als Nachweis kann der SMTP-AUTH-Clients-Bericht helfen: Er zeigt unter anderem Absender und Authentifizierungsprotokoll. Die Dokumentation unterscheidet Basic Auth und Modern Auth. Ein leerer Bericht muss mit passendem Zeitraum geprüft werden. Er ersetzt keine vollständige Inventur aller Website-Nachrichten.

Erfassen Sie auch seltene Auslöser: eine monatliche Zusammenfassung, einen zurückgesetzten Zugang oder eine Vertretungsnachricht. Ein erfolgreich getestetes Kontaktformular deckt diese Abläufe nicht mit ab. In die Bestandsliste gehören Zuständigkeit und Konfigurationsort, aber keine Kennwörter oder Token.

Die OAuth-Dokumentation für SMTP beschreibt App-Registrierung, Tokenabruf und Anmeldung mit dem Token. Versand im Namen einer angemeldeten Person und selbstständige Hintergrundanwendungen verwenden unterschiedliche Berechtigungswege. Welche Zustimmung und Postfachzuordnung nötig sind, hängt vom gewählten Verfahren ab. Ein Token ist daher kein Wert, der einmal in ein Passwortfeld kopiert wird.

Das folgende Migrationsblatt ist eine eigene Planungshilfe. Füllen Sie es zunächst für genau eine Verbindung aus. Erst danach lässt sich beurteilen, welche weiteren Formulare dieselbe Einrichtung verwenden dürfen und welche einen eigenen Auftrag brauchen.

Zu jedem offenen Punkt gehört eine Person, die ihn klärt. „Macht das Plugin“ ist keine ausreichende Zuständigkeit für eine Freigabe, die nur Ihre Administration erteilen kann.

Ein fiktiver Metallbaubetrieb erhält über seine Website Anfragen zu individuellen Bauteilen. Das Formular sendet eine Nachricht an das interne Vertriebsteam und eine kurze Bestätigung an die anfragende Person. Die Website liegt bei einem externen Hoster. Die bisherige Verbindung nutzt ein Firmenpostfach mit Basisauthentifizierung.

Bei der Bestandsaufnahme entdeckt das Team zusätzlich eine zweite Versandfunktion für Angebotsunterlagen. Sie läuft in einer anderen Anwendung und gehört deshalb nicht stillschweigend zur ersten Umstellung. Im Migrationsblatt werden beide Verbindungen getrennt erfasst. Für den ersten Auftrag bleibt das Website-Formular der klar abgegrenzte Umfang.

Website-Entwicklung und Postfachadministration prüfen gemeinsam den passenden Anmeldeweg. Die interne verantwortliche Person gibt die erforderliche Einrichtung frei. In einer getrennten Probe werden nur abgestimmte Testadressen und erfundene Anfragedaten verwendet. Die Bestätigung an einen externen Empfänger gehört ausdrücklich zur Abnahme.

Vor der Umschaltung klärt der Betrieb, wie eine Anfrage erreichbar bleibt, wenn der Mailversand scheitert. Die Formulardarstellung soll keinen erfolgreichen Versand behaupten, der technisch nicht bestätigt ist. Nach dem Wechsel wird derselbe Ablauf erneut geprüft, bevor die alte Verbindung aus der Anwendung entfernt wird.

Dieses Beispiel ist eine eigene Planungssituation mit fiktiven Beteiligten. Es enthält weder ein Ruhrstack-Kundenergebnis noch eine Aussage zur tatsächlichen Einrichtung eines bestimmten Microsoft-Mandanten.

Ruhrstack kann im vereinbarten Entwicklungsauftrag die vorhandene Website-Anbindung untersuchen, notwendige Anpassungen einordnen und eine passende Umsetzung mit konkreten Prüffällen vorbereiten. Bei Hosting und Betrieb werden die relevanten Abhängigkeiten und Zuständigkeiten abgestimmt. Die Freigabe von Unternehmenszugriffen bleibt bei den dafür autorisierten Personen.

Für ein erstes Gespräch reichen Website-Adresse, betroffene Nachrichtenart und eine kurze Beschreibung der vorhandenen Betreuung. Zugangsdaten werden dafür nicht benötigt. Eine sinnvolle Rückmeldung benennt dann, was bereits belegt ist, welche Angaben fehlen und welche einzelne Änderung als Nächstes geprüft werden sollte.

So entsteht ein nachvollziehbarer Übergang mit bekannter Verantwortung. Die Bezeichnung OAuth allein verspricht weder eine fehlerfreie Einrichtung noch die Zustellung jeder Nachricht. Maßgeblich sind die passende Konfiguration, die vereinbarte Probe und die anschließende Pflege.

Redaktion

Ruhrstack, Dortmund

Veröffentlicht

9. November 2026

Aktualisiert

10. November 2026

Quellen geprüft

10. November 2026

1. Microsoft Exchange Team: Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline: Ankündigung vom 27. Januar 2026, aktualisiert am 29. Januar: veränderte Standardeinstellungen und spätere Bekanntgabe des endgültigen Entfernungstermins. Abgerufen am 10. November 2026.
2. Microsoft Learn: Enable or disable authenticated client SMTP submission (SMTP AUTH) in Exchange Online: Unterstützte Authentifizierung und Zusammenspiel von Organisations-, Postfach- und Sicherheitsrichtlinien. Abgerufen am 10. November 2026.
3. Microsoft Learn: SMTP AUTH Clients report in the new Exchange admin center in Exchange Online: Bericht zu Absendern, Zeitraum und verwendeter Basic- oder Modern-Auth-Anmeldung. Abgerufen am 10. November 2026.
4. Microsoft Learn: How to set up a multifunction device or application to send email using Microsoft 365 or Office 365: Versandverfahren, Empfängergrenzen und Voraussetzungen für extern gehostete Anwendungen. Abgerufen am 10. November 2026.
5. Microsoft Learn: Authenticate an IMAP, POP or SMTP connection using OAuth: App-Registrierung, Token und unterschiedliche Berechtigungswege für OAuth-Verbindungen. Abgerufen am 10. November 2026.
6. Microsoft Learn: Security best practices for application properties in Microsoft Entra ID: Berechtigungen, Anwendungsverantwortung sowie geschützter Umgang mit Zertifikaten und Secrets. Abgerufen am 10. November 2026.
7. Microsoft: Trademark and Brand Guidelines: Sachliche Namensnennung und Kennzeichnung der Markeninhaberschaft. Abgerufen am 10. November 2026.
8. Microsoft: Publications, seminars, and conferences guidelines: Unabhängigkeit redaktioneller Veröffentlichungen und vorgegebene Markenfußnote. Abgerufen am 10. November 2026.

Marken und Unabhängigkeit: Microsoft, Exchange, Microsoft 365 und Microsoft Entra sind Marken der Microsoft-Unternehmensgruppe. All other trademarks are the property of their respective owners. Die Namen dienen hier der sachlichen Zuordnung. Dieser unabhängige Ruhrstack-Beitrag ist weder mit Microsoft verbunden noch von Microsoft beauftragt, autorisiert, gesponsert oder freigegeben.

Redaktioneller Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Einzelfallprüfung. Trotz sorgfältiger Recherche wird keine Gewähr für Vollständigkeit und fortdauernde Aktualität übernommen. Eine Haftung nach zwingenden gesetzlichen Vorschriften bleibt unberührt. Redaktionelle Einordnung.