nanoPost

The WordPress Email Authority

WordPress SMTP with Microsoft 365

Last reviewed/updated:

Use Microsoft 365 (formerly Office 365) as the SMTP server for a WordPress site when the site sends a small, predictable volume of operational mail (password resets, contact-form notifications, order receipts) on behalf of a real licensed M365 mailbox the operator already pays for. The fit is a site sending well under 10,000 recipients a day, fewer than 30 messages a minute, where every message goes out as a single mailbox identity ([email protected]) and where nobody needs delivery webhooks or per-recipient suppression. Adding a Microsoft 365 licence purely to acquire an SMTP endpoint is bad arithmetic; the path is for sites that already pay for the mailbox.

The Microsoft 365 SMTP AUTH path has a published expiration date that shapes the setup decision. SMTP AUTH Basic Authentication is default-off on existing tenants from the end of December 2026, unavailable on tenants created from that point, with the final removal date to be announced in the second half of 2027. The path that survives the cutoff is OAuth via a Microsoft Entra app registration. Anyone setting M365 up as a WordPress relay in 2026 is choosing OAuth; the SMTP AUTH path covered below is here for operators who cannot register an Azure app today and who will rebuild before December 2026.

If the site doesn’t fit, the catalog of dedicated providers is at SMTP services for WordPress and a four-name shortlist sits at the bottom of this page. The companion guide for Google Workspace is at WordPress SMTP with Google Workspace.

When this is the right approach

Microsoft 365 is a mailbox system being repurposed as a transactional sender, and the SMTP AUTH path closes by end of 2026 either way.

  • Volume well under the per-mailbox 10,000-recipients-per-day cap and the 30-messages-per-minute rate, with headroom for a seasonal surge.
  • A single licensed M365 mailbox the site is acting on behalf of, owned by the operator.
  • Either the ability to register an Azure app today (OAuth) or the willingness to rebuild on OAuth before the SMTP AUTH default-off in December 2026.
  • No requirement to keep transactional and broadcast reputations separate. A same-domain newsletter sent from the same mailbox will eventually pull the transactional reputation down with it.
  • No need for bounce webhooks, per-message delivery logs, or per-recipient suppression. Exchange Online’s message trace is 90 days, admin-centre only, and not a webhook stream.

When any of these flip, the right move is a dedicated transactional provider; the off-ramp section names the shortlist.

Choosing a mailer plugin

Three mailer plugins handle Microsoft 365, and the deprecation-survival shape of each is the operator-facing decision. FluentSMTP and Post SMTP both submit via Microsoft Graph (the Mail.Send delegated permission) and sidestep the SMTP AUTH deprecation entirely; FluentSMTP groups the flow under “Outlook / Microsoft 365” in its free version, and Post SMTP carries the same Graph submission path. WP Mail SMTP‘s Outlook mailer (for both @outlook.com consumer accounts and custom-domain M365 mailboxes) is gated behind the Pro tier; the free version doesn’t ship that mailer at all. Operators sending from a custom-domain M365 mailbox who want to stay on free-tier plugins use FluentSMTP or Post SMTP. The plugin-by-plugin trade-offs live in best WordPress SMTP plugins.

Setting up OAuth (recommended)

OAuth is the only path that survives the SMTP AUTH cutoff, and the right default whenever an admin can register an Azure app on the tenant. The Microsoft Entra side is the same regardless of which mailer plugin holds the credential. Plugin docs carry the click-by-click; the structure is:

  1. Register the app. Microsoft Entra admin centre → App registrations → New registration. Set supported accounts to “Accounts in this organisational directory only” (single tenant). Paste the redirect URI from the plugin’s connection screen.
  2. Grant the permission. API permissions → Add → Microsoft Graph → Delegated → Mail.Send. Click “Grant admin consent for [tenant]”. Without it, authorisation returns AADSTS65001 on first connect (Microsoft Entra’s error for consent missing on the requested scope).
  3. Create the client secret. Certificates & secrets → New client secret. Azure caps lifetime at 24 months. Copy the secret value immediately; Azure shows it only once. The “Secret ID” is not the secret.
  4. Paste into the plugin. Paste Application (client) ID and the client secret value into the M365 connection screen, run the browser authorisation round-trip, then run the plugin’s Connection Test before relying on the path for live mail.

