nanoPost

The WordPress Email Authority

FluentSMTP + Microsoft 365 OAuth: migrating off password authentication

Last reviewed/updated:

If your WordPress site sends its transactional email through Microsoft 365, and FluentSMTP is the plugin doing the sending with a mailbox and its password, that setup has a shelf life. Contact-form notifications, password resets, order receipts all go out that way. Microsoft is turning off the password sign-in that plugins use to hand mail to Exchange Online. On existing tenants the default flips off at the end of December 2026; on new tenants it is already unavailable.

When it does, FluentSMTP’s log will fill with:

550 5.7.30 Basic authentication is not supported for Client Submission

Two paths lead out. Switch FluentSMTP’s connection to the Microsoft 365 / Outlook OAuth type, so M365 stays as the sender. Or add a transactional provider as a new FluentSMTP connection, so mail leaves M365 entirely. The pillar hub carries the timeline and the routing for readers on a different plugin or a different M365 setup.

Your two paths

Path What changes What it costs When it’s right
A. Switch FluentSMTP to Microsoft 365 OAuth M365 stays as the sender. FluentSMTP submits over Graph instead of SMTP AUTH. An app registration you own in the tenant’s Microsoft Entra portal, plus tenant Global Admin consent. Free at the plugin level; FluentSMTP’s Outlook connection ships in the free plugin. The M365 mailbox identity matters to recipients, and someone reachable has Global Admin on the tenant.
B. Add a transactional-provider connection Site sends via Postmark, SMTP2GO, Mailgun, or SendGrid. FluentSMTP has a native mailer for each. Domain verification, SPF, DKIM, and (in most cases) sending from a subdomain rather than the M365 mailbox. No Entra access, no Global Admin, or M365 was in the stack for expedience rather than sender identity.

A third option (“do nothing”) is not on the table. The site stops sending; contact forms, password resets, and order receipts fail silently until fixed.

One difference between FluentSMTP and WP Mail SMTP Pro is worth naming before Path A begins. WPMS Pro’s One-Click Setup uses a Microsoft-published Entra application that the site operator never registers; the reader only signs in and consents. FluentSMTP has no equivalent. Every FluentSMTP installation that reaches the Microsoft 365 / Outlook connection needs its own Entra app registration in the customer’s tenant. That difference does not matter to a reader who has tenant Global Admin. It is disqualifying for a reader on a reseller-provisioned M365 tenant (GoDaddy, IONOS, a hosting-bundled add-on) who cannot reach the Entra admin center at all. Those readers go to Path B.

Path A: switch FluentSMTP to Microsoft 365 OAuth

