Microsoft SMTP Basic Auth for Office 365 is going away: what WordPress site owners actually need to do

If your WordPress site sends email through an Office 365 mailbox using a username and password, that setup has an expiration date. Microsoft has been working to shut down Basic Authentication for SMTP Client Submission (the smtp.office365.com:587 flow that most WordPress SMTP plugins use) for years. The original cutoff was April 30, 2026. Then Microsoft delayed it. The actual 2026 story is messier than the headline, and more urgent than the new date suggests.

TL;DR: Microsoft revised the timeline on January 27, 2026. Basic Auth for SMTP Client Submission now stays on until end of December 2026, then flips off by default for existing tenants. New tenants from 2027 lose it entirely. But plenty of WordPress sites are already broken for a different reason: Microsoft's Security Defaults disable SMTP AUTH at the tenant level, and any tenant spun up after 2020 is likely affected. The two error codes to know are 550 5.7.30 Basic authentication is not supported for Client Submission and 535 5.7.139 Authentication unsuccessful. Your options: switch your SMTP plugin to OAuth, move transactional mail to a proper relay, or stop mixing business email and website mail altogether.

Table of contents

• What actually changed in January 2026
• Why your site may already be broken
• The two error codes and what they mean
• How to check if this affects you
• Path 1: switch your SMTP plugin to OAuth
• Path 2: move transactional mail to a relay
• Path 3: separate email hosting from WordPress
• What will not help
• Key takeaways

What actually changed in January 2026

Microsoft's original 2024 post said Basic Auth for SMTP Client Submission would be permanently removed around March and April 2026. That post is still live and still the top Google result. It is outdated. On January 27 the Exchange team published a revised timeline:

• Now through December 2026, SMTP AUTH Basic Auth keeps working exactly as it does today.
• End of December 2026, Basic Auth is disabled by default for existing tenants. Admins can still re-enable it temporarily via PowerShell if they have a very good reason.
• From 2027 onward, new tenants get no Basic Auth at all, no opt-in.
• In the second half of 2027, Microsoft will announce the final hard removal date.

So the panic articles from February and March are wrong about the deadline. You have until December. But the real story is that the deadline was never your only problem.

Why your site may already be broken

Here is the part the "April 30 deadline" coverage skips. Microsoft has been enabling Security Defaults on every Microsoft 365 tenant created since October 2019, and Security Defaults switch off SMTP AUTH at the tenant level. If you (or anyone else with admin access) clicked "Enable Security Defaults" in the Microsoft 365 admin center at any point, SMTP AUTH is already off. The Basic Auth retirement is irrelevant in that case. The door was closed years ago.

That is the single most common cause of "my contact form stopped sending emails overnight" in 2025 and 2026. I see it in the WP Mail SMTP support forum and on Microsoft Q&A repeatedly. If you set up SMTP in 2018 and nobody touched anything, it still works. If your tenant is newer, or if anyone ever enabled Security Defaults, it probably does not.

The two error codes and what they mean

If you have logging enabled in your SMTP plugin, you will see one of two errors in the transcript:

535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant. The tenant admin disabled SMTP AUTH outright. This is the Security Defaults scenario. Fixing this means either exempting the mailbox via Set-CASMailbox -Identity user@domain -SmtpClientAuthenticationDisabled $false, switching to OAuth, or moving the site off M365 SMTP entirely.

550 5.7.30 Basic authentication is not supported for Client Submission. This is the actual Basic Auth retirement speaking. You will start seeing it when Microsoft begins enforcing the December 2026 cutoff on your tenant, or if an admin has flipped the switch manually as a dry run.

For a non-technical site owner the symptom is identical: email is not going out. The fix is the same either way. Move away from username-and-password SMTP.

How to check if this affects you

Five minutes of poking around tells you everything you need to know.

1. Log into WordPress and check which SMTP plugin is active. The common ones are WP Mail SMTP, FluentSMTP, Easy WP SMTP and Post SMTP.
2. Open the settings. If the mailer type is "Other SMTP" or "Custom SMTP" and the host is smtp.office365.com or smtp-mail.outlook.com, you are on the affected path.
3. If the mailer type is "Microsoft 365", "Outlook", or similar, you are already on OAuth. You are fine.
4. Trigger a test email. Every plugin has a test button. Check the log for either of the two error codes.
5. If the plugin has logging turned off, enable it now. Without logs, your only signal that email is broken is an angry phone call from a customer who never got their order confirmation.

Path 1: switch your SMTP plugin to OAuth

This is the minimum-change option. You keep the plugin, keep the host, keep the port. You only change how authentication works: a token instead of a password.

For this you need Azure admin access to the Microsoft 365 tenant (or cooperation from whoever has it), and about 45 minutes the first time. The plugin side is easy. The Azure App registration is the fiddly part, but every plugin has documentation:

