Background
I recently set up a WordPress site for a small business that uses Microsoft 365 for email. The obvious first attempt was to use WP Mail SMTP with basic SMTP auth — set the host to smtp.office365.com, port 587, STARTTLS, drop in an app password, and call it done. That didn’t work.
The SMTP debug log told the story clearly:
535 5.7.139 Authentication unsuccessful, user is locked by your organization's security defaults policy.
Microsoft 365 tenants have Security Defaults enabled by default, which blocks basic/legacy authentication — including SMTP AUTH with app passwords — across the whole tenant. Even after disabling Security Defaults and enabling per-mailbox SMTP AUTH, the propagation delay and Microsoft’s ongoing deprecation of basic auth makes this an unreliable path. OAuth 2.0 is the right solution.
What you’ll need
- A WordPress site
- A Microsoft 365 account with a licensed mailbox
- An admin account on the Microsoft 365 tenant (Global Administrator role)
- Access to the Microsoft Entra admin centre
In my case the business had a licensed user mailbox for day-to-day email and a shared mailbox for general enquiries (e.g. [email protected]). The goal was to send WordPress emails from the shared mailbox. More on how that works below.
Step 1 — Install FluentSMTP
FluentSMTP is a free, open-source WordPress plugin that supports Microsoft 365 OAuth 2.0 at no cost — unlike WP Mail SMTP and Post SMTP, which gate the Microsoft 365 OAuth option behind a paid plan.
Install it from the WordPress plugin directory:
- Go to Plugins → Add New
- Search for FluentSMTP
- Install and activate
- Go to Settings → FluentSMTP
- Select Microsoft as your email provider
Before doing anything else, copy the App Callback URL shown on the settings page — you’ll need it in the next step. Leave this tab open.
Step 2 — Register an app in Microsoft Entra
FluentSMTP authenticates via an Azure app registration. You need to create one in the Microsoft Entra admin centre.
- Go to entra.microsoft.com and sign in with your admin account
- Navigate to Identity → Applications → App registrations
- Click + New registration
- Fill in the form:
- Name: anything descriptive, e.g.
WordPress Mail - Supported account types: select “Accounts in any organizational directory (Any Azure AD directory – Multitenant) and personal Microsoft accounts” — this is required by FluentSMTP
- Redirect URI: set the dropdown to Web and paste the App Callback URL from FluentSMTP
- Name: anything descriptive, e.g.
- Click Register
- On the overview page, copy the Application (client) ID
⚠️ Pitfall: wrong account type
If you select single-tenant instead of multitenant, the OAuth redirect will fail with AADSTS50194: Application is not configured as a multi-tenant application and the access token box in FluentSMTP will come back empty. If this happens, go to Authentication in your app registration and change the supported account types, then try again.
Step 3 — Create a client secret
- In your app registration, click Certificates & secrets in the left sidebar
- Click + New client secret
- Give it a description and set expiry to 24 months
- Click Add
- Copy the Value immediately — it is only shown once and will be masked on your next visit
⚠️ Pitfall: secret expiry
The client secret will expire after 24 months and WordPress emails will silently stop sending. Set a calendar reminder for around 22 months from now to come back and renew it under Certificates & secrets.
Step 4 — Add API permissions
The app needs explicit Microsoft Graph permissions to send mail.
- In your app registration, click API permissions
- Click + Add a permission → Microsoft Graph → Delegated permissions
- Search for and tick each of the following:
Mail.SendMail.Send.Shared(needed if sending from a shared mailbox)offline_access(needed for token refresh)
- Click Add permissions
- Click Grant admin consent for [your organisation] and confirm
All permissions should show a green Granted status in the configured permissions list.
Step 5 — Configure FluentSMTP and authenticate
- Go back to Settings → FluentSMTP in WordPress
- Fill in:
- Sender Name: your business name
- Sender Email: the address emails should come from
- Application Client ID: the Application ID from Step 2
- Application Client Secret: the Value from Step 3
- Click Authenticate with Office 365 & Get Access Token
A Microsoft login popup will appear. A few important things here:
- Sign in with an account that has Global Administrator rights on the tenant
- On the consent screen, tick “Consent on behalf of your organization” before clicking Accept — if you skip this, other users on the tenant won’t be covered
- Make sure you are doing this in the same browser profile that is logged into Entra — if WordPress is open in one profile and Entra in another, it will authenticate the wrong account
After accepting, you’ll be redirected back to a page showing your access token. Copy it, paste it into the Access Token field in FluentSMTP, and click Save Connection Settings.
A note on shared mailboxes
If you want WordPress to send from a shared mailbox (e.g. [email protected]) rather than a licensed user mailbox, this is fully supported — but the OAuth authentication still happens via a licensed user account. You cannot authenticate directly as a shared mailbox since it has no password or OAuth credentials of its own.
The correct approach is:
- Authenticate as: the licensed user account (e.g.
[email protected]) - Sender Email in FluentSMTP: the shared mailbox address (e.g.
[email protected])
Microsoft 365 will honour the shared mailbox as the from address as long as the licensed user has Send As permissions on the shared mailbox. You can verify this in the Microsoft 365 admin centre under Teams & groups → Shared mailboxes → [your mailbox] → Send As permissions. This is also why you need Mail.Send.Shared in your API permissions.
Step 6 — Test it
- Go to the Email Test tab in FluentSMTP
- Set From to your sender address
- Set Send To to an address you can check
- Click Send Test Email
If it goes through, you’re done. FluentSMTP hooks into WordPress’s core wp_mail() function, which means every plugin that sends email through WordPress — WPForms, WooCommerce, comment notifications, password resets — will automatically use this setup without any additional configuration.
Troubleshooting summary
| Error | Cause | Fix |
|---|---|---|
535 5.7.139 Authentication unsuccessful, user is locked by your organization's security defaults policy | Security Defaults enabled on tenant | Disable Security Defaults in Entra under Identity → Overview → Properties |
AADSTS50194 — empty access token box | App registered as single-tenant | Change supported account types to Multitenant in Authentication settings |
| Need admin approval screen | User account is not a Global Admin | Click “Have an admin account?” and sign in with an admin account |
| Not Found on test email | Missing API permissions | Add Mail.Send, Mail.Send.Shared, offline_access and grant admin consent |
| Forbidden on test email | Wrong account authenticated or consent not granted for organisation | Re-authenticate, ensure same browser profile, tick “Consent on behalf of your organization” |
Once it’s working, WordPress email is one less thing to worry about. The OAuth token refreshes automatically via the offline_access permission — the only maintenance required is renewing the client secret every 24 months.
