No. The retirement of Exchange Web Services does not affect WordPress sites that send email through Microsoft 365. The three WordPress mailer plugins that integrate with M365 all submit mail through SMTP or Microsoft Graph, and EWS retirement touches neither path. The Microsoft deprecation that did break WordPress sites talking to M365 is a different one: SMTP AUTH basic authentication, which has its own tenant-level default-off at the end of December 2026.
What EWS retires, and what WordPress mailers actually use
EWS is Exchange Web Services, a SOAP-over-HTTPS API (/EWS/Exchange.asmx) applications use to read mailboxes, manage calendar items, and run mail-flow operations against Exchange. It is a mail-reading and mailbox-management protocol. Microsoft’s retirement page sets October 2026 as the start of global EWS disablement and April 2027 as full removal (
Microsoft Learn, Deprecation of Exchange Web Services in Exchange Online). Scope is Microsoft 365 and Exchange Online; Exchange Server on-premises is not affected. The recommended replacement is Microsoft Graph.
WordPress mailer plugins submit outbound mail. EWS is not an outbound submission protocol. The three plugins that carry Microsoft 365 as a documented first-party connection all send via SMTP or Microsoft Graph:
| Plugin | M365 free-tier path | M365 Pro path | Transport | Uses EWS? |
|---|---|---|---|---|
| WP Mail SMTP | Other SMTP against smtp.office365.com |
Dedicated Outlook mailer (Pro only) | SMTP (free) / Microsoft Graph (Pro) | No |
| FluentSMTP | Native Outlook / Microsoft 365 provider | Same (same free provider) | Microsoft Graph (graph.microsoft.com/v1.0/me/sendMail, Mail.Send scope) |
No |
| Post SMTP | Other SMTP against smtp.office365.com (with mailbox credentials or XOAUTH2) |
Native Microsoft 365 socket (office365_api, Pro extension) |
SMTP (free) / Microsoft Graph (Pro) | No |
Every one of these paths survives October 2026 and April 2027 unchanged, because EWS retirement removes EWS, not SMTP submission and not Graph /sendMail.
The deprecation that does affect WordPress → M365: SMTP AUTH basic auth
The migration a WordPress operator sending through M365 in 2026 actually needs is off SMTP AUTH basic authentication (mailbox username and password) and onto OAuth via a Microsoft Entra app registration. The current Microsoft timeline leaves SMTP AUTH basic default-on through the end of December 2026 and default-off from that point for existing tenants, with the final removal date to be announced in the second half of 2027; tenants created after end of December 2026 ship without the Basic path at all. See Microsoft 365 as a WordPress SMTP Server for the full timeline reference.
The symptom when SMTP AUTH basic is off is 550 5.7.30 Basic authentication is not supported for Client Submission in the mailer plugin’s log. Security Defaults or a Conditional Access policy that blocks legacy authentication produces the same visible failure before December 2026 arrives, overriding the per-mailbox Set-CASMailbox -SmtpClientAuthenticationDisabled $false. The fix in each case is the same: switch the mailer to the M365 OAuth connection and register the Entra app. The per-plugin paths are FluentSMTP Microsoft 365 migration, WP Mail SMTP Microsoft 365 migration, and Post SMTP Microsoft 365 migration.
The one WordPress case where EWS retirement does matter
A small set of WordPress integrations do speak EWS: the ones that read a mailbox rather than send to it. The pattern (not any specific plugin unless its documentation confirms the dependency) covers bounce-handling plugins that watch a bounces@ mailbox for non-delivery reports and update a suppression list; helpdesk and support plugins that ingest tickets from a shared support@ mailbox; email-to-post plugins that create WordPress posts from messages sent to a dedicated address.
An integration in this category whose documentation still names EWS as its transport is on Microsoft’s October 2026 countdown and needs an update from its author to Microsoft Graph. A WordPress site that only sends through M365 (contact form notifications, password resets, WooCommerce order emails, admin alerts) owns none of this problem.
Three-step diagnosis
If a WordPress → M365 configuration behaves strangely in the current window and the headline that prompted the search was EWS retirement, three checks settle it:
- Is the plugin sending, or reading? Mailers that replace
wp_mail()use SMTP or Graph, not EWS. Reading plugins (bounce handlers, helpdesk ingest) might use EWS and are the only ones EWS retirement touches. - Is authentication OAuth or Basic? OAuth survives December 2026. Basic (mailbox username and password on
smtp.office365.com) does not. - Is the transport SMTP, Graph, or EWS? The mailer plugin’s connection screen names it. SMTP (any
smtp.*host) and Graph (graph.microsoft.com/v1.0/...) are unaffected by EWS retirement; EWS (/EWS/Exchange.asmx) is the one that stops.
The headline is scary; the WordPress send path is fine. The deprecation that actually breaks WordPress mail through M365 in the current window is SMTP AUTH basic authentication, and the fix is the OAuth switch.
For the parent decisions, Can I use Outlook for my WordPress email? covers whether to use Microsoft 365 at all, and Can WordPress send from a Microsoft 365 alias? covers the recent GA on alias sending.