Two scopes, two submission paths. Plugins that send via Microsoft Graph use the Mail.Send delegated permission and never touch SMTP AUTH; FluentSMTP and Post SMTP work this way, and the SMTP AUTH default-off in December 2026 does not affect them. Plugins that submit via SMTP with OAuth use the Exchange https://outlook.office.com/SMTP.Send scope; the SMTP AUTH default-off does affect this path because the underlying transport is still SMTP submission. Operators don’t usually choose between the two; the plugin’s documented setup picks one. Tenants on FluentSMTP or Post SMTP are structurally outside the December 2026 cutoff regardless of admin action.

WP Mail SMTP Pro’s Outlook mailer requests the broader Graph Mail.ReadWrite scope; the plugin’s docs say this is to lift the 3MB attachment-size cap that Mail.Send alone imposes. For a tenant-dedicated app registration the broader scope is appropriate; for a multi-purpose app registration, prefer FluentSMTP’s Mail.Send-only flow.

The 24-month client secret expiry. When the client secret expires, Exchange Online stops accepting OAuth-fronted submissions and WordPress mail fails silently: no free-tier plugin warning fires, and the rejection does not name secret expiry. The fix is a calendar reminder at secret-creation time and a brief rotation procedure (create a new secret, paste the value into the plugin, retire the old secret once Connection Test passes against the new one).

Setting up SMTP AUTH (legacy, expires December 2026)

SMTP AUTH is here for operators stuck without Azure app-registration rights today (rare in 2026 but real for tenants under a third-party IT admin). The path works through end-of-2026; the timeline section below covers what happens after.

Setting Value
Host smtp.office365.com
Port 587 (STARTTLS)
Encryption TLS required
Authentication Mailbox UPN and account password
Username Mailbox UPN ([email protected])

Port 25 on smtp.office365.com is reserved for the M365 SMTP relay (connector-based, not client submission). Port 465 is not a supported endpoint.

Tenants with Security Defaults enabled (the default for tenants created since October 22, 2019) have SMTP AUTH disabled tenant-wide. A global admin re-enables it tenant-wide and per-mailbox:

Set-TransportConfig -SmtpClientAuthenticationDisabled $false
Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false

If Set-CASMailbox reports the mailbox is enabled but submissions still return 535 5.7.139, the next-most-likely cause is a Conditional Access policy blocking legacy authentication (Microsoft Entra admin centre → Conditional Access → Policies; look for any policy whose Client apps condition includes “Other clients”). A Conditional Access policy overrides both the tenant and the per-mailbox enable. The fix is either a CA-policy exclusion for the WordPress-authenticating mailbox or a move to OAuth. Microsoft 365 app passwords are not the answer either; the silent-failures section names the trap.

The SMTP AUTH deprecation timeline

Microsoft published the current timeline on January 27, 2026 (Exchange Team blog). Three milestones matter to a WordPress operator:

Date What happens Operator implication
End of December 2026 SMTP AUTH Basic Authentication default-off on existing tenants Configurations working on December 30 stop on December 31 unless an admin has explicitly re-enabled
December 2026 onward (new tenants) SMTP AUTH Basic Authentication unavailable on tenants created from this date A WordPress site moving to a freshly created tenant in 2027 has no SMTP AUTH option, even temporarily
Second half of 2027 Microsoft announces the final removal date After the announced date, the admin-enabled escape hatch closes on existing tenants. Microsoft has not committed to how much notice the announcement carries

The timeline has been revised twice already. The original 2022 retirement post pointed at early 2026; a subsequent update pushed the dates; the January 2026 post is the current schedule. Operators who rebuilt early on the prior schedule did the right thing; the operators still on SMTP AUTH today are inside the final migration window. The honest read is that this is not the schedule shifting again, it is the runway closing.

The practical response: pick a date in 2026, set the calendar reminder, run the OAuth setup walkthrough above on that date, retire the SMTP AUTH credentials, move on. A site that delays into Q4 2026 will be doing the rebuild under deadline pressure alongside every other M365 SMTP AUTH operator hitting the same cutoff.

DNS alignment

