nanoPost

The WordPress Email Authority

WP Mail SMTP + Microsoft 365: migrating off password authentication

Last reviewed/updated:

The WordPress site was sending mail through Office 365 fine last month. Now the contact-form notifications aren’t arriving, the debug log is carrying 550 5.7.30 Basic authentication is not supported for Client Submission, or a support forum thread has warned that the site’s Office 365 connection is about to stop working.

Microsoft is switching off SMTP AUTH Basic Authentication for Exchange Online. On existing tenants it becomes disabled by default at the end of December 2026; on new tenants the login method is already unavailable. Sites that hand mail to Office 365 with a mailbox address and a password sit on the affected path, and this page is for the specific version of that stack where WP Mail SMTP is doing the sending in its Other SMTP mailer mode against smtp.office365.com.

Two paths lead out. Move the WP Mail SMTP mailer from Other SMTP to its Microsoft 365 / Outlook mailer, so M365 stays as the sender over OAuth. Or reconfigure WP Mail SMTP to send through a transactional provider (Postmark, SMTP2GO, Mailgun, SendGrid) and leave M365 out of the outbound path. 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 to WP Mail SMTP’s Microsoft 365 / Outlook mailer M365 stays as the sender. WP Mail SMTP authenticates over OAuth. Pro licence required for custom-domain M365 mailboxes: $49 first year, $99 on renewal, one site. Plus tenant Global Admin consent. The M365 mailbox identity matters, and someone reachable has Global Admin on the tenant. Reseller-provisioned tenants (GoDaddy, IONOS, hosting-bundled M365) often lack this; take Path B instead.
B. Switch to a transactional provider Site sends via Postmark, SMTP2GO, Mailgun, or SendGrid. WP Mail SMTP’s free plugin ships native mailers for all four. Domain verification, SPF, DKIM, and (in most cases) sending from a subdomain rather than the M365 mailbox. Free or low-cost at the provider’s tier for typical WordPress volume. No route to Global Admin, no appetite for the Pro tier, or M365 was in the stack for expedience rather than sender identity.

Path A: the Microsoft 365 / Outlook mailer in WP Mail SMTP

The Microsoft 365 / Outlook mailer for custom-domain M365 mailboxes is a Pro-only feature in WP Mail SMTP. The free plugin’s Microsoft mailer supports consumer @outlook.com and @hotmail.com accounts only, not tenant mailboxes on a custom domain. WP Mail SMTP Pro is $49 for the first year and $99 on renewal for the one-site tier (wpmailsmtp.com/pricing/, verified 2026-08-02).

  1. Upgrade to WP Mail SMTP Pro. Install the Pro archive over the free plugin from WP Mail SMTP → Settings → General → Upgrade to Pro; existing settings carry over.

  2. Pick a setup method. WP Mail SMTP’s Microsoft 365 / Outlook mailer offers two flows, documented at wpmailsmtp.com/docs/how-to-set-up-the-outlook-mailer-in-wp-mail-smtp:

    • One-Click Setup uses a Microsoft-published app registration that WP Mail SMTP owns. The operator never touches the Microsoft Entra admin center; the flow signs into the M365 mailbox, consents to the WP Mail SMTP app, and returns to the plugin with a stored token. Fastest path, and the material differentiator between WP Mail SMTP Pro and every other mailer plugin in this category; FluentSMTP has no equivalent.
    • Manual setup has the operator create their own Entra app registration, generate an Application (client) ID and a Client Secret, and paste both into the plugin. Only matters when the tenant policy blocks third-party publishers, or when GCC/DoD compliance requires the customer-owned app path.

  3. Grant admin consent: the gotcha. Both flows still require a tenant Global Admin to grant admin consent to whichever app is being authorised. On a reseller-provisioned M365 tenant (GoDaddy, IONOS, hosting-bundled M365 add-ons), the site owner often does not have the Global Admin role. If the Microsoft consent screen returns “Need admin approval” or the plugin surfaces AADSTS65001: The user or administrator has not consented to use the application, the consent request routes to whoever owns the tenant, often the reseller’s support desk. If that path is not reachable, Path B is the faster resolution; there is no way to complete Path A without the consent step.

  4. Save the connection and send a test email. WP Mail SMTP → Tools → Email Test sends to any address; use an inbox on a different domain (a Gmail account works fine; testing to another mailbox in the same tenant can pass even when external delivery is broken). A successful send returns without the 5.7.30 string.

  5. Clear the debug log and monitor for 24 hours. WP Mail SMTP → Tools → Email Log (Pro-only) records every send attempt. Any subsequent 5.7.30 is a regression; the two most common causes at this stage are a caching layer holding stale mailer settings until PHP-FPM cycles, and a second SMTP configuration elsewhere in the codebase (a wp-config.php block, a legacy mu-plugin) still forcing the Other SMTP path.

Path B: a transactional provider

WP Mail SMTP’s free plugin ships native mailers for Postmark, SMTP2GO, Mailgun, and SendGrid (alongside SendLayer, Brevo, Elastic Email, ZeptoMail, and others). No Pro upgrade for this path.

  1. Pick the provider. Four sit in most nanoPost readers’ consideration set for this migration. Postmark has the highest reputation for transactional-only mail, with a permanent free developer plan at 100 emails/month (no expiry, no credit card) and paid tiers from $15/month. SMTP2GO allows 1,000 emails per month permanently and fits mixed transactional and light-marketing traffic in the same relay. Mailgun allows 100 emails per day permanently and is sensible when other Mailgun infrastructure is already in the stack. SendGrid allows 100 emails per day for the first 60 days and then charges from $19.95/month; broadest name-recognition of the four. The free SMTP servers 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. Reconfigure WP Mail SMTP. Settings → General → Mailer → pick the provider. Paste the API key or SMTP credentials from the provider dashboard. Set the From Email to an address on the verified sending domain. Save.

  4. Test and monitor. WP Mail SMTP → Tools → Email Test to an address on a different domain. Watch WP Mail SMTP’s Email Log (Pro-only; the free version shows recent sends in Tools → Debug Events) for 24 hours.

  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; if a caching plugin or a stale admin session does revert the plugin settings, the revoked credential ensures the failure is immediate and visible rather than silent.

Cached mailer settings: the common regression

On both paths, the most common post-migration failure is a caching plugin (or a PHP-FPM opcode cache) serving a stale admin session that re-saves the old Other SMTP values after the switch. Signs: everything tests clean immediately after the change, then the site reverts to 5.7.30 errors 15–60 minutes later. Fix: purge all caches after saving the new mailer settings, then send a second test email 30 minutes later before calling it done. A second SMTP configuration hardcoded in wp-config.php or a mu-plugin can cause the same regression independently of caching.

Which path when

Reseller-provisioned M365 tenants are Path B by default. The Global Admin consent requirement in Path A routes through the reseller’s support desk, which is not a controllable dependency for a same-day migration.

Take Path A when the M365 mailbox identity 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 requires someone reachable with tenant Global Admin. WP Mail SMTP Pro at $49 first year and $99 on renewal is cheaper than the ongoing cost of a paid provider tier at any meaningful volume; the friction is the OAuth consent step, not the licence fee.

Take Path B when any Path A prerequisite is a no: no route to Global Admin, no budget for the Pro tier, or no reason M365 has to stay as the visible sender. Transactional providers deliver contact-form notifications and order receipts more reliably than a repurposed mailbox does and cost nothing (or very little) at WordPress-transactional volume.

When neither path fits

The site owner who wants M365 as the sender identity but cannot reach a Global Admin 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.

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