Wer WordPress mit Microsoft 365 nutzen möchte, steht früher oder später vor dem Thema SMTP. Klassisches SMTP mit Benutzername und Passwort funktioniert in vielen Microsoft-365-Umgebungen nur eingeschränkt oder gar nicht mehr. Die saubere Lösung für WordPress Microsoft 365 SMTP heißt OAuth. In dieser Anleitung zeigen wir Schritt für Schritt, wie Sie FluentSMTP korrekt mit Microsoft 365 verbinden – inklusive Entra-App, Mail.Send-Berechtigung und den typischen Stolperfallen aus der Praxis.
Warum Microsoft 365 eine saubere OAuth-Anbindung braucht
Microsoft verschärft seit Jahren die Sicherheitsanforderungen für den Mailversand. Klassisches SMTP-Login mit Benutzername und Passwort wird in vielen Tenants blockiert oder funktioniert nur eingeschränkt.
Die saubere Lösung heißt OAuth. Das bedeutet: WordPress bekommt keinen direkten Passwortzugang, sondern eine autorisierte Verbindung über eine registrierte App. Das ist sicherer, stabiler und langfristig die einzig sinnvolle Variante.
Voraussetzungen für die Einrichtung
Bevor Sie starten, klären Sie intern drei Punkte. Wenn das nicht sauber vorbereitet ist, bleiben Sie später in der Einrichtung hängen.
- Welche Microsoft-365-E-Mail-Adresse soll als Absender verwendet werden?
Definieren Sie klar eine konkrete Mailbox, zum Beispiel info@ oder no-reply@. Diese Adresse wird später technisch authentifiziert. - Existiert diese Mailbox im Tenant und darf sie E-Mails versenden?
Die Mailbox muss real angelegt sein und SMTP-basierten Versand erlauben. Bei Shared Mailboxes ist zusätzlich zu prüfen, ob die entsprechenden Sendeberechtigungen korrekt gesetzt sind. - Wer hat Adminzugriff auf Microsoft Entra?
Für die App-Registrierung und die Vergabe der API-Berechtigungen sind Administratorrechte im Microsoft Entra Admin Center erforderlich. Ohne diese Rechte lässt sich die Verbindung nicht vollständig einrichten.
Schritt 1: FluentSMTP in WordPress vorbereiten
Bevor Sie mit der Verbindung zu Microsoft 365 beginnen, muss das Plugin korrekt installiert und aktiviert sein. Wir setzen voraus, dass FluentSMTP bereits auf Ihrer Website installiert ist. Nach unserer Erfahrung ist es ein zuverlässiges, schlankes und kostenfreies Plugin, das sich für den produktiven Einsatz gut eignet.
Wichtig ist außerdem, dass Sie Zugriff auf das WordPress-Backend sowie auf das entsprechende Microsoft-365-Konto haben, da im weiteren Verlauf eine Authentifizierung durchgeführt wird.
Vorgehen im WordPress-Backend:
- WordPress Backend öffnen
- Einstellungen → FluentSMTP → Einstellungen
- Add Connection auswählen
- Mailer: Microsoft 365 / Outlook wählen
Wichtig: Nicht „Other SMTP“ auswählen. Für Microsoft 365 sollte OAuth genutzt werden.
In den Einstellungen wird eine sogenannte App Callback URL angezeigt. Diese URL müssen Sie exakt kopieren. Sie wird später in Entra hinterlegt.
Schritt 2: App in Microsoft Entra registrieren
Jetzt wird es technisch. Sie legen in Microsoft Entra eine eigene App an, über die WordPress später sauber und autorisiert E-Mails versenden darf.
Öffnen Sie das Microsoft Entra Admin Center unter entra.microsoft.com.
Navigation:
Entra ID → App-Registrierungen → Neue Registrierung
Folgende Einstellungen sind entscheidend:
- Name: zum Beispiel „WordPress SMTP – IhreDomain“ – Der Name ist intern, wählen Sie ihn aber so, dass Sie ihn später eindeutig zuordnen können.
- Unterstützte Kontotypen: Wählen Sie hier „Mehrere Entra ID-Mandanten“ und aktivieren Sie „Alle Mandanten zulassen“.
- Umleitungs-URI hinzufügen: Typ „Web“
- URL: Exakt die Redirect-URL aus FluentSMTP übernehmen. Keine Abweichung, kein fehlender Slash, kein http statt https. Wenn die URL nicht 1:1 stimmt, funktioniert die Authentifizierung nicht!
- Abschließend unten auf „Registrieren“ klicken
Nach dem Klick landen Sie direkt in der neu angelegten App. Dort geht es im nächsten Schritt mit Client-ID, Client-Secret und API-Berechtigungen weiter.
Schritt 3: Client-ID und Mandanten-ID übernehmen
Nach der Registrierung landen Sie auf der Übersichtsseite der neu angelegten App. Dort finden Sie zwei zentrale Werte:
- Anwendungs-ID (Client-ID)
- Verzeichnis-ID (Mandanten-ID)
Die Anwendungs-ID, also die Client-ID, wird später in FluentSMTP in WordPress eingetragen. Kopieren Sie sich diesen Wert am besten direkt sauber heraus.
Die Mandanten-ID wird je nach Konfiguration ebenfalls benötigt, insbesondere wenn FluentSMTP danach fragt oder wenn Sie die Verbindung manuell prüfen müssen. Beide Werte sollten Sie daher griffbereit dokumentieren.
Schritt 4: Client Secret erstellen
Ohne Client-Secret kann die Verbindung nicht kryptografisch signiert werden. Die App wäre zwar registriert, aber WordPress könnte sich nicht gegenüber Microsoft authentifizieren.
Gehen Sie in der App zu:
Zertifikate & Geheimnisse → Neuer geheimer Clientschlüssel
Dort:
- Beschreibung vergeben, zum Beispiel „FluentSMTP WordPress“
- Ablaufzeit definieren. Wählen Sie hier bewusst einen Zeitraum, der zu Ihrem Wartungskonzept passt. Läuft das Secret ab, funktioniert der Mailversand nicht mehr. Abgelaufene Secrets sind einer der häufigsten Gründe für plötzlich nicht funktionierende E-Mails.
- Auf „Hinzufügen“ klicken, um das Secret zu erstellen.
Nach dem Erstellen wird ein „Wert“ angezeigt.
Diesen Wert sofort kopieren und sicher speichern.
Wichtig: Es geht nicht um die „Geheimnis-ID“, sondern um den tatsächlichen „Wert“. Dieser wird nur einmal angezeigt. Wenn Sie ihn nicht sichern, müssen Sie ein neues Secret erzeugen.
Schritt 5: API-Berechtigungen prüfen, konkret Microsoft Graph – Mail.Send
Hinweis zu Mail.Send:
In vielen Microsoft-365-Umgebungen ist keine separate Administratorzustimmung erforderlich. Die Berechtigung „Mail.Send“ wird im Rahmen der OAuth-Anmeldung automatisch genehmigt, sobald Sie die angezeigten Berechtigungen bestätigen.
Unser Tipp: Erst normal authentifizieren und testen. Wenn der Versand funktioniert, müssen Sie hier nichts weiter tun. Erst bei Fehlermeldungen wie „insufficient privileges“ oder „not authorized“ sollten Sie die Berechtigung und die Admin-Zustimmung gezielt prüfen.
Damit WordPress über Microsoft 365 E-Mails versenden darf, braucht die registrierte App die Berechtigung Mail.Send innerhalb von Microsoft Graph. Ohne diese Berechtigung kann die Authentifizierung zwar funktionieren, der Versand selbst wird aber blockiert.
In vielen Umgebungen wird Mail.Send während der OAuth-Autorisierung automatisch angefragt und bestätigt. Deshalb wird dieser Punkt oft übersprungen. Wenn später jedoch keine Mails rausgehen, ist das hier der erste Ort, den Sie prüfen sollten.
So kontrollieren Sie die Einstellung:
- entra.microsoft.com öffnen
- Entra ID → App-Registrierungen
- Ihre erstellte App auswählen
- Im linken Menü „API-Berechtigungen“ öffnen
Dort sollte ein Eintrag wie folgt sichtbar sein:
Microsoft Graph – Delegierte Berechtigung – Mail.Send
Falls Mail.Send noch nicht vorhanden ist:
- „Berechtigung hinzufügen“ anklicken
- Microsoft Graph auswählen
- „Delegierte Berechtigungen“ wählen
- Nach „Mail.Send“ suchen und hinzufügen
Anschließend oben auf „Administratorzustimmung erteilen“ klicken. Erst mit dieser Zustimmung ist die Berechtigung tenantweit aktiv.
Wichtig: Ohne die Berechtigung Mail.Send darf die App keine E-Mails im Namen des Benutzers versenden.
Wenn im FluentSMTP-Log später Meldungen wie „insufficient privileges“ oder „not authorized“ auftauchen, liegt die Ursache in der Praxis fast immer genau hier.
Bevor Sie also an WordPress, Caching oder Servereinstellungen zweifeln, prüfen Sie zuerst die API-Berechtigungen in Microsoft Entra. In den meisten Fällen ist das der entscheidende Punkt.
Schritt 6: Daten in FluentSMTP eintragen
Zurück in WordPress wechseln Sie nun in die FluentSMTP-Verbindung und tragen dort die zuvor erzeugten Werte ein:
- Client ID
- Client Secret
Anschließend speichern.
Nach dem Speichern erscheint ein „Authorize“-Button. Klicken Sie darauf. Sie werden zur Microsoft-Anmeldung weitergeleitet.
Melden Sie sich exakt mit dem Microsoft-365-Konto an, das später als Absender fungieren soll. Wenn Sie hier ein anderes Konto verwenden, passt die Autorisierung technisch nicht zur konfigurierten Mailbox.
Nach erfolgreicher Anmeldung und Bestätigung der Berechtigungen werden Sie zurück zu WordPress geleitet. In FluentSMTP wird die Verbindung anschließend als aktiv angezeigt. Ab diesem Moment kann der Versand über Microsoft 365 erfolgen.
Schritt 7: Absenderadresse sauber definieren
In FluentSMTP konfigurieren Sie anschließend die Absenderdaten:
- From Email: die echte Microsoft-365-Mailadresse
- From Name: Ihr Unternehmensname
Wichtig ist hier absolute Klarheit. Verwenden Sie ausschließlich eine reale, im Tenant existierende Mailbox, die auch autorisiert wurde.
Keine Fantasie-Adressen, keine umgebogenen Aliase ohne Berechtigung. Microsoft akzeptiert keinen Versand „im Namen von irgendwem“. Wenn die Adresse nicht exakt zur authentifizierten Mailbox passt oder keine Sendeberechtigung besteht, wird der Versand blockiert.
Schritt 8: OAuth-Authentifizierung durchführen (zweistufiger Login in der Praxis)
Nachdem Sie Client ID und Client Secret in FluentSMTP hinterlegt haben, folgt die eigentliche Autorisierung gegenüber Microsoft. Im Bereich „Outlook / Office 365 API Settings“ klicken Sie auf:
„Authenticate with Office 365 & Get Access Code“
Sie werden nun zu Microsoft weitergeleitet.
Wichtiger Hinweis: In manchen Microsoft-365-Tenants läuft dieser Prozess zweistufig ab:
- Phase 1: Admin-Login (wird manchmal von Microsoft erzwungen)
Microsoft verlangt zunächst eine Anmeldung mit einem Konto mit Admin-Rechten. Nach dem Login wird ein „Access Code“ angezeigt.
Wichtig: In diesem Fall ist dieser Code nicht der, den Sie am Ende für den Versand mit Ihrer Absender-Mailbox brauchen. Sie können ihn ignorieren. - Phase 2: Authentifizierung mit der tatsächlichen Absender-Mailbox
Starten Sie den Authentifizierungsprozess anschließend erneut und melden Sie sich diesmal mit der E-Mail-Adresse an, die später wirklich versenden soll.
Erst bei dieser zweiten Anmeldung ist der angezeigte Access Code für die richtige Mailbox ausgestellt.
Kopieren Sie dann den Access Code vollständig, fügen Sie ihn in FluentSMTP in das Feld „Access Token“ ein und klicken Sie auf „Save Connection Settings“.
Wenn die Verbindung korrekt steht, sehen Sie anschließend in FluentSMTP den Status, dass Microsoft 365 / Outlook verbunden ist.
Hinweis: Wenn Sie diesen zweiten Schritt überspringen, wirkt die Einrichtung zwar zunächst erfolgreich, der Versand scheitert aber später häufig mit „Forbidden“, weil die Autorisierung nicht zur tatsächlichen Absender-Mailbox passt.
Schritt 9: Testmail senden und Logs prüfen
Zum Abschluss sollten Sie den Versand sauber testen.
Senden Sie eine Testmail an eine externe Adresse, also nicht an die gleiche Microsoft-Domain. Ideal ist ein völlig unabhängiges Postfach, damit Sie sicher sehen, ob die Mail wirklich extern zugestellt wird.
Anschließend öffnen Sie in FluentSMTP die Protokolle.
Dort sehen Sie für jede versendete Mail den Status und gegebenenfalls eine konkrete Fehlermeldung. Wenn etwas nicht funktioniert, steht hier in der Regel sehr klar, ob es ein Authentifizierungsproblem, eine fehlende Berechtigung oder ein Konfigurationsfehler ist.
Erst wenn die Testmail erfolgreich zugestellt wurde und im Log als „Sent“ erscheint, ist die Einrichtung technisch sauber abgeschlossen.
Typische Fehler aus der Praxis
- Redirect-URL falsch eingetragen
Die URL muss exakt mit der in FluentSMTP angezeigten Redirect-URL übereinstimmen. Ein fehlender Slash oder eine abweichende Domain genügt, und die Authentifizierung schlägt fehl. - Single-Tenant-App mit /common-Endpoint (AADSTS50194)
Wird die App in Entra als „Nur meine Organisation“ registriert, kann es beim OAuth-Login zum Fehler AADSTS50194 kommen. FluentSMTP verwendet den /common-Endpoint von Microsoft, der nur mit Multi-Tenant-Apps funktioniert. Lösung: In der App-Registrierung „Mehrere Entra ID-Mandanten“ auswählen. - Client Secret abgelaufen
Wenn das Secret seine Ablaufzeit erreicht hat, bricht der Versand kommentarlos oder mit Authentifizierungsfehlern ab. In diesem Fall muss ein neues Secret erstellt und in WordPress hinterlegt werden. - Administratorzustimmung nicht erteilt
Mail.Send ist zwar hinzugefügt, aber die Admin-Zustimmung wurde nicht tenantweit erteilt. Ergebnis: „insufficient privileges“ oder „not authorized“. - Falsches Konto autorisiert
Bei der OAuth-Anmeldung wurde nicht die spätere Absender-Mailbox verwendet. In manchen Tenants verlangt Microsoft zunächst eine Anmeldung mit einem Admin-Konto. Der dabei angezeigte Access Code gehört jedoch zu diesem Admin-Benutzer. Wird dieser Code verwendet, scheitert der spätere Versand häufig mit „Forbidden“. In diesem Fall muss der Authentifizierungsprozess erneut mit der tatsächlichen Absender-Mailbox durchgeführt werden. Oder es wurde grundsätzlich nicht das spätere Absenderkonto verwendet. Die App ist dann technisch verbunden, darf aber nicht im Namen der gewünschten Mailbox senden. - Conditional Access blockiert den Zugriff
Sicherheitsrichtlinien im Tenant können App-Logins oder bestimmte Authentifizierungsflüsse blockieren. Das sieht dann wie ein SMTP- oder Plugin-Fehler aus, ist aber ein Entra-Policy-Thema.
In der Praxis liegt der Fehler in der überwiegenden Zahl der Fälle nicht in WordPress, sondern in Microsoft Entra.
Debug-Checkliste: Wenn WordPress Microsoft 365 SMTP nicht funktioniert
Wenn die Verbindung steht, aber keine E-Mails versendet werden oder Fehler wie „Forbidden“, „insufficient privileges“ oder AADSTS-Meldungen erscheinen, gehen Sie diese Punkte systematisch durch:
- Redirect-URL prüfen: Stimmt sie exakt mit der in FluentSMTP angezeigten URL überein? Kein http/https-Mix, kein fehlender Slash.
- Kontotyp prüfen: Ist die App in Entra als „Mehrere Entra ID-Mandanten“ registriert? Single-Tenant-Apps führen häufig zu AADSTS50194.
- Client Secret prüfen: Ist das Secret noch gültig? Wurde der tatsächliche „Wert“ (nicht die ID) in FluentSMTP eingetragen?
- OAuth erneut durchführen: Access Token löschen und die Authentifizierung neu starten.
- Richtige Mailbox verwendet? Wurde die OAuth-Anmeldung mit genau der E-Mail-Adresse durchgeführt, die später versenden soll?
- Admin-Login-Falle beachten: Wenn Microsoft zunächst ein Admin-Konto verlangt, den dabei angezeigten Code ignorieren und die Authentifizierung erneut mit der finalen Absender-Mailbox durchführen.
- Mail.Send prüfen: Ist die Berechtigung vorhanden? Wurde die Zustimmung im OAuth-Dialog akzeptiert?
- Conditional Access prüfen: Blockieren Sicherheitsrichtlinien App-Logins oder bestimmte Authentifizierungsflüsse?
- FluentSMTP-Log ansehen: Die genaue Fehlermeldung (z. B. invalid_client, invalid_grant, insufficient_privileges, forbidden) gibt fast immer einen klaren Hinweis.
Wenn Sie diese Punkte strukturiert prüfen, liegt die Ursache in der Regel nicht in WordPress selbst, sondern in der Entra- oder Microsoft-365-Konfiguration.
Warum wir diese Einrichtung nicht selbst für unsere Kunden autorisieren
Die OAuth-Autorisierung erfolgt direkt über das jeweilige Microsoft-365-Konto inklusive Mehrfaktor-Authentifizierung. Dabei werden sicherheitsrelevante Berechtigungen im Tenant vergeben.
Aus Sicherheits- und Compliance-Gründen muss diese Anmeldung immer intern erfolgen. Es geht hier nicht nur um ein technisches Login, sondern um die Freigabe einer Anwendung mit Zugriff auf Mail-Funktionen im Namen eines Benutzers.
Eine Agentur kann die App vorbereiten, die Konfiguration prüfen und durch den Prozess führen. Die eigentliche Authentifizierung und Freigabe gehört jedoch zwingend ins Unternehmen.
Fazit
Wer WordPress sauber und dauerhaft mit Microsoft 365 verbinden möchte, kommt an einer OAuth-basierten Lösung nicht vorbei. Alles andere ist heute entweder unsauber oder wird früher oder später von Microsoft blockiert.
FluentSMTP ist dafür eine technisch solide Lösung, vorausgesetzt die Entra-App ist korrekt registriert, die Berechtigung Mail.Send ist gesetzt und die Administratorzustimmung wurde erteilt. Genau an diesen Punkten scheitert es in der Praxis am häufigsten.
Wenn diese drei Dinge stimmen, läuft der E-Mail-Versand stabil und nachvollziehbar. Und genau das sollte bei einer professionell betriebenen Website kein Zufall sein, sondern Standard.