Blog / Infrastructure

Microsoft Is Going OAuth-Only: What It Means for Cold Email

30 May 2026

Microsoft is retiring basic authentication for SMTP. In plain terms: signing in to send mail with a stored username and password is going away. Microsoft has published timelines pointing to basic-auth SMTP being disabled by default in existing tenants and new Microsoft 365 tenants being OAuth-only by default — the dates have moved before, so treat the specific milestones as approximate and check current Microsoft announcements. The direction is not in doubt: any cold-email setup that logs in with a password will eventually stop sending unless it moves to modern authentication.

What “OAuth-only” actually means

There are two ways a tool can connect to a Microsoft 365 mailbox to send mail.

Basic authentication is the old way: your sequencer stores a username and password and presents them on each connection, the same way an email client did in 2010. It works, but the credentials are long-lived, easy to leak, and impossible to scope tightly.

OAuth (often called modern authentication) is the replacement. Instead of a password, your tool holds a revocable, scoped token issued by Microsoft. You grant a specific application permission to act on a mailbox, and that grant can be limited and withdrawn without changing the account password. It is the standard Microsoft now requires for programmatic access.

The shift is not about cold email specifically. Microsoft has been deprecating basic auth across Exchange Online for years to close off password-spray and credential-stuffing attacks. SMTP AUTH was one of the last protocols still allowing it, and it is now on the same path.

The timeline that matters

Microsoft has revised these dates more than once, so the specific milestones below are based on its published guidance at the time of writing — confirm the current dates against Microsoft’s own announcements before you plan around them.

Change	When (per Microsoft’s current guidance)	Who it affects
Basic-auth SMTP disabled by default in existing tenants	Around end of 2026 (admins may still be able to re-enable temporarily)	Anyone still sending with a username and password
New tenants OAuth-only by default	New tenants created after that point	Every newly provisioned Microsoft 365 tenant

Two practical takeaways. First, if you provision new sending tenants — which most cold-email operators do regularly, because domains wear out under sustained volume, often within a few months — those tenants are heading toward OAuth-only first. Second, even where basic auth can be re-enabled for a while, that is a temporary stopgap, not a permanent setup. The direction of travel is one-way, so plan the move to OAuth rather than relying on a grace period whose end date Microsoft has not finalised.

What breaks, and what doesn’t

What breaks is any integration that authenticates with a password. That includes raw SMTP connections using AUTH LOGIN, older sequencer connectors that ask for an app password, and homegrown scripts that send through smtp.office365.com with stored credentials. When the switch flips, those connections fail at sign-in. The mailbox is fine; the way you reached it is the problem.

What does not break is your domain authentication or your reputation. SPF, DKIM, and DMARC sit at the DNS and message layer and are unaffected by how your tool logs in. Your warmup history, sending reputation, and inbox placement carry over. OAuth changes the lock on the door, not the house behind it.

It is worth being blunt about one thing: OAuth does not improve deliverability. It is an authentication mechanism, not a reputation signal. Receiving servers do not reward you for using a token instead of a password. If you want to move the needle on placement, the levers are still SPF, DKIM, and DMARC, proper warmup, realistic daily volume, and clean lists — not your login method.

How to check whether you’re exposed

A quick self-audit:

• How does your sequencer connect Microsoft 365? If you pasted a username and password (or an “app password”), you are on basic auth. If you went through a Microsoft sign-in screen and approved permissions, you are likely on OAuth.
• Are you provisioning new tenants now? New tenants are heading to OAuth-only first. A workflow that relies on password connections will hit the wall sooner than a tenant-wide cutoff might suggest.
• Do any scripts send raw SMTP with stored credentials? Those are the most fragile and the first to fail.

If any answer points to passwords, plan the migration to OAuth before your sending depends on a deadline you didn’t set. For background on how these tenants fit together, see what a Microsoft 365 tenant is and what mailbox provisioning involves.

Why this favours managed, OAuth-native setups

The deprecation rewards infrastructure that was built for modern auth from the beginning. An OAuth-native setup connects each mailbox through Microsoft’s token flow at provisioning time, so there is no password to migrate and no cutoff to scramble for. A setup glued together with app passwords has to be reworked tenant by tenant before its deadline.

This is one more reason the managed-versus-manual decision is getting sharper. Manual stacks accumulate authentication debt; the operator owns the migration. Managed infrastructure that already speaks OAuth absorbs the change quietly.

How Mailionaire approaches this

Mailionaire provisions each sending domain into its own isolated Microsoft 365 tenant with OAuth-native authentication from the start, so there is no password-based credential to migrate as Microsoft retires basic-auth SMTP. SPF, DKIM, and DMARC are configured automatically, which means you’re not the one tracking Microsoft’s deprecation calendar. Pricing stays simple at $50/month per active domain, with up to 100 mailboxes per domain; see how it works.

FAQ

When does Microsoft turn off basic authentication for SMTP?

Microsoft has been retiring basic authentication (password-based AUTH LOGIN) across Exchange Online, and its published timelines point to basic-auth SMTP being disabled by default for existing tenants and new tenants being OAuth-only. Exact dates have shifted before, so check current Microsoft announcements for the latest. The takeaway: any cold-email setup that signs in with a username and password is on borrowed time and should move to OAuth.

Will my cold-email tool still work after the OAuth-only change?

Only if it connects via OAuth (modern authentication). Tools and integrations that authenticate with a stored password will fail. Check whether your sequencer connects Microsoft 365 mailboxes through OAuth rather than an SMTP username and password, and migrate before the deadline.

Does OAuth improve my cold-email deliverability?

No. OAuth is an authentication method — it controls how your tool proves it may use a mailbox. It does not influence inbox placement. Deliverability still depends on SPF, DKIM, DMARC, warmup, sending volume, list quality, and reputation, not on how you log in.

Does switching to OAuth make my cold email legal?

No. Authentication has nothing to do with consent law. You still need a lawful basis to email a recipient. In Germany, UWG §7(2) generally requires prior opt-in even for B2B, and the recipient's jurisdiction governs. This is not legal advice; the sender is responsible.

---