Microsoft 365 is not a A transactional email is the automated message a WordPress site sends in response to a single user action – a password reset, an order confirmation, a form receipt – addressed to the user who triggered it. Read full reference → service. It is a productivity and business-mail platform whose Exchange Online mailboxes happen to expose SMTP, and WordPress mailer plugins can use that endpoint to relay site notifications. For a site that already pays for a licensed M365 mailbox under its own domain, this works inside narrow limits. For anything beyond those limits, a purpose-built relay like SMTP2GO or Postmark costs less per message, lifts the per-mailbox sending caps, and provides delivery reporting that Exchange Online does not.
What separates the M365 case from the Gmail one is a published expiration date. Microsoft is removing SMTP AUTH Basic Authentication from Exchange Online on a schedule: default-off on existing tenants from the end of December 2026, unavailable on tenants created after that point, with the final removal date to be announced in the second half of 2027. A WordPress site standing up M365 as its SMTP relay in 2026 is configuring something that, on the SMTP AUTH path, has at most twelve months before it needs explicit re-enablement, and an unannounced number of months after that before it stops working. The path that survives is OAuth via a Microsoft Entra app registration. Anyone choosing M365 for WordPress in 2026 is, in practice, choosing OAuth.
SMTP settings
| Setting | Value |
|---|---|
| Host | smtp.office365.com |
| Port | 587 (STARTTLS) |
| Encryption | TLS required |
| Authentication | OAuth (recommended) or SMTP AUTH with the mailbox username and password |
| Username | Mailbox UPN (typically [email protected] for a custom-domain tenant) |
Port 25 on smtp.office365.com is reserved for the SMTP relay product (connector-based, anonymous, for application servers and multifunction devices), not for authenticated client submission. Port 465 is not documented as a supported endpoint for M365 client submission. WordPress mailer plugins should target 587 with STARTTLS.
Authentication: OAuth and the SMTP AUTH cutoff
Exchange Online supports two authentication paths for SMTP client submission. They are not equivalent choices in 2026; Microsoft’s published timeline has already resolved the decision.
OAuth (recommended): the mailer plugin authenticates via a Microsoft Entra app registration with delegated permission to send mail (Mail.Send on Microsoft Graph for plugins that send via Graph, or https://outlook.office.com/SMTP.Send for plugins that submit via SMTP with OAuth). An admin registers the app once, grants tenant consent, generates a client secret, and pastes the application ID and secret value into the plugin’s M365 connection screen. The client secret has a Microsoft-enforced maximum lifetime of 24 months, after which the connection silently stops sending; a calendar reminder set at secret-creation time is the practical fix.
SMTP AUTH (legacy, expires December 2026): the mailer plugin authenticates with the mailbox UPN and the account password. Microsoft is removing this path on a published schedule:
- End of December 2026: SMTP AUTH Basic Authentication is default-off on existing tenants. Admins can re-enable it per-tenant or per-mailbox until further notice, but the default flips.
- December 2026 onward (new tenants): tenants created from this date ship with SMTP AUTH Basic Authentication unavailable. OAuth is the only supported authentication for SMTP submission on those tenants.
- Second half of 2027: Microsoft announces the final removal date. After the announced date, even the admin-enabled escape hatch closes.
SMTP AUTH is also blocked before the deprecation fires in two common cases. Tenants with Security Defaults enabled (the default for tenants created since October 2019) have SMTP AUTH disabled at the tenant level today. Tenants with a Conditional Access policy that blocks legacy authentication have it blocked regardless of the per-mailbox setting. Both override Set-CASMailbox -SmtpClientAuthenticationDisabled $false, which is the per-mailbox enable WordPress plugin docs typically point at. The most common “I configured SMTP AUTH per the plugin docs and it still won’t send” failure is one of these policies overriding the per-mailbox setting.
Microsoft’s app passwords are not the equivalent of Gmail App Passwords. They are a legacy-MFA bypass for accounts that do not support modern authentication, only available when explicitly enabled at the tenant level, and they do not work for accounts that are required to use modern auth (which is most accounts in any reasonably configured tenant). 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.
For the full WordPress-side setup, see WordPress SMTP with Microsoft 365.
DNS and email authentication
A WordPress site sending through M365 from its own domain publishes three DNS records to align SPF, DKIM, and DMARC against that domain.
- SPF: add
include:spf.protection.outlook.comto the domain’s TXT record. If the domain already has an SPF record with other senders, merge the include rather than publishing a second SPF record. - DKIM: in the Defender or Exchange admin centre, generate the two domain keys for the custom domain, publish the two provided CNAME records at
selector1._domainkey.yourdomain.comandselector2._domainkey.yourdomain.com, then toggle DKIM to Enabled in the admin centre. The two-step (publish CNAMEs first, then enable in the portal) catches operators who toggle before DNS has propagated. - DMARC: publish a starter policy at
_dmarc.yourdomain.com, typicallyv=DMARC1; p=none; rua=mailto:[email protected], and tighten toquarantineorrejectonce aggregate reports confirm SPF and DKIM are aligned.
A tenant that has not enabled custom-domain DKIM signs outbound mail with the default onmicrosoft.com selectors. DMARC alignment against the tenant’s custom domain fails in that configuration, which receivers interpret as an unauthenticated message from yourdomain.com. Custom DKIM is not optional for a WordPress site sending from its own domain through M365.
The mechanism behind SPF, DKIM, and DMARC is covered in DNS for WordPress email; this section covers the M365-specific alignment only.
Sending limits
Exchange Online enforces per-mailbox sending limits and a tenant-level external-recipient cap. Both apply to outbound mail from a WordPress site over SMTP AUTH or OAuth.
| Limit | Value | Window |
|---|---|---|
| Recipient rate (per mailbox) | 10,000 recipients per day | 24-hour rolling |
| Message rate (per mailbox) | 30 messages per minute | per-minute throttle |
| Tenant External Recipient Rate (TERRL) | scales with licence count; 5,000/day on trial tenants | 24-hour sliding |
onmicrosoft.com outbound throttle |
100 external recipients per organisation per day | 24-hour rolling |
The per-mailbox cap counts recipients, not messages: a WooCommerce site that emails 200 customers in a campaign consumes 200 of the 10,000. The 24-hour window is rolling from each message that crossed the limit, not a midnight reset; a mailbox that hits the cap at 09:00 on Tuesday is unblocked when the 09:00 Tuesday messages roll off at 09:00 Wednesday.
TERRL is the limit a WordPress site usually trips first. The per-mailbox 10,000-recipients-per-day cap is generous for a single store; TERRL is set at the tenant level and depends on licence count, and a busy site sending to customers on external domains exhausts the tenant’s external allowance before any single mailbox hits its own ceiling. The limit appears in the Exchange admin centre under Mail flow > Reports > Tenant Outbound External Recipients. Trial tenants are capped at 5,000 external recipients per day regardless of activity.
Hitting either limit returns NDRs the WordPress site never surfaces by default. 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, covering the 100-recipients-per-day throttle on *.onmicrosoft.com sending rather than custom-domain TERRL. SMTP AUTH submission from an identity other than the authenticated mailbox returns 550 5.7.60 SMTP; Client does not have permissions to send as this sender. Exchange Online does not rewrite the From address the way Gmail can, so configuring WordPress to send from [email protected] while authenticating as [email protected] is rejected unless explicit Send As permission has been granted on the mailbox.
For context: Postmark’s Basic plan at $15/month covers 10,000 emails with delivery webhooks, log retention, and no per-minute throttle. Exchange Online’s 30-message-per-minute rate is fine for a contact form and password resets; it is not fine for a WooCommerce flash sale that fires 200 order confirmations in 90 seconds.
Pricing
Exchange Online SMTP capacity is not sold as a separate product. It comes with a licensed M365 mailbox. Current annual-commit pricing for the plans that include Exchange Online:
| Plan | Monthly cost (annual commit) | What’s included |
|---|---|---|
| Business Basic | $6.00/user | Exchange mailbox, web/mobile Office apps, Teams, OneDrive |
| Business Standard | $12.50/user | Business Basic plus desktop Office apps |
| Business Basic (no Teams) | $4.40/user | Business Basic without Teams (EU regulatory unbundle) |
| Business Standard (no Teams) | $9.29/user | Business Standard without Teams |
Month-to-month billing adds roughly 20% on each tier. Exchange Online Plan 1 ($4.00/user/month) is the mailbox-only SKU for organisations that want Exchange without the rest of the suite.
A WordPress site that already pays for a M365 mailbox treats SMTP as a free byproduct of the licence. A WordPress site that does not is paying $4-$6 per user per month for an SMTP endpoint with a 10,000-recipient daily cap, no webhooks, no log retention beyond message trace, and a SMTP AUTH path that expires in December 2026. By comparison, SMTP2GO’s $10/month Starter plan sends 10,000 emails with delivery logs and webhooks, and does not require a productivity-suite licence.
WordPress integration
M365 works with any WordPress mailer plugin that supports SMTP submission with OAuth or, until December 2026, SMTP AUTH with mailbox credentials.
| Plugin | M365 OAuth support | Notes |
|---|---|---|
| WP Mail SMTP | Yes (Outlook mailer) | Free version supports only Microsoft consumer accounts; Pro is required for custom-domain M365 mailboxes |
| FluentSMTP | Yes | Free; includes the Microsoft 365 OAuth flow against Microsoft Graph |
| Post SMTP | Yes | Submits via Microsoft Graph rather than SMTP; sidesteps the SMTP AUTH deprecation entirely |
Each plugin’s setup walks the Azure app registration at the click-by-click level. The pieces a WordPress operator pastes into the plugin connection screen are the same across all three: the application (client) ID and the client secret value (copied at creation time, since Azure does not show the secret again afterwards). Plugins that send via Microsoft Graph use the Mail.Send delegated permission; plugins that submit via SMTP with OAuth use the Exchange https://outlook.office.com/SMTP.Send scope.
For setup, see WordPress SMTP with Microsoft 365.
Limitations
Features standard in purpose-built transactional services that M365 either lacks or does not surface for WordPress use:
- Delivery webhooks: no programmatic notification when email bounces, is opened, or links are clicked. Exchange Online message trace is searchable in the admin centre for 90 days; it is not a webhook stream WordPress can consume.
- Per-message delivery status: message trace shows delivered, deferred, or failed at the Exchange Online layer. It does not report inbox placement or third-party spam filtering downstream.
- Dedicated IP: M365 sends from Microsoft’s shared IP pools. A site cannot build or protect its own sender reputation.
- Bounce handling: bounces return to the sending mailbox. No webhook, no suppression list, no automatic unsubscribe management.
- Volume burst capacity: 30 messages per minute is a hard rate limit. A WooCommerce store that generates 200 order confirmations in a minute throttles and retries; emails arrive eventually, but the burst spreads over several minutes.
- Send-as flexibility: Exchange Online rejects SMTP submission from a From address that does not match the authenticated mailbox (without explicit Send As permission). WordPress sites that want a
noreply@From address have to either authenticate asnoreply@or grant Send As onnoreply@to the authenticating mailbox. - SMTP AUTH durability: the credential-based path expires on a published schedule. OAuth is the only path that survives, and OAuth client secrets expire every 24 months and require rotation.
Verdict
Microsoft 365 is appropriate when the site already pays for a licensed M365 mailbox under its own domain, sends fewer than a few hundred emails per day from that mailbox, can spare an admin afternoon to register an Azure app for OAuth, and has no requirement for bounce webhooks, delivery logs, or dedicated sending reputation. WooCommerce confirmations on a low-volume store, contact form notifications, password resets: these work over M365 OAuth without issue, and the cost is already on the operator’s bill.
Microsoft 365 is not appropriate when the site does not already use M365 (paying for the licence to get SMTP is bad arithmetic), needs delivery reporting, sends marketing email, processes high-volume WooCommerce orders, or wants the SMTP path to outlive the December 2026 SMTP AUTH cutoff without an OAuth rebuild. The correct answer at that point is a transactional relay: SMTP2GO for simplicity, Postmark for deliverability focus, Amazon SES for cost at volume, or Brevo when marketing email shares the domain.
The most common failure mode with M365 as a WordPress SMTP relay is not the limits but the silent expiration cliffs: the OAuth client secret reaches its 24-month maximum and the connection stops sending without a plugin-side warning; the SMTP AUTH default-off in December 2026 flips a working configuration into a non-working one overnight; a Conditional Access policy added by an IT admin for an unrelated reason blocks legacy auth tenant-wide. A logging plugin like Check & Log Email catches the first two; the third is a coordination problem with whoever owns the M365 tenant.
For the broader setup that places M365 inside the WordPress email stack, see the WordPress email setup guide.