Microsoft has pushed more runway to organizations still using legacy SMTP AUTH with Basic Authentication in Exchange Online, replacing an earlier hard deadline with a clearer, staged timeline that gives admins more time to inventory, remediate, and migrate—but it also tightens defaults going forward. The Exchange Team’s Jan. 27, 2026 update makes three concrete commitments: leave behavior unchanged through December 2026;
disable SMTP AUTH Basic Authentication by default for existing tenants at the end of December 2026 (but allow administrators to re-enable it); make SMTP AUTH Basic Authentication unavailable by default for
new tenants created after December 2026 while supporting OAuth as the authentication method; and announce a final removal date in the second half of 2027. (
techcommunity.microsoft.com)
Background / overview
For years Microsoft has been phasing out Basic Authentication across Exchange Online because it transmits credentials in ways that are easy to abuse. The company completed broad removals for many Exchange protocols in 2022 but left SMTP AUTH (the protocol used for client SMTP submission—typically port 587) as the final exception. Over the last two years Microsoft published multiple timelines and admin tools to help tenants move to modern authentication (OAuth 2.0). That effort has produced toolsets and reporting inside Exchange admin interfaces and PowerShell cmdlets admins can use to find and control SMTP AUTH usage.
The new January 27, 2026 post is a refinement of previous dates (which at different times pointed to September 2025 or spring 2026 milestones). Microsoft now gives explicit
defaults that change at the end of December 2026 while promising a firm removal date will be announced in the second half of 2027. That gives up to a year of runway for many tenants to modernize without an immediate, global cutover.
Timeline breakdown — what administrators need to know
Key dates and behaviors (as announced)
- Now — December 2026: No behavioral change. SMTP AUTH Basic Authentication continues to behave according to each tenant’s current settings. (techcommunity.microsoft.com)
- End of December 2026: Existing tenants — SMTP AUTH Basic Authentication will be disabled by default. Administrators will still be able to explicitly enable SMTP AUTH for their tenant or individual mailboxes where necessary. (techcommunity.microsoft.com)
- New tenants created after December 2026: SMTP AUTH Basic Authentication will be unavailable by default. OAuth will be the supported authentication method for client submission. (techcommunity.microsoft.com)
- Second half of 2027: Microsoft will announce the final removal date for SMTP AUTH Basic Authentication, giving customers a clear end-of-life milestone to plan to. (techcommunity.microsoft.com)
How this differs from earlier public communications
Microsoft’s earlier Message Center and blog communications targeted an aggressive removal window (for example, a staged start March 1, 2026 with a completion April 30, 2026). The Jan. 27, 2026 update supersedes and softens that schedule by providing a default-disable milestone at the end of 2026 and promising a later, explicit final removal in 2027. Administrators should treat the Jan. 27 announcement as the current authoritative public guidance while continuing to monitor tenant Message Center notices that may include tenant-specific timings.
What SMTP AUTH Basic Authentication actually is — quick technical primer
- SMTP AUTH (authenticated client SMTP submission): the mechanism many applications, scripts, and devices use to send mail through Exchange Online (typically connecting to smtp.office365.com on TLS port 587). It supports both Basic Authentication (username + password) and Modern Authentication (OAuth/XOAUTH2).
- Basic Authentication: sends credentials in a way that’s easy to capture or abuse and cannot easily be combined with multi-factor authentication (MFA) or conditional access policies. That’s why Microsoft is removing Basic Authentication as an option for SMTP AUTH client submission.
- OAuth for SMTP (XOAUTH2): lets clients obtain short-lived access tokens via Microsoft identity flows rather than sending raw passwords. OAuth enables stronger controls (MFA, conditional access) and is the supported, long-term authentication path for SMTP client submission.
Who and what will be affected
This update primarily impacts non-interactive SMTP clients that historically use username/password credentials:
- Legacy applications and background scripts that perform authenticated SMTP submissions with stored credentials.
- Multifunction devices (MFPs: printers, scanners) configured to “scan to email” using a tenant mailbox and a username/password. Vendors often ship firmware that only supports Basic Authentication.
- Small appliances, bespoke line-of-business systems, or on-prem processes that can’t be easily upgraded to OAuth.
- Tenants that have left SMTP AUTH enabled globally should still expect functionality during 2026, but the default will change at end-December 2026—admins must act to avoid sudden surprises if they rely on Microsoft defaults. (techcommunity.microsoft.com)
Note:
Direct Send (sending unauthenticated to the tenant MX from a known IP) and
SMTP Relay via connectors are not the same as SMTP AUTH client submission and are not subject to removal of Basic Authentication in the same way; many organizations use those approaches for appliances and scanners as alternatives. However, each option has trade-offs (IP-based security, internal-only delivery, or connector configuration). Validate the option you intend to use for your scenario. (
techcommunity.microsoft.com)
Administrative actions — a practical runbook
The remaining 11 months of runway require an operational plan. Below is a prioritized checklist distilled from Microsoft guidance and community best practice.
1. Inventory and measure (first, non-negotiable)
- Run the SMTP AUTH Clients Submission report in the Exchange Admin Center and capture the new Authentication Protocol column to see who is still using Basic Authentication. This report was added to help migration.
- Use Exchange Online PowerShell to enumerate mailboxes and identify SMTP AUTH usage. Practical PowerShell patterns include:
- Verify organization-level enable/disable for SMTP AUTH:
- Get current value:
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
- Set tenant-level disable:
Set-TransportConfig -SmtpClientAuthenticationDisabled $true (or $false to enable).
- Find mailboxes where SMTP AUTH is enabled/disabled:
Get-CASMailbox -ResultSize Unlimited | Where-Object {$_.SmtpClientAuthenticationDisabled -eq $false} (enabled)Get-CASMailbox -ResultSize Unlimited | Where-Object {$_.SmtpClientAuthenticationDisabled -eq $ - Set a mailbox to explicitly allow SMTP AUTH:Set-CASMailbox -Identity user@contoso.com -SmtpClientAuthenticationDisabled $false`. ands to build a CSV of mailboxes and services that depend on SMTP AUTH. Administrators at larger orgs should automate the cross-reference with inventory CMDBs and device management systems. Community playbooks and operational analyses show this inventory step dramatically reduces surprises on enforcement days.
2. Categorize affected flows
- Human-owned mobile mail clients — often can move to Outlook Mobile or modern clients quickly.
- Service accounts and scripts — consider re-writing to use OAuth client credentials, daemon flows, or consolidate into a centrally managed, modern-auth-enabled service account.
- MFPs and appliances — contact vendors to confirm OAuth support or use relay options (connector, direct send, or HVE/ACS solutions). Vendors like Xerox and others have published guidance and firmware updates; coordinate with procurement/support.
3. Choose an alternative for each flow (see next section for options)
- Replace Basic-auth SMTP client submission with modern OAuth (where device/app supports it).
- Use SMTP relay via a connector, direct send, Microsoft Graph SendMail API, Azure Communication Services (ACS), or High Volume Email (HVE) when appropriate. Each has pros/cons (auth model, recipient scope, deliverability, attachment limits). Document the chosen path.
4. Pilot and validate
- Pick a pilot group (critical apps, 5–10 printers, etc.) and test OAuth flows or relays, validate logging and conditional access behavior.
- For OAuth pilots, validate token refresh, permission scopes (Microsoft Graph or SMTP XOAUTH2), and consent/privilege models. Check logs and verify Mail Submission events.
5. Migrate at scale with rollback plans
- Schedule migration waves by business priority.
- Communicate with service owners and vendors.
- Keep a temporary exception list (per-mailbox SMTP AUTH enabled) only while migrations are ongoing. Track exceptions and reduce them over time.
6. Harden and remove
- When migration is complete, turn off SMTP AUTH globally with
Set-TransportConfig -SmtpClientAuthenticationDisabled $true and remove per-mailbox exceptions. Use this final step only after validation and stakeholder sign-off.
Migration options and technical trade-offs
OAuth (recommended)
- Use XOAUTH2 for SMTP client submission or, preferably, move programmatic senders to Microsoft Graph SendMail API where possible (Graph is the future for mailbox access and offers richer telemetry, permission scopes, and better token controls). OAuth supports MFA, conditional access, and revocable short-lived tokens.
Pros:
- Stronger sccess, MFA friendly.
Cons:
- Devices and older appliances often don’t support OAuth flows. Implementing OAuth on embedded devices can be complex and vendor-dependent.
SMTP Relay via Connector / Direct Send
- SMTP Relay (connector): Appliances submit mail to a tenant connector (often IP-authenticated), which forwards mail with tenant-level routing. Good for many MFPs where OAuth isn’t available.
- Direct Send: Devices send unauthenticated to your MX from a known IP; mail only routes internally (won’t send to external recipients reliably in all setups). Both approaches sidestep username/password but require network and routing changes.
Pros:
- Minimal device changes in many cases.
Cons:
- Different security model (IP-based trust), scope and deliverability limitations; not always suitable for external recipient workflows.
High Volume Email (HVE)
- Microsoft’s HVE is designed for large internal volumes and will support Basic Authentication until September 2028, while continuing to add internal recipients focused and has specific limits and pricing considerations; it’s not a universal replacement for every Basic-auth flow. Test carefully.
Azure Communication Services (ACS) or third-party SMTP providers
- ACS or third-party mail gatewders) allow applications to send mail via token-based APIs or authenticated relay. These can act as OAuth-capable bridges for legacy apps. Evaluate cost, compliance, and deliverability trade-offs.
Practical vendor and device guidance
- Contact MFP and printer vendors early. Many vendors published firmware updates or cloud-proxy solutions that implement OAuth on behalf of embedded devices (or provide a secure token-based relay). Examples include firmware updates and vendor cloud services that act as an OAuth-capable relay. Test vendor-supplied solutions in pilots; do not assume firmware updates will be available for older hardware.
- If a vendor cannot provide OAuth support, you have three practical options:
- Move the device to an internal SMTP relay or connector with an IP-allowlist.
- Replace the device with a vendor that supports OAuth or provides a proxy service.
- Use HVE or ACS where the device’s workload and recipient scope fit the product limitations.
Risks, gotchas, and what to ions and defaults: The Jan. 27 change makes disabling the tenant default at the end of December 2026—if your tenant relies on Microsoft defaults, expect behavior to change. Don’t treat “no change now” as a license to procrastinate; use this runway for remediation. ([techcommunity.microsoft.com](https://techcommunity.microsoft.com...-online-smtp-auth-basic-authentication/bandor readiness: Many vendors will be late or will require paid updates for OAuth. Factor vendor timelines into your plan and budget for device replacement where necessary.
- Operational debt: Relying on wide per-mailbox exceptions will create ongoing security debt and increase attack surface. Exceptions should be documented, time-boxed, and audited.
- HVE constraints: HVE is not a drop-in replacement for all scenarios (internal-only emphasis, size/throughput semantics, pricing). Use it only where it matches requirements.
Quick checklist for the ne30 days:
- Inventory SMTP AUTH usage using EAC reports and PowerShell.
- Identify top 10 highest-volume or highest-risk devices/apps.
- 30–60 days:
- Pilot OAuth for the lowest-risk set (scripts, cloud apps). Coordinate vendor firmware updates for devices.
- Create a communications plan for help desk and affected users.
- 60–90 days:
- Migrate the next wave (service accounts, core appliances), reduce exceptions, update conditional access and monitoring.
- Reassess backlog vs. end-of-December 2026 default change and accelerate where necessary.
Final analysis — strengths and risks of Microsoft’s approach
Microsoft’s update balances two clear goals: accelerate stronger authentication by shifting defaults while acknowledging real-world complexity by keeping user-controllable exceptions and promising an explicit final removal date later in 2027. That approach has strengths and trade-offs.
Strengths:
- Predictable default behavior: making the default disabled reduces the security risk surface for tenants that do not actively manage protocol settings. (techcommunity.microsoft.com)
- Clear runway: a defined “disable-by-default” milestone plus a later final removal window allows large organizations time to plan and execute migrations. (techcommunity.microsoft.com)
- Multiple alternatives: Microsoft publishes alternatives (OAuth, Graph, HVE, ACS, relay/connectors), giving architects options for different device profiles and volume needs.
Risks and potential downsides:
- Operational burden on admins: the need to inventory thousands of devices, coordinate vendors, and implement OAuth or relays is non-trivial and costly—especially for organizations with heavy legacy fleets. Operational playbooks emphasize inventory-first approaches; these steps can be time-consuming.
- Vendor and device gaps: not all vendors will have OAuth-capable firmware for older gear, forcing replacements or temporary relays (and thus additional cost).
- Exception proliferation: giving admins the ability to re-enable SMTP AUTH per mailbox risks long-lived exceptions that undermine the security benefits unless strictly managed. Audit and remove exceptions aggressively.
Conclusion and recommended next moves
Microsoft’s Jan. 27, 2026 refinement to the Exchange Online SMTP AUTH Basic Authentication timeline provides valuable time—but not unlimited time. The
default changes at the end of December 2026 mean that organizations must convert fragile Basic-auth-dependent workflows into modern-auth or relay-based solutions on a planned cadence rather than by emergency triage.
Action items to finish today:
- Run the Exchange Admin Center SMTP AUTH report and the PowerShell inventory commands outlined above.
- Classify every SMTP-authenticated device/service by feasibility: OAuth-ready, relayable, or replace.
- Start pilot migrations (Graph or XOAUTH2) and vendor coordination immediately; do not wait for a final removal date announcement.
Treat the period between now and December 2026 as a firm project window: inventory, pilot, migrate, and clean up exceptions. If you need a concise technical script or a printable admin checklist tailored to your tenant size and device mix, generate one from your inventory outputs and treat it as your program’s SLA to business stakeholders.
Microsoft’s change is a sensible security move; it becomes a successful operational outcome only if administrators use the runway—starting now—to modernize email submission across their estates. (
techcommunity.microsoft.com)
Source: Microsoft Exchange Team Blog
Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline | Microsoft Community Hub