Microsoft 365 sends mail regardless of DNS state. Whether that mail aligns to the sending domain (and survives a moderately strict DMARC policy at the receiver) depends on three records. The general SPF / DKIM / DMARC mechanism is in DNS setup for WordPress email; the M365 specifics are below.

SPF. Add include:spf.protection.outlook.com to the domain’s TXT SPF record. Multiple SPF records on the same domain invalidate all of them; merge into a single record. The record looks like v=spf1 include:spf.protection.outlook.com -all for an M365-only setup.

DKIM. DKIM is the alignment record M365 most often gets wrong on first setup, because the configuration is two steps in two places. In the Defender admin centre (Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM), generate the two domain keys for the custom domain. Microsoft provides two CNAME values; publish them at selector1._domainkey.yourdomain.com and selector2._domainkey.yourdomain.com. The CNAME targets are Microsoft-controlled hosts under the tenant’s onmicrosoft.com zone; the key material itself stays on Microsoft’s side, unlike Workspace’s TXT-published key. Then return to the admin centre and toggle DKIM signing to Enabled for the domain. Until that final toggle, the tenant signs outbound mail with its onmicrosoft.com selectors and DMARC alignment against the custom domain fails. The send succeeds; the alignment doesn’t.

DMARC. A starting DMARC policy of v=DMARC1; p=none; rua=mailto:[email protected] at _dmarc.yourdomain.com will deliver aggregate reports without quarantining mail. Tightening to p=quarantine or p=reject is appropriate after a few weeks of clean reports.

Microsoft 365 does not rewrite the From address when the authenticated mailbox and the From header disagree. It rejects, which means a Workspace-shaped configuration carried across to M365 will break loudly rather than silently. The silent-failures section names the rejection code.

A sibling product is worth knowing exists: the Microsoft 365 SMTP relay (connector-based, IP allowlist or certificate, port 25) is the path for application servers and multi-site agencies, and Direct Send (anonymous, internal recipients only) is the no-auth path. Both are out of scope here; Microsoft’s comparison sits at How to set up a multifunction device or application to send email using Microsoft 365 or Office 365.

Verifying the setup

The lightest end-to-end test is the WordPress password-reset flow on a test account.

  1. From a logged-out browser, visit /wp-login.php and click “Lost your password?”.
  2. Enter the test account’s email address. WordPress sends a reset email via the configured path.
  3. Confirm the message arrives within a minute or two, and check the headers for Received-SPF: pass, dkim=pass, and dmarc=pass.

Look at the DKIM signature specifically. If the header shows d=onmicrosoft.com rather than d=yourdomain.com, the Defender admin centre toggle never fired and alignment is silently failing even when dkim=pass. This is the M365 equivalent of Workspace’s d=gmail.com trap and the single most common DKIM-side misconfiguration; the fix is to return to the Defender admin centre and flip the DKIM signing toggle for the custom domain.

If the test fails, the SMTP error code points at the cause. 5.7.57 Client not authenticated to send mail means the submission lacks authentication entirely. 5.7.139 Authentication unsuccessful on credentials-correct setups means SMTP AUTH is disabled at the tenant level or blocked by Conditional Access. 5.7.60 Client does not have permissions to send as this sender means the From header names an identity the authenticated mailbox does not have Send As permission on. For deeper triage, see troubleshoot WordPress email and how to read an SMTP session log.

Limits, alignment, and silent failures

Five behaviours catch operators off guard, and none appear in the typical “configure WP Mail SMTP with Office 365” walkthrough.

The 10,000-recipient cap is rolling, with a 30-messages-per-minute throttle and TERRL behind it. Exchange Online caps per-mailbox sending at 10,000 recipients per 24-hour rolling window and 30 messages per minute. The recipient cap counts recipients, not messages: a WooCommerce campaign emailing 200 customers consumes 200 of the 10,000. The 24-hour window rolls forward from the message that crossed the limit, not at midnight. Behind the per-mailbox cap sits the Tenant External Recipient Rate Limit (TERRL), a tenant-wide cross-domain cap that scales with licence count (trial tenants capped at 5,000/day). A site whose audience is mostly external customers exhausts TERRL before any single mailbox hits its own ceiling; TERRL exhaustion returns 550 5.7.233 on a licensed tenant or 550 5.7.232 on a trial tenant. (The adjacent code 5.7.236 is unrelated: it’s the 100-external-recipients-per-day throttle on *.onmicrosoft.com sending, which a WordPress site sending from its own custom domain doesn’t normally trip.) Current TERRL usage appears in the Exchange admin centre under Mail flow → Reports → Tenant Outbound External Recipients.