• WP Mail SMTP Microsoft 365 / Outlook mailer: a Pro-only feature, so you need a paid license. Includes a one-click setup that handles most of the Azure work.
• WPO365 MS Graph Mailer: free core plugin, 10,000+ active installs, actively maintained. This is the most Microsoft-native option: it bypasses SMTP entirely and sends via Microsoft Graph. Requires a manual Azure App registration with Mail.Send permission.
• FluentSMTP Microsoft 365 setup: supports OAuth in the free version.
• Easy WP SMTP one-click Microsoft 365 setup: also free, also OAuth-based in recent versions.

One thing nobody warns you about up front: the Azure client secret expires. The default lifetime is one or two years, and when it expires, email silently stops going out. Set it to the maximum lifetime and put the expiry date in a calendar you actually read. I have seen clients come back a year later wondering why nothing is arriving, and this is the reason.

Path 2: move transactional mail to a relay

For most WordPress sites I would argue this is the better long-term option, not just a workaround. Microsoft 365 mailboxes were never designed for transactional volume. They have a hard sending limit of 10,000 recipients per day and 30 messages per minute per user. That is fine for a small contact form. It falls over the moment a WooCommerce shop sends order, shipping and refund emails in bulk. A dedicated transactional relay also has much better deliverability, because its entire IP reputation is built around transactional sending rather than mixed with regular business mail.

For readers in the EU market, the shortlist:

• Brevo: Paris-based, servers entirely in the EU. Free tier of 9,000 emails per month with a 300-per-day cap. Paid plans from around 7 euro per month. My default suggestion for Dutch and Belgian clients who care about EU residency.
• SMTP2GO: has an EU data center in Amsterdam. Free tier of 1,000 emails per month. Paid from 10 dollar per month.
• MailerSend: Lithuanian founders, EU-based. Free tier was reduced from 3,000 to 500 emails per month in October 2025, so double-check the current limit before signing up.
• Postmark: US-only hosting. No EU data residency. But the deliverability reputation is the best in the transactional category by a long way. If EU residency is not a hard requirement for you, Postmark is often the cleanest choice.
• Amazon SES: available in Frankfurt and Ireland, 0.10 dollar per 1,000 emails. Cheap and reliable, but the setup and DNS verification are more technical than the plug-and-play relays.

All of these work with any SMTP plugin that supports custom credentials. No Azure portal involved.

Path 3: separate email hosting from WordPress

This is the advice I give most clients: stop trying to route WordPress transactional email through a business mailbox at all. Your Outlook inbox is where replies come in. A relay is where your website sends from. These are two different jobs and they do not need to share infrastructure.

In practice: keep Microsoft 365 or Google Workspace for info@yourdomain.com and the rest of your human mailboxes. Use a separate relay (Path 2) for everything wp_mail() produces. Authorize the relay to send on your domain by updating SPF and DKIM. If you need the DNS side, I wrote a full guide to setting up SPF, DKIM and DMARC. If you want to understand why contact form plugins land in spam in the first place, I covered that in why WordPress contact form emails end up in spam.

What will not help

A few things that Microsoft documentation lists as alternatives, but which are not viable for typical WordPress hosting:

• Direct Send (unauthenticated, to your tenant's MX endpoint): cannot reach external recipients. WooCommerce order emails go to Gmail and Outlook customers. Direct Send will not deliver them. Microsoft is also actively working on disabling it by default for new tenants.
• SMTP relay via connector with a static IP: explicitly blocked from cloud hosting IP ranges. The Microsoft doc states plainly: "You can't use SMTP relay to send email from a third-party hosted service (for example, Microsoft Azure) through Microsoft 365 or Office 365." That rules out shared hosting, VPS, Kinsta, WP Engine, Cloudways and effectively every managed WordPress platform.
• Microsoft High Volume Email (HVE): generally available since March 31, 2026 but internal recipients only. External sending was removed during public preview. HVE is useless for WordPress transactional email.

Key takeaways

• Microsoft moved the SMTP Basic Auth deadline from April 30, 2026 to end of December 2026. The old articles are outdated, but the migration still has to happen.
• Many WordPress sites on Microsoft 365 are already broken right now, not because of the retirement but because of Security Defaults. Turn on SMTP plugin logging and check for 535 5.7.139 or 550 5.7.30 today.
• OAuth inside your existing SMTP plugin is the minimum change. Budget 45 minutes for the first Azure App registration, and put the client secret expiry on your calendar.
• For most WordPress sites, a dedicated transactional relay is the better long-term answer. Brevo and SMTP2GO are the strongest EU-based options.
• Treat business email and website email as two separate systems. Outlook is where replies come in. A relay is where wp_mail() goes out.