WordPress email and the Microsoft 365 Basic auth shutdown

A WordPress site that cannot send email does not look broken. It looks fine.

The order page still says thank you. The password-reset form still says check your inbox. The contact form still shows its success message. Every one of those screens is rendered before the mail is handed to the SMTP server, and none of them changes when the handoff is refused.

So the failure arrives as an absence, and it arrives at somebody who cannot report it to you: the customer who never got the confirmation and assumes the order failed, the user who never got the reset link and gave up, the enquiry that was never answered because it was never seen.

What actually stops

If your site authenticates to Microsoft 365 with a username and password — which is what every plugin’s Other SMTP option does — then at the end of December 2026 Exchange Online stops accepting it by default. Not throttles: refuses.

An administrator can switch it back on; Microsoft’s own announcement says so. That is a reprieve, not a fix — the final removal date gets announced in the second half of 2027, and tenants created after December 2026 never get the option. And if you are maintaining somebody else’s site, the person who can grant that reprieve is not you.

That covers, in rough order of how much it hurts:

WooCommerce order confirmations, invoices and shipping notices. The customer’s only receipt.
Password resets. Locks people out permanently, including administrators.
New-account and email-change confirmations.
Contact-form and enquiry mail. Lost leads, no error anywhere.
Core update and security notifications — including the ones that tell you something is wrong.

How to tell whether you are affected, today

You are affected if your SMTP plugin is set to Other SMTP with an smtp.office365.com host and a mailbox password in the password field.

You are not affected if the plugin is using a Microsoft 365 / Outlook mailer that sent you through a Microsoft consent screen, or a provider that is not Microsoft at all.

The message you will actually see

Not the server’s. Your plugin’s.

WordPress surfaces PHPMailer’s summary through the plugin, one layer further from the server, and prints SMTP connect() failed. — six words naming no code, no tenant and no cause. The wording suggests a network problem. It is not.

What WordPress prints, and what the server said covers how to make the plugin show you the real line, which is the only thing that tells you whether somebody with tenant rights can switch this back on — and whether that somebody is you.

Your three routes, honestly

1. OAuth through the plugin — best, if you can do it

Both major plugins offer a Microsoft 365 mailer that uses OAuth instead of a password:

FluentSMTP lists Microsoft Office (Outlook) among its providers and is free on WordPress.org.
WP Mail SMTP’s Microsoft 365 / Outlook.com mailer is a paid feature — their documentation states it “is only available with the Pro license or higher.”

Either way the real gate is not the plugin. It is that OAuth needs an application registered in Microsoft Entra, which needs somebody with admin rights in the tenant. If you have those rights, take this route and stop reading — it keeps your own domain in the From address, and nothing on this site improves on that.

2. A relay — when route 1 is closed to you

Route 1 is closed more often than its documentation assumes. An agency maintaining a client’s site is not an administrator of the client’s tenant. A freelancer handed FTP credentials is not either. Neither is anyone on shared hosting whose customer’s IT is a phone number that answers in three weeks.

That is who a relay is for: the site owner who can change a plugin setting and cannot change anything in Entra.

3. Move the site’s mail off Microsoft 365 entirely

For a transactional store this is frequently the correct answer, and it is not ours. A dedicated transactional provider gives you your own sending domain, DKIM alignment, bounce handling and volume. The alternatives page names them without pretending we compete.

Before you configure ZeroSMTP, two limits that may disqualify it

Stated here rather than discovered after your store’s busiest day:

Mail leaves from a generated @msgwing.com address, not your own domain. For password resets and contact forms this is usually acceptable. For WooCommerce order confirmations it often is not — customers expect the shop’s address, and a receipt from an unfamiliar domain gets ignored or reported.
200 messages a day, with no paid tier that lifts it. A small business site will never touch that. A store with a hundred orders a day, each generating several messages, will.

If either rules you out, route 3 above is where to go, and going there is not a defeat.

Setup, if it still fits

Works with WP Mail SMTP, FluentSMTP, Post SMTP or any plugin offering a plain SMTP option.

Register at msgwing.com and copy the generated login and password — they are shown once.
In the plugin’s mailer settings choose Other SMTP.
Enter the values below.
Set the From address to your generated @msgwing.com login. Leaving your own domain there while sending through a different one is the fastest way into a spam folder.
Send the plugin’s built-in test email.

Setting	Value
SMTP host	`mx.msgwing.com`
Port	`587` (STARTTLS) or `465` (SSL/TLS)
Encryption	STARTTLS on 587, or SSL/TLS on 465 — required
Authentication	Enabled
Username	your `@msgwing.com` login
Password	your `@msgwing.com` password
From address	your `@msgwing.com` login

Then place a test order, or trigger a real password reset. The plugin’s test email proves the connection; it does not prove that WooCommerce’s own mail uses it.

Updated 29 Aug 2026