If you searched for this because you read that Microsoft killed Basic authentication for SMTP on March 1, 2026, and your cold email is about to stop working: it didn't, and it isn't. Microsoft revised that timeline. Basic auth for SMTP AUTH still works in Exchange Online today. This guide gives you the actual schedule, what genuinely changes and when, and how to move your sending onto a path that survives the real deadline.
Short answer: Basic authentication for Microsoft 365 SMTP AUTH was not disabled in March 2026. Microsoft updated the deprecation timeline in January 2026. Behavior stays unchanged through December 2026. At the end of December 2026, SMTP AUTH Basic Auth becomes disabled by default for existing tenants, but administrators can still re-enable it. Tenants created after December 2026 won't have it available by default. Microsoft will announce the final removal date in the second half of 2027. The migration path is OAuth 2.0 for SMTP, or Microsoft Graph, or a relay connector.
What actually changed (and what didn't)
There is a lot of confidently wrong content about this, including from vendors who benefit from you panicking. So let's separate the two things that get conflated.
What changed years ago and is genuinely dead: Basic authentication for Exchange ActiveSync, POP, IMAP, Remote PowerShell, Exchange Web Services, Offline Address Book, Autodiscover, and Outlook desktop clients. Microsoft finished disabling those across all tenants by 2023. Nobody can re-enable them, including Microsoft support. If you read a blog post saying "Basic auth is disabled in all tenants," that statement is true, but it is about those protocols.
What has not happened yet: SMTP AUTH — the protocol you actually use to send cold email from a Microsoft 365 mailbox — was deliberately carved out of that shutdown. Microsoft disabled it in tenants where it wasn't being used, but left it working where it was. It is still working today.
The thing most articles get wrong: Microsoft's own documentation on Basic authentication deprecation now explicitly points readers away from its old SMTP guidance, noting that the retirement timeline has been updated and directing them to the current announcement. Any article citing a hard March 2026 SMTP cutoff is quoting the superseded schedule.
Where the March 2026 date came from
The confusion is legitimate, because Microsoft did announce that date. It just isn't the live one anymore.
In the original announcement, Microsoft said Exchange Online would permanently remove support for Basic authentication with Client Submission (SMTP AUTH), and that rejection rollouts would begin in early 2026 — the March 1 date that has been copy-pasted across the internet ever since.
Then Microsoft revised it. The stated reasoning was that customers face real difficulty modernizing legacy email workflows and needed more runway, and that based on customer feedback and observed adoption progress, Microsoft was refining the timeline to give clearer milestones and more time.
The practical consequence: a large amount of content published in late 2025 and early 2026 is describing a deadline that no longer exists. Some of it has been updated. A lot of it hasn't. If you are making an infrastructure decision, check the date on whatever you are reading and check it against Microsoft's current announcement rather than a secondary source.
The real timeline, milestone by milestone
Here is the current schedule as Microsoft has published it.
Now through December 2026: nothing changes
SMTP AUTH Basic Authentication behavior remains unchanged. Username-and-password SMTP submission on smtp.office365.com:587 keeps working exactly as it does today. This is the window you have to migrate calmly.
End of December 2026: disabled by default, but re-enableable
SMTP AUTH Basic Auth gets switched off by default for existing tenants. The critical detail, and the one that most summaries drop: administrators can still turn it back on if they need to. This is a default change, not a removal. If you get caught out, you have a lever to pull while you finish migrating — unlike the 2023 shutdown, where the lever was removed entirely.
After December 2026: new tenants don't get it
Tenants created after that point won't have SMTP AUTH Basic Auth available by default at all. OAuth becomes the supported authentication method from day one. If you spin up fresh tenants for outreach domains — which many agencies do — this is the milestone that hits you first and hardest, because you cannot fall back on a setting that was never enabled.
Second half of 2027: the final date gets announced
Microsoft will announce the actual removal date for SMTP AUTH Basic Auth. Not the removal itself — the announcement of when removal happens. That is the point at which the re-enable lever eventually goes away.
What this means for planning: you have roughly four months before the default flips, and the flip is reversible. You are not in an emergency. You are on a clock, and the clock is real — the direction of travel has never changed, only the pace. Treat December 2026 as your working deadline and the 2027 announcement as the hard one.
Who is actually affected
Not everyone sending through Microsoft 365 is on the affected path. Work out which bucket you are in before you change anything.
- Affected: anything submitting mail with a username and password over SMTP. This is most cold email sequencers connecting a Microsoft 365 mailbox via "custom SMTP" or "connect via SMTP/IMAP," most internal scripts, most CRM integrations configured with an app password, and effectively every multifunction printer or scan-to-email device in the building.
- Affected: agencies running many M365 mailboxes across many tenants. The exposure scales with mailbox count, and the remediation is per-tenant. This is the group with the most work and the least visibility into it.
- Not affected: OAuth-based connections. If your tool connects Microsoft 365 through a "Sign in with Microsoft" consent flow rather than a password field, you are already on modern auth. Nothing to do.
- Not affected: Microsoft Graph. Graph has never used Basic auth. If your platform sends via Graph, this deprecation is irrelevant to you.
- Not affected: SMTP relay via connector, direct send, or High Volume Email. These submission paths remain supported and are outside the scope of the change.
The fastest way to check: look at how you connected the mailbox. If you typed a password into your sending tool, you are affected. If you clicked through a Microsoft consent screen, you are not.
Your five supported options
Microsoft lists several submission methods that survive the change. They are not equally good for cold outreach, so here is the honest ranking for outbound specifically.
Option 1: OAuth 2.0 with SMTP AUTH
The minimal-change path. You keep SMTP as the protocol and swap the credential from a password to an OAuth access token. You register an application in Microsoft Entra ID, grant it the SMTP send permission, and implement the token exchange.
Best for: teams whose sending tool already supports Microsoft OAuth. Watch out for: token refresh. Access tokens are short-lived by design. Any implementation that fetches a token once and caches it indefinitely will work perfectly in testing and then fail silently in production a few hours later. This is by a wide margin the most common self-inflicted failure in this migration.
Option 2: Microsoft Graph
Skip SMTP entirely and send via the Graph sendMail endpoint. This is Microsoft's strategic direction and the most future-proof option.
Best for: platforms that control their own sending layer. Watch out for: Graph's throttling behavior and consent management differ from SMTP, and admin consent can go stale in ways that produce confusing failures months after setup. More on that below.
Option 3: SMTP relay via connector
Configure an Exchange Online connector that accepts mail from your sending IP without per-mailbox authentication. Common for on-prem applications and appliances.
Best for: fixed-IP infrastructure sending on behalf of a domain. Watch out for: this is a poor fit for cold outreach at multi-mailbox scale, and it concentrates reputation risk onto one IP.
Option 4: High Volume Email
Microsoft's purpose-built path for bulk internal-facing mail. Watch out for: it is scoped and priced for a different job than cold outbound. Read the limits before assuming it fits.
Option 5: Move sending off Microsoft 365 entirely
Use dedicated sending infrastructure — Google Workspace mailboxes, a managed SMTP provider, or your own relay — and leave Microsoft 365 for internal mail.
Vendors selling SMTP infrastructure will tell you this is the only sane answer. It isn't; it's one answer. But it is a legitimate one, and for a specific reason that has nothing to do with authentication — which is the next section.
What actually breaks in production
We run outbound at scale across a large fleet of Microsoft 365 mailboxes, including tenants we provision ourselves. The auth migration itself is the easy part. These are the failures that actually cost us time.
Stale admin consent
An OAuth or Graph integration that was consented months ago can stop working without anyone touching it — a permission scope changes, an admin revokes and re-grants, a tenant policy shifts. The application still exists, the tokens still issue, and sends start failing in ways that don't obviously point at consent. When we audited our own tenants for this, a meaningful minority had drifted. If you migrate to OAuth or Graph, you need a recurring check that consent is still valid per tenant, not a one-time setup step.
Credential drift on newly provisioned mailboxes
When you provision mailboxes in bulk, the credential stored in your sending platform and the credential actually live on the mailbox can diverge — a reset that didn't propagate, a provisioning step that half-completed. The symptom is a batch of mailboxes silently skipped at send time rather than a loud error. Whatever path you migrate to, make sure your sending layer surfaces per-mailbox auth failures as a visible count, not a log line.
Shared mailboxes without a licence
A shared mailbox will happily accept an SMTP connection attempt and then reject the send with 535 5.7.139. The error reads like an authentication problem, so people burn hours rotating passwords and re-consenting. It usually isn't auth at all — the mailbox has no licence, or SMTP AUTH is disabled at the mailbox level. Check licensing before you debug credentials.
Per-mailbox SMTP AUTH settings overriding tenant settings
SMTP AUTH can be disabled at the tenant level and enabled per-mailbox, or the reverse. When the December default flip happens, tenants with explicit per-mailbox settings will behave differently from tenants relying on the default. Audit both levels, not just the tenant.
Should you use Microsoft 365 for cold email at all?
Worth separating from the auth question entirely, because it's the more important decision and it points a different way.
Microsoft 365 has generous published sending limits — 10,000 recipients per day on Business plans. That number is close to irrelevant for cold outreach, and treating it as any kind of guide is how domains get burned.
Our actual operating limits are far lower than most published advice, including advice we have given ourselves in older guides. They also differ depending on which of two infrastructure models you are running — a distinction almost nobody makes explicit, and the reason most published numbers are wrong for someone.
Model 1: standard provider mailboxes
Google Workspace, or properly licensed Microsoft 365 — real mailboxes on a domain you treat as a long-lived sending asset.
- 2 mailboxes per domain.
- 30 sends per inbox per day, maximum.
Ceiling: 60 cold emails per day per domain. You scale by adding domains, not by adding mailboxes to a domain or pushing a mailbox harder.
Model 2: bulk-provisioned Microsoft 365 tenants
Many mailboxes spun up across dedicated tenants. Cheaper per mailbox, but each mailbox carries far less trust, so the per-inbox volume has to drop hard to compensate.
- 50 mailboxes per domain.
- 5 sends per inbox per day, maximum.
- 1 domain = 1 tenant. Never put a second sending domain in a tenant — it ties their fates together, and a problem on one becomes a problem for both.
Ceiling: 250 cold emails per day per tenant.
The number that surprises people: 5 sends per inbox per day, not 50 or 100. The published provider cap and the safe cold-outreach volume are not the same number and not even the same order of magnitude. Volume comes from breadth — more mailboxes, more domains, more tenants — never from pushing any single mailbox harder.
The counterintuitive part: in our experience running campaigns across Google Workspace, Microsoft 365, and Zoho mailboxes, M365 sending accounts face more scrutiny from recipient-side Microsoft Defender filtering — which makes it harder to land in Outlook inboxes when you send from Outlook. Sending from the same ecosystem as your recipient does not help you the way people assume.
Picking a model: standard provider mailboxes give you more volume per mailbox and a domain worth keeping, at a higher cost per send. Bulk-provisioned tenants give you scale at low cost, but only if you respect the 5-per-inbox ceiling and keep one domain per tenant — the failure mode is treating cheap mailboxes as if they had Google Workspace trust and sending 30 from each. Whichever model you run, full SPF/DKIM/DMARC goes on every sending domain before a single message leaves it. The auth deprecation doesn't change either model. It changes how the M365 mailboxes in them connect.
So: don't let the deprecation stampede you into an infrastructure migration you didn't otherwise need. Decide the mailbox mix on deliverability grounds. Then solve auth for whatever M365 mailboxes remain.
The migration checklist
- Inventory every system that submits mail with a password. Sequencers, CRMs, scripts, form handlers, monitoring alerts, backup notifications, printers. The forgotten ones cause the outages. Exchange admin reporting will show you which mailboxes have recent SMTP AUTH activity — start there rather than from memory.
- Sort the inventory into "cold outreach" and "everything else." They have different answers. Outreach mailboxes want OAuth or a move off M365. Internal systems usually want a relay connector.
- Check whether your sending tool supports Microsoft OAuth today. Ask the vendor directly and get a version number, not a roadmap promise. Support here is genuinely uneven.
- Migrate one mailbox first and let it run for a full week. The token-refresh failure mode does not show up in a smoke test. It shows up on day two.
- Verify SPF, DKIM, and DMARC still align after the change. Switching submission path can change the envelope sender. See our SPF, DKIM, and DMARC setup guide for the alignment checks.
- Set a calendar reminder for early December 2026. Confirm every mailbox is migrated before the default flips, so you never need the re-enable lever.
- Re-check admin consent quarterly. Not once. Quarterly.
How ACA sends through Microsoft 365
ACA sends Microsoft 365 mail through Microsoft Graph rather than password-based SMTP, so the Basic auth deprecation doesn't affect campaigns running on the platform. Mailboxes connect through a Microsoft consent flow, not a password field.
Because we run this across many tenants, we also monitor the failure modes above rather than assuming setup is permanent. Consent validity is checked on an ongoing basis per tenant, not just at connect time. Mailboxes that fail authentication surface as a visible skipped count on the campaign rather than disappearing into logs — which is the difference between noticing a problem in an hour and noticing it after a week of half-sent sequences.
Authentication records get the same treatment. ACA runs a pre-flight SPF, DKIM, and DMARC check on the sending domain before a campaign goes live, and keeps checking as DNS changes.
Frequently asked questions
Did Microsoft disable Basic auth for SMTP on March 1, 2026?
No. That date came from an earlier announcement that Microsoft subsequently revised. SMTP AUTH Basic Authentication behavior remains unchanged through December 2026. Articles still citing March 1, 2026 as a completed cutoff are working from the superseded timeline.
When does Microsoft 365 SMTP Basic Auth actually stop working?
It gets disabled by default for existing tenants at the end of December 2026, with administrators still able to re-enable it. Tenants created after that date won't have it by default. Microsoft will announce the final removal date sometime in the second half of 2027.
Is SMTP AUTH itself being removed?
No — and this is the most common misunderstanding. SMTP AUTH the protocol survives. What is being retired is Basic authentication as a credential method for it. You can keep using SMTP AUTH indefinitely by authenticating with an OAuth 2.0 token instead of a password.
Will app passwords keep working?
App passwords are a Basic authentication mechanism, so they follow the same timeline. If your setup depends on an app password for SMTP, treat it as on the migration list.
Do I need to move off Microsoft 365 entirely?
Not for authentication reasons — OAuth and Graph both keep you on Microsoft 365 indefinitely. There are reasonable deliverability arguments for keeping M365 as a minority of your sending rotation for cold outreach, but that is a separate decision from this deprecation, and vendors selling SMTP infrastructure have an obvious incentive to merge the two.
What happens if I do nothing until December 2026?
Your sending stops when the default flips, and you have a recovery option: an administrator re-enables SMTP AUTH Basic Auth for the tenant while you migrate properly. That is a real safety net, but it is temporary and it will not exist forever. Planning around it is a bad trade for the amount of work involved.
Does this affect receiving mail or only sending?
This specific change is about Client Submission — sending. Basic auth for the receiving protocols (POP, IMAP, EWS, ActiveSync) was already removed back in 2023 and cannot be re-enabled by anyone.
How do I tell whether a mailbox is using Basic auth right now?
In practice, look at how the mailbox was connected to your sending tool. A password field means Basic auth. A "Sign in with Microsoft" consent screen means OAuth. For a tenant-wide view, Exchange admin reporting will show SMTP AUTH usage per mailbox, which is also the fastest way to find the systems nobody remembers configuring.