Register an application in Microsoft Entra

  1. Sign in to the Microsoft Entra admin center as a tenant Global Admin, or as an account holding the Application Administrator role. If the URL returns “You don’t have permission” or the tenant selector shows only the reseller’s tenant, stop here and jump to Path B. A customer-owned app registration cannot be created without directory access, and FluentSMTP has no plugin-published fallback to reach.

  2. Navigate to Applications → App registrations → New registration. Give the app a name; FluentSMTP or WordPress mailer for <site> is fine, the name is internal to the tenant. For “Supported account types”, pick “Accounts in this organizational directory only” (single tenant) unless there is a specific multi-tenant reason not to. Set the Redirect URI type to Web and paste the URI FluentSMTP shows on its Microsoft 365 / Outlook connection screen (it looks like https://<site>/wp-admin/options-general.php?page=fluent-mail#/connections; copy the plugin’s rendered value rather than typing it). Click Register.

  3. Note the Application (client) ID and Directory (tenant) ID from the app’s Overview page. Both get pasted into FluentSMTP in the next section.

    [Screenshot: App registration Overview page showing Application (client) ID and Directory (tenant) ID fields]

  4. Add a client secret. Certificates & secrets → Client secrets → New client secret. Description FluentSMTP, expiry 24 months (the maximum; a shorter expiry means an earlier calendar reminder to rotate). Copy the Value column immediately.

    [Screenshot: Client secret Value field immediately after creation, before navigating away]

    Entra shows the secret in cleartext only on creation, and the Value column is what the plugin needs. The Secret ID next to it is a different string and will not authenticate. Paste the Value into a password manager entry named for the site before doing anything else.

  5. Add API permissions. API permissions → Add a permission → Microsoft Graph → Delegated permissions. Add these five: Mail.Send, Mail.ReadWrite, Mail.Send.Shared, User.Read, offline_access. These are the scopes FluentSMTP’s Outlook mailer requests, verified against the plugin’s own source. Click Grant admin consent for &lt;tenant&gt;.

    [Screenshot: API permissions list with the Grant admin consent button visible]

    The button is only enabled for tenant Global Admins. Without admin consent granted, the plugin returns AADSTS65001: The user or administrator has not consented to use the application (or similar) on the connection attempt.

Connect FluentSMTP to the app

  1. In WordPress, go to FluentSMTP → Settings → New Connection, and pick Microsoft 365 / Outlook as the connection type.

  2. Paste the Application (client) ID, Directory (tenant) ID, and Client Secret Value from the Entra portal. Set the From Email to the M365 mailbox address that will authorise the connection.

    [Screenshot: FluentSMTP Microsoft 365 / Outlook connection form filled out with the three ID/secret fields]

  3. Click Authorize your Microsoft account. The Microsoft consent screen appears; sign in as the mailbox owner, not the tenant admin. The mailbox owner grants delegated access to their own mailbox. Approve. FluentSMTP returns to the connection page with a stored token.

  4. Save the connection. If an “Other SMTP” connection to M365 is still configured, delete it now, or leave it as a routed fallback for a week before deleting.

Test and monitor

Use FluentSMTP → Email Test to send to an address on a different domain (a Gmail address works fine; testing to another mailbox in the same tenant loopbacks the delivery path and can pass even when external delivery is broken). A successful send returns without the 5.7.30 string.

Watch FluentSMTP → Email Log for 24 hours after the switch. Any subsequent 5.7.30 is a regression. The two most common causes at this stage are a caching plugin serving a stale FluentSMTP settings page to an admin session that then re-saves the old “Other SMTP” values, and the Secret ID / Value confusion at step 4 above.

Path B: add a transactional provider connection

FluentSMTP ships native mailers for Postmark, SMTP2GO, Mailgun, and SendGrid in the free plugin, alongside Brevo, Elastic Email, ZeptoMail, SparkPost, and others. The four named here are the shared set the pillar hub and the WP Mail SMTP spoke also route to.

  1. Pick the provider.

    • Postmark. The highest-reputation option for transactional-only mail. 100 emails per month free, permanently, then paid.
    • SMTP2GO. 1,000 emails per month free forever. Fits mixed transactional and light-marketing traffic.
    • Mailgun. 5,000 emails per month for the first three months, then paid. Sensible when other Mailgun infrastructure is already in the stack.
    • SendGrid. 100 emails per day for the first 60 days, then paid from $19.95/month. Broadest name-recognition.

    The best SMTP providers for WordPress roundup covers the free tiers at more length.

  2. Provision the domain. Sign up, verify the sending domain, publish the SPF and DKIM records the provider issues. The site’s From address usually shifts from the M365 mailbox to a subdomain (send.example.com or similar); sending from the M365 mailbox address itself is possible but breaks M365’s inbound reply routing unless the mailbox forwards those replies onward.

  3. Add the connection in FluentSMTP. Settings → New Connection, pick the provider, paste the API key or SMTP credentials from the provider dashboard, set the From Email, save.

  4. Route the traffic. Either delete the old “Other SMTP” M365 connection outright, or leave it in place as a routed fallback for a week while the new connection is monitored. FluentSMTP’s multi-connection routing lets both live at once, which is an ergonomic advantage over WPMS’s single-mailer model for this migration.

  5. Retire the M365 SMTP AUTH configuration. In the mailbox owner’s account portal → Security → App passwords, revoke the app password the site was using. If tenant policy allows, an Exchange admin can also disable SMTP AUTH on the mailbox with Set-CASMailbox -Identity <[email protected]> -SmtpClientAuthenticationDisabled $true. Both steps are optional but tidy.

Which path when

Take Path A when the site’s identity as the M365 mailbox owner matters to recipients: invoices from [email protected], support replies from a mailbox humans also read, order confirmations that need to land in the mailbox’s own Sent items. Path A also assumes the operator has tenant Global Admin (or can reach someone who does) and access to the Entra admin center. FluentSMTP’s Outlook connection is free at the plugin level; the ongoing cost is the app registration the site now owns and the client secret that has to rotate before its 24-month expiry.

Take Path B when any Path A prerequisite is a no: no Entra access, no Global Admin, or no appetite for owning an app registration and a rotating secret indefinitely. Transactional providers deliver contact-form notifications and order receipts more reliably than a repurposed mailbox does, cost nothing at typical WordPress-transactional volume, and remove the tenant-admin coordination step. Reseller-provisioned M365 tenants are Path B by default.

For a site that pays for M365 anyway and has an in-house admin, Path A is the cleaner long-term answer; for everyone else, Path B removes the tenant-admin dependency entirely.

When neither path fits

The reader who wants M365 as the sender identity but cannot register an Entra app has one middle option: a paid transactional provider that supports the M365 mailbox address in the From: header, plus a mailbox-level forwarding rule to route replies. It costs more than either path above and adds a moving part; it is worth naming for the reader who has already ruled out both.

The reader with a WP Mail SMTP Pro licence already paid for is on the wrong spoke; WP Mail SMTP + Microsoft 365 migration is the right page, and WPMS Pro’s One-Click Setup skips the manual Entra registration this page walks.

If the site is actually on M365 SMTP relay via connector (port 25, source-IP allowlist) or on Direct Send, the SMTP AUTH retirement does not apply and this migration is the wrong one to run. Microsoft 365 SMTP relay and Direct Send is the right page.

Related