Microsoft 365 for Cold Email in 2026: What Changed and What to Do

For years, Microsoft 365 (formerly Office 365) was a popular choice for cold email senders. The combination of Outlook's strong domain reputation, straightforward SMTP credentials, and broad compatibility with sales automation tools made it an attractive option. That era ended on March 1, 2026.

Microsoft's deprecation of Basic Authentication for SMTP AUTH in Exchange Online has disrupted the workflows of thousands of sales teams and agencies. If your cold email setup relied on Outlook SMTP credentials, this guide explains exactly what happened, what your options are, and how to get back to sending without downtime.

What Changed on March 1, 2026

On March 1, 2026, Microsoft permanently disabled Basic Authentication for SMTP AUTH connections in Exchange Online. This means that any application, tool, or script that connected to Microsoft 365's SMTP servers using a simple username and password no longer works.

This was not a surprise. Microsoft first announced the deprecation back in September 2022, with an original enforcement date of October 2022. After significant pushback from customers, the timeline was extended multiple times. Temporary re-enablement policies were offered throughout 2023 and 2024. A "final warning" phase ran through most of 2025, during which Microsoft began disabling Basic Auth for tenants that showed no recent usage. On March 1, 2026, the switch was flipped for everyone -- no exceptions, no extensions.

What Basic Auth deprecation means in practice:

• Simple SMTP connections fail. Connecting to smtp.office365.com with a username and password returns an authentication error.
• All connections must use OAuth 2.0 (also called "Modern Auth"). This requires an access token obtained through Microsoft's identity platform, not a static password.
• App passwords are deprecated too. Microsoft began removing app password support in tandem with Basic Auth. If you were using an app password as a workaround, that path is also closed.
• IMAP and POP3 Basic Auth were disabled earlier (October 2023 for most tenants), but SMTP AUTH was the last holdout -- and the one that cold email tools relied on most.

The technical change is straightforward: Microsoft's SMTP servers now reject the AUTH LOGIN and AUTH PLAIN commands when used with static credentials. Only the XOAUTH2 SASL mechanism is accepted, which requires a valid OAuth 2.0 bearer token.

Who's Affected

The impact is broad. Anyone who was sending email through Microsoft 365 via SMTP using username/password credentials is affected. But some groups are hit harder than others.

Sales Automation Tools

The most affected group is users of sales engagement platforms that connect to Outlook/Microsoft 365 via SMTP. This includes users of Smartlead, Apollo, Instantly, Lemlist, Woodpecker, Mailshake, and dozens of smaller tools. Most of these platforms originally onboarded Microsoft 365 accounts by asking users for their Outlook email and password (or app password), then connecting via SMTP AUTH to smtp.office365.com on port 587.

That connection method no longer works. Period.

Agencies Running Multiple Accounts

Cold email agencies that managed dozens or hundreds of Microsoft 365 accounts across multiple tenants are particularly disrupted. The per-tenant OAuth setup required to maintain these connections at scale is substantially more complex than the old username/password approach.

Custom Scripts and Internal Tools

Development teams that built internal sending tools using Python's smtplib, Node.js's Nodemailer, or similar libraries with hardcoded Microsoft 365 SMTP credentials need to refactor their authentication flow entirely.

Who Is NOT Affected

Senders using dedicated SMTP infrastructure (not Microsoft 365) are unaffected. Gmail/Google Workspace users are also unaffected by this specific change, though Google has its own set of restrictions for cold email senders. Users who already migrated to Microsoft's OAuth 2.0 or Graph API authentication continue to work normally.

The OAuth 2.0 Problem

In theory, the solution is simple: switch from Basic Auth to OAuth 2.0. In practice, this introduces significant complexity -- especially for cold email use cases where you may be managing many accounts.

What OAuth 2.0 Requires

To send email through Microsoft 365 using OAuth 2.0, you need:

1. Azure AD App Registration. You must register an application in Azure Active Directory (now called Microsoft Entra ID). This involves creating a client ID and client secret, defining the required API permissions (specifically Mail.Send or SMTP.SendAsApp), and configuring redirect URIs.
2. Tenant Admin Consent. The Azure AD application requires admin consent for the permissions it requests. For multi-tenant setups (common in agencies), each customer's Microsoft 365 admin must grant consent separately.
3. Token Refresh Handling. OAuth access tokens expire (typically after 60 minutes). Your application must handle token refresh automatically using refresh tokens, which themselves expire after 90 days of inactivity. If a refresh token expires, the user must re-authenticate interactively.
4. Conditional Access Compliance. Many organizations have Conditional Access policies that can block token issuance from unrecognized devices, IP addresses, or locations. This is a common source of authentication failures that didn't exist with Basic Auth.

Tool Support Is Uneven

Major sales automation platforms have been rolling out OAuth support, but the transition is far from complete. Some platforms added OAuth support early and handle it smoothly. Others added it late, with rough edges around token refresh failures and re-authentication flows. Some smaller or newer tools still don't support Microsoft OAuth at all, leaving their users stranded.

Even when a tool does support OAuth, the user experience is worse than it was with Basic Auth. Instead of entering an email and password, users must navigate Azure AD setup, grant admin consent, and deal with periodic re-authentication prompts when tokens expire. For agencies managing 50+ Microsoft 365 accounts, this administrative overhead is substantial.

The Token Refresh Problem

The most common post-migration issue is silent token expiration. When a refresh token expires -- because the account was inactive for 90 days, because a Conditional Access policy revoked it, or because an admin changed the tenant's security settings -- the SMTP connection fails quietly. Campaigns stop sending, and many teams don't notice until days later when they check their analytics.

This is fundamentally different from Basic Auth, where credentials either worked or they didn't. OAuth introduces a class of intermittent, time-delayed failures that are harder to monitor and debug.

Your Options

If you're currently using Microsoft 365 for cold email (or were, before March 1), you have three paths forward. Each has different tradeoffs around complexity, cost, and reliability.

Option A: Migrate to OAuth 2.0

Continue using Microsoft 365, but update your authentication to use OAuth 2.0. This means registering an Azure AD application, configuring permissions, and ensuring your sales tools support the OAuth flow.

Pros: Keep your existing Microsoft 365 accounts and domain reputation. No need to change email addresses or warm up new accounts.

Cons: Requires Azure AD admin access. Token refresh adds ongoing maintenance. Not all tools support it. Still subject to Microsoft's sending limits (10,000 emails/day per tenant, with per-mailbox rate limits that are much lower).

Option B: Use Microsoft Graph API

Instead of SMTP, send emails through Microsoft's Graph API. This is Microsoft's recommended approach for application-level email sending and is the most "future-proof" option within the Microsoft ecosystem.

Pros: Full Microsoft support. Access to advanced features (read receipts, calendar integration). No SMTP configuration needed.

Cons: Even more complex than OAuth SMTP. Requires application-level permissions and admin consent. Most sales automation tools don't support Graph API natively. Sending limits remain the same. Custom development is typically required.

Option C: Switch to Dedicated SMTP Infrastructure

Move your cold email sending to purpose-built SMTP infrastructure. This means new domains, new email accounts, and a warmup period -- but it eliminates the Microsoft dependency entirely.

Pros: No OAuth complexity. No token refresh failures. Higher sending limits. Purpose-built for cold email volume. Automatic SPF, DKIM, and DMARC. Works with every sales automation tool that supports SMTP.

Cons: Requires new domains and email accounts. Warmup period before sending at full volume. Monthly cost for the SMTP service.

Option Comparison

For most cold email use cases, Option C (dedicated SMTP) is the recommended path. The 2-3 week warmup period is a short-term cost that eliminates ongoing OAuth complexity and gives you infrastructure that was actually designed for outbound email volume.

How to Migrate from Microsoft 365 to SMTP

If you've decided to move away from Microsoft 365 for cold email, here's a step-by-step migration plan that minimizes downtime and protects your sender reputation.

Step 1: Set Up Dedicated SMTP Accounts

Sign up for a dedicated SMTP provider like Winnr. Provision your email accounts and domains. With Winnr, SPF, DKIM, and DMARC are configured automatically on every domain -- no DNS records to set up manually. Plan for roughly the same number of sending accounts you had in Microsoft 365, or more if you want to distribute volume further.

Step 2: Export Your Microsoft 365 Contact Lists

Before making any changes to your Microsoft 365 accounts, export your contact lists and campaign data from your sales automation tool. Most tools allow CSV exports of prospect lists, campaign sequences, and performance data. Keep this data as your migration reference.

Step 3: Connect SMTP Accounts to Your Sequencer

Add your new SMTP accounts to your sales automation tool using standard SMTP credentials (host, port, username, password). Unlike Microsoft 365 OAuth, this is the same simple credential-based setup that worked before -- just with a different mail server. Every major sequencer supports SMTP: Smartlead, Instantly, Apollo, Lemlist, Woodpecker, and others.

Step 4: Warm Up New Accounts

New email accounts need a warmup period to build sender reputation. This typically takes 2-3 weeks. During warmup, start with low volume (5-10 emails per day per account) and gradually increase. If your SMTP provider includes built-in warmup (Winnr does), enable it on all accounts from day one.

Step 5: Gradually Shift Campaigns

Don't switch everything at once. Start by routing new campaigns through your SMTP accounts while letting existing Microsoft 365 campaigns finish their sequences. As SMTP accounts complete warmup, shift more volume over. Within 3-4 weeks, you can fully transition.

Step 6: Keep Microsoft 365 for Business Email

Microsoft 365 remains excellent for day-to-day business communication: internal email, client correspondence, calendar scheduling. The deprecation only affects programmatic SMTP AUTH, not normal Outlook usage. Keep your Microsoft 365 licenses for business email and use dedicated SMTP for cold outreach -- this separation is a best practice regardless of the auth changes.

Microsoft 365 vs Dedicated SMTP: Updated Comparison

With the March 2026 changes factored in, here's how Microsoft 365 and dedicated SMTP infrastructure compare for cold email specifically.

The cost difference alone is significant at scale. A team running 50 sending accounts on Microsoft 365 pays $300-600/month in licensing before any sequencer costs. The same 50 accounts on dedicated SMTP costs $50-100/month -- and you get higher limits, simpler auth, and purpose-built infrastructure.

What This Means Going Forward

The Microsoft 365 Basic Auth deprecation is part of a broader industry trend: shared email providers are making it increasingly difficult to use their infrastructure for cold outreach. Google tightened its policies in 2024. Microsoft followed in 2026. Yahoo and other providers have introduced stricter authentication requirements as well.

The pattern is clear. Shared email providers are optimizing for inbox users, not outbound senders. Every policy change -- whether it's authentication requirements, sending limits, or abuse detection -- makes cold email harder on shared infrastructure.

Dedicated SMTP infrastructure exists specifically to solve this problem. Purpose-built sending infrastructure doesn't fight you on authentication. It doesn't throttle you at 10,000 emails per day. It doesn't suspend your account for sending patterns that are normal for sales outreach.

If the March 2026 change caught you off guard, use it as the catalyst to move to infrastructure that was built for what you're actually doing.

Related guides: Compare SMTP vs Google/Microsoft for cold email, read our cold email best practices guide, learn what to do if Google Workspace suspends your account, or check our sending limits by provider comparison.