Security Defaults and Conditional Access disable SMTP AUTH before the deprecation fires. Security Defaults (default since October 22, 2019) disable SMTP AUTH tenant-wide unless Set-TransportConfig re-enables it; a Conditional Access policy that blocks legacy authentication overrides both. The plugin sees 535 5.7.139 with correct credentials, operators conclude the credentials are wrong rather than checking the tenant-level policy, and the resolution that costs nothing is to move to OAuth.

Microsoft 365 app passwords are a trap, not the path. App passwords are a legacy bypass for per-user MFA on accounts that do not support modern authentication. They are tenant-admin-gated, they do not work for accounts required to use modern auth (most accounts in any reasonably configured tenant), and the Microsoft Entra documentation itself recommends pairing app-password disable with a CA policy that blocks legacy auth. The Workspace-shaped instruction to “generate an app password and use it as the SMTP password” is wrong advice for almost every M365 tenant in 2026; any guide carrying it is recycling Workspace advice without checking. The right answer is OAuth.

The OAuth client secret expires after 24 months, silently. Free-tier plugins do not warn before expiry; Exchange Online’s rejection does not name secret expiry. Mitigation lives in the OAuth setup section: calendar reminder at secret-creation time, documented rotation procedure.

Exchange Online rejects send-as identity mismatches. Where Workspace silently rewrites the From header when the authenticated mailbox is not authorised to send as the From identity, Exchange Online returns 550 5.7.60 Client does not have permissions to send as this sender and the message does not go out. Fix: authenticate as the From mailbox, or grant explicit Send As on the From mailbox to the authenticating mailbox (Exchange admin centre → Recipients → Mailboxes → select the mailbox → Mailbox Delegation → Send as). Carrying a Workspace-shaped noreply@-authenticates / support@-sends configuration across to M365 without the Send As is the most common WordPress-side cause of 5.7.60.

When to migrate to a transactional provider

The forcing function is the deprecation deadline: the operator is migrating before December 2026 either way, and the question is whether the migration lands on OAuth-on-M365 or off M365 entirely. The off-ramp signals are sharp:

  • The day’s send count regularly clears a few hundred. A WooCommerce store past a few hundred orders a day, or a membership site with regular automated touch points, is on the wrong tool. The per-mailbox cap looks roomy until TERRL bites first; the 30-per-minute throttle caps burst capacity well below what a flash sale produces.
  • The audience is mostly on external domains. Per-mailbox limits are sized for human correspondence; transactional sends pattern-match against rate-limiter heuristics, and TERRL caps cross-domain volume at the tenant level rather than the mailbox level.
  • Operations needs bounce webhooks, per-message delivery logs, or per-recipient suppression. Exchange Online’s 90-day message trace is admin-centre searchable; it is not a webhook stream a WordPress plugin can consume, and there is no built-in suppression list.
  • The site sends from identities that aren’t a real licensed mailbox. Interleaved noreply@, orders@, notifications@, and support@ sends are not an M365 use case; the Send As permissioning required to make every identity work is high-friction enough that the migration pays for itself.

The catalog of dedicated providers is at SMTP services for WordPress. Four are worth shortlisting:

  • Postmark is the right default for a site under 100,000 transactional messages a month, with bounce webhooks, per-message inspection, and a strict transactional-only posture that keeps reputation clean.
  • SMTP2GO covers transactional and lower-volume broadcast in one account, with a generous free tier and a predictable pricing curve.
  • Brevo (formerly Sendinblue) covers transactional and marketing in one account, with a daily-cap free tier that suits intermittent senders.
  • Amazon SES is the per-message-cheapest option once a site is comfortable with AWS console setup, sandbox-to-production approval, and managing its own bounce-handling.

References

The deprecation timeline:

OAuth and SMTP submission mechanics:

Limits and rejection codes:

App passwords and Conditional Access:

DNS authentication:

Mailer plugin OAuth setup:

Sibling nanoPost guides: