Verified against Microsoft’s published timeline as of August 2026. This date has moved once already — it previously read 30 April 2026 — so check Microsoft’s Exchange team post before acting on a date alone.
If your WordPress site sends email through Microsoft 365 using a username and password, that arrangement has an expiry date.
The timeline
- Now through December 2026 — no change. SMTP AUTH basic authentication continues to work.
- End of December 2026 — basic authentication for SMTP AUTH is disabled by default for existing tenants. Administrators can still re-enable it.
- After that — tenants created later have it unavailable by default.
- Second half of 2027 — Microsoft says it will announce the final removal date, after which re-enabling will not be possible.
So the December date is not the end of the world; it is the point at which a working site can stop working overnight without anybody touching it, and the fix requires an administrator.
The part that is already happening
The deadline is not the whole story, and this catches people out today.
Accounts created recently — including on Microsoft 365 Basic — are showing no Authenticated SMTP option at all. In the mailbox settings where POP and IMAP toggles appear, the SMTP AUTH toggle is simply absent. It is off, and there is no user-facing switch to turn it on.
If you have set up a new Microsoft 365 mailbox in the last year and cannot work out why SMTP authentication fails no matter what credentials you use, this is likely why. You are not misconfiguring it. The option is not there.
Are you affected?
You are affected if your SMTP settings look roughly like this:
Host: smtp.office365.com
Port: 587
Encryption: STARTTLS
Username: [email protected]
Password: (your mailbox password, or an app password)That is basic authentication, and it is what stops working.
You are not affected if you connect to Outlook or Microsoft 365 through OAuth — where you clicked a Microsoft consent screen and authorised the connection rather than typing a password into your SMTP settings.
You are also unaffected if you send through a separate provider such as Amazon SES, SendGrid or Postmark, even if your staff mailboxes are on Microsoft 365. This distinction matters and is worth being clear about: where your team reads mail and how your website sends mail are separate decisions.
Your options
Option 1: move to OAuth
The direct replacement. Instead of storing a password, the site holds a token issued by Microsoft, which you authorise once and which can be revoked without changing anybody’s password.
Practically this means registering an application in Microsoft Entra ID (formerly Azure AD) to get a client ID and secret, then connecting your site to it. The steps:
- In the Azure portal, register a new application.
- Add the redirect URI your SMTP plugin gives you. It must match exactly — a trailing slash difference is enough to cause a
redirect_uri_mismatcherror. - Grant the mail-sending permission and, if your tenant requires it, have an administrator consent to it.
- Create a client secret and record it immediately; the portal shows the value only once.
- Enter the client ID and secret in your site, then complete the Microsoft consent screen.
NimblyMail supports Microsoft 365 and Outlook over OAuth in the free plugin, and stores the resulting tokens encrypted rather than in plain text — both the access token and the refresh token are encrypted at rest.
Two honest caveats. First, you register your own Entra application; there is no way around that step today. Second, OAuth tokens are bound to the site that authorised them, so a staging clone will hold an invalid token — which is a nuisance during migration and, on reflection, a useful accident, since a cloned site cannot send mail as you.
Option 2: use a high-volume relay instead
If your site sends transactional mail — order confirmations, password resets, form notifications — a dedicated sending service is arguably a better fit than a mailbox provider regardless of this deadline.
Mailbox providers are built for people reading and writing mail, and they enforce sending limits that transactional volume runs into. A sending service gives you delivery logs, bounce handling and suppression management, which Microsoft 365 does not surface for application mail.
This also decouples your website from your staff email entirely, so a mailbox policy change stops being a website outage.
Option 3: ask your administrator to re-enable it
A stay of execution, not a fix. It buys time until the final removal date is announced. Reasonable if you need to survive December while planning properly; unreasonable as a strategy.
Deciding between OAuth and a relay
The choice is usually clearer than it looks once framed by what the site actually sends.
| Microsoft 365 over OAuth | A transactional relay | |
|---|---|---|
| Setup effort | Entra app registration, admin consent | API key, DNS records |
| Sending limits | Human-scale, enforced per mailbox | Built for volume |
| Delivery logs | Not surfaced for application mail | Per-message, with bounce reasons |
| Bounce handling | None you can act on | Automatic suppression |
| Survives a mailbox policy change | No | Yes — fully decoupled |
| Best for | Low-volume mail that must come from a real mailbox | Order confirmations, resets, notifications |
The row that decides it for most stores is the last but one. If your website’s ability to send email depends on your staff mailbox provider’s authentication policy, then every future policy change is a website outage. Decoupling them is worth doing on its own merits, and this deadline is a good prompt.
Errors you will meet during the OAuth switch
redirect_uri_mismatch— the redirect URI registered in Entra does not exactly match the one your plugin uses. Exactly means protocol, host, path and any trailing slash. Copy it from the plugin rather than typing it.AADSTS65001(consent required) — the application has not been consented to for your tenant. If your organisation requires administrator consent, a global administrator must grant it; users cannot self-consent.AADSTS7000215(invalid client secret) — usually the secret’s ID was copied rather than its value. The portal shows both and the value only once, at creation.- Authentication succeeds, sending fails — the mail-sending permission was not granted, or was granted and not consented to. Permissions and consent are two separate steps.
- Works, then fails weeks later — the client secret expired. Entra secrets have an expiry date, commonly six or twelve months, and nothing warns you. Record the date somewhere you will see it.
That last one deserves emphasis, because it recreates the exact failure this deadline is meant to end: mail stops silently, months later, for a reason nobody connects to the change they made. Whatever you choose, a recurring connectivity check that actually opens a connection to your mail host is what turns that into a notification rather than a support ticket.
Agencies and multisite
If you manage sites for other people, this deadline scales badly. The same Microsoft 365 SMTP configuration tends to be replicated across every client that uses Microsoft for email, and each one fails independently, at roughly the same time, in December.
Two things worth doing now rather than then:
- Inventory which sites authenticate with a password to
smtp.office365.com. That list is your exposure, and it is almost always longer than expected. - Decide once, apply everywhere. Migrating a portfolio to a single transactional relay is usually less total work than registering an Entra application per client, and it removes the dependency permanently.
On multisite specifically, settings that resolve from the network level let you change the mailer once for every subsite rather than site by site, and locking the field prevents a subsite administrator reverting it.
What to do now
- Find out how your site actually authenticates. Open your SMTP settings. If there is a password field with a password in it, you are on basic auth.
- Check every site. Agencies and multisite networks tend to have this configuration replicated across dozens of installs, each of which will fail independently.
- Decide between OAuth and a relay. If the site sends more than a trickle of transactional mail, the relay is usually the better long-term answer.
- Change it before December, not during. OAuth setup involves an Azure application registration and possibly an administrator’s consent. That is not a thing to discover at speed on a broken production site.
- Set up a check that would notice. The failure mode here is silence: mail stops and nothing in WordPress announces it. A recurring connectivity check that actually opens a connection to your mail host will tell you the day it breaks, rather than the day a customer does.
Source
Microsoft’s Exchange team post, Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline, is the authoritative reference and the one to check for changes.