SMTP Basic Auth Retirement: The IT Helpdesk Migration Guide for Exchange Online

Microsoft is pulling the plug on Basic Authentication for SMTP AUTH Client Submission in Exchange Online. The phased rollout kicks off March 1, 2026, with full enforcement by April 30, 2026. After that date, any application or device still sending email via smtp.office365.com with a plain username and password will get hit with a permanent rejection: 550 5.7.30 Basic authentication is not supported for Client Submission. No retry, no queue, no second chances—the email is just gone.

So yeah, this one's kind of a big deal.

This guide walks IT helpdesk teams through every step of the migration: auditing affected systems, picking the right replacement path, configuring OAuth 2.0 for SMTP AUTH, dealing with those stubborn multifunction printers, and making sure everything actually works before the deadline hits.

Why Microsoft Is Killing Basic Auth for SMTP

Basic Authentication sends usernames and passwords in plain text (well, Base64-encoded, but that's trivially decoded—it's barely a speed bump for anyone snooping). This makes it a magnet for credential harvesting, replay attacks, brute-force attempts, and phishing campaigns.

Microsoft already retired Basic Auth for EAS, POP, IMAP, EWS, and PowerShell back in October 2022. SMTP AUTH Client Submission was the last holdout—and its time has finally come.

The retirement falls under Microsoft's broader Secure Future Initiative. OAuth 2.0 replaces static credentials with short-lived tokens (60 minutes by default) that are revocable, scoped to specific permissions, and fully compatible with MFA and Conditional Access policies. It's a genuinely better approach to auth, even if the migration is a headache.

Key Dates: The SMTP Basic Auth Retirement Timeline

Date	What Happens
March 1, 2026	Microsoft begins rejecting a small percentage of Basic Auth SMTP submissions (phased rollout starts)
April 30, 2026	100% rejection of Basic Auth for SMTP AUTH Client Submission—no exceptions
End of December 2026	Basic Auth for SMTP AUTH disabled by default for all existing tenants
January 2027+	New tenants cannot use Basic Auth for SMTP AUTH at all
H2 2027	Microsoft announces the final drop-dead removal date

Important: That phased rollout starting March 1 means your systems could begin failing at any point. Don't wait until April—start migrating now.

What's Actually Affected (And What Isn't)

Affected: SMTP AUTH Client Submission

Any application or device connecting to smtp.office365.com on port 587 that authenticates with a username/password pair is affected. The usual suspects include:

• Multifunction printers and scanners using scan-to-email
• Line-of-business applications sending notifications, alerts, or reports
• Custom scripts (PowerShell, Python, etc.) that fire off emails via SMTP
• CRM and ERP systems (Dynamics, SAP, Business Central) with email integration
• Monitoring tools (Nagios, PRTG, Zabbix) sending alert emails
• Legacy web applications with contact forms or automated emails

Not Affected

• SMTP Relay via Connector (Option 2): Uses an inbound connector authenticated by IP address, not per-message Basic Auth. If you're sending from a static IP through a connector, you're fine.
• Direct Send (Option 3): Uses the MX endpoint on port 25 with no authentication at all. Not affected.
• Microsoft Graph API: Already uses OAuth. Nothing to change here.

Step 1: Audit Your Environment—Find Every Basic Auth Sender

Before you migrate anything, you need a complete inventory of every system using Basic Auth SMTP. I can't stress this enough—the systems you forget about are the ones that'll break at 2 AM on a Monday.

Microsoft provides a built-in report for this, thankfully.

Use the SMTP AUTH Report in Exchange Admin Center

1. Sign in to the Exchange Admin Center at https://admin.exchange.microsoft.com
2. Navigate to Reports > Mail flow > SMTP AUTH clients report
3. Review the report—it now distinguishes between Basic Auth and OAuth connections (this was updated in October 2024)
4. Export the data and note every sender address, message count, and authentication type

PowerShell: Check SMTP AUTH Status per Mailbox

Run the following to see which mailboxes currently have SMTP AUTH enabled:

Connect-ExchangeOnline

# List all mailboxes with SMTP AUTH status
Get-CASMailbox -ResultSize Unlimited | Select-Object DisplayName, PrimarySmtpAddress, SmtpClientAuthenticationDisabled | Export-Csv -Path "C:\Temp\SmtpAuthStatus.csv" -NoTypeInformation

Mailboxes where SmtpClientAuthenticationDisabled is (or blank, meaning it inherits the org default) have SMTP AUTH enabled and could be in use.

Check Organization-Wide SMTP AUTH Setting

Get-TransportConfig | Select-Object SmtpClientAuthenticationDisabled

If this returns , SMTP AUTH is disabled at the org level, and only mailboxes explicitly set to can use it.

Step 2: Choose Your Migration Path

Microsoft offers five alternatives to Basic Auth SMTP. The right one depends on what you're migrating and who the recipients are.

Option	Best For	Recipients	Auth Method
OAuth 2.0 for SMTP AUTH	Apps and devices that support OAuth	Internal + External	OAuth 2.0 (XOAUTH2)
Microsoft Graph API	Custom apps, modern integrations	Internal + External	OAuth 2.0
High Volume Email (HVE)	Bulk internal notifications (HR, IT alerts)	Primarily Internal (up to 100K/day); External limited to 2K/day	OAuth 2.0
Azure Communication Services	Transactional/marketing email at scale	Internal + External (millions/hour)	Azure SDK / REST API
SMTP Relay via Connector	Devices that can't support OAuth (printers, legacy hardware)	Internal only (or external with connector config)	IP-based (no per-message auth)

Step 3: Migrate Applications to OAuth 2.0 SMTP AUTH

This is the most common migration path for line-of-business apps and scripts. You'll still use SMTP AUTH on port 587, but authenticate with OAuth tokens instead of a password. Honestly, once you've done it a couple times, it's not that bad.

3a. Register an Application in Microsoft Entra ID

1. Go to Microsoft Entra Admin Center > Applications > App registrations > New registration
2. Give it a descriptive name (something like SMTP-OAuth-ScanToEmail)
3. Set Supported account types to “Accounts in this organizational directory only”
4. Click Register
5. Copy the Application (client) ID and Directory (tenant) ID from the Overview page—you'll need both later

3b. Add API Permissions

1. In your app registration, go to API permissions > Add a permission
2. Select the APIs my organization uses tab
3. Search for Office 365 Exchange Online
4. Select Application permissions
5. Check SMTP.SendAsApp
6. Click Add permissions
7. Click Grant admin consent and confirm

3c. Create a Client Secret

1. Go to Certificates & secrets > New client secret
2. Set an expiration (24 months max is recommended)
3. Click Add
4. Copy the secret value immediately—you won't see it again after leaving the page

Pro tip: Set a calendar reminder for the secret's expiration date. When it expires, your email sending will silently stop working, and you'll spend an hour troubleshooting before realizing the secret just expired. Ask me how I know.

3d. Register the Service Principal in Exchange Online

This step is required and it's the one people miss most often. The Entra app registration alone isn't enough—you also need to register the service principal in Exchange Online via PowerShell.

# Connect to Exchange Online
Install-Module -Name ExchangeOnlineManagement -Force
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline

# IMPORTANT: Use the Object ID from Enterprise Applications, NOT App Registrations
# Find it at: Entra Admin Center > Enterprise Applications > [Your App] > Overview > Object ID

New-ServicePrincipal -AppId "<Application-Client-ID>" -ServiceId "<Enterprise-App-Object-ID>"

This is critical: The Object ID in App registrations is different from the Object ID in Enterprise Applications. You must use the one from Enterprise Applications. Getting these mixed up is the #1 cause of OAuth SMTP failures, and it trips up even experienced admins.

3e. Grant Mailbox Permissions

# Grant the service principal full access to the sending mailbox
Add-MailboxPermission -Identity "[email protected]" -User <Enterprise-App-Object-ID> -AccessRights FullAccess

3f. Enable SMTP AUTH on the Sending Mailbox

Here's something that catches people off guard: even with OAuth fully configured, SMTP AUTH still needs to be explicitly enabled on the mailbox itself.

# Enable SMTP AUTH for the specific mailbox
Set-CASMailbox -Identity "[email protected]" -SmtpClientAuthenticationDisabled 

# Verify the setting
Get-CASMailbox -Identity "[email protected]" | Format-List SmtpClientAuthenticationDisabled
# Should return: False

3g. Update Your Application Code

Your application now needs to obtain an OAuth token and use it for SMTP authentication. Here's a Python example using the client credentials flow:

import requests
import smtplib
import base64
from email.mime.text import MIMEText

# Step 1: Get OAuth token
tenant_id = "your-tenant-id"
client_id = "your-client-id"
client_secret = "your-client-secret"

token_url = f"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
token_data = {
    "grant_type": "client_credentials",
    "client_id": client_id,
    "client_secret": client_secret,
    "scope": "https://outlook.office365.com/.default"
}

response = requests.post(token_url, data=token_data)
access_token = response.json()["access_token"]

# Step 2: Build the XOAUTH2 string
sender = "[email protected]"
auth_string = f"user={sender}\x01auth=Bearer {access_token}\x01\x01"
auth_bytes = base64.b64encode(auth_string.encode()).decode()

# Step 3: Send via SMTP with XOAUTH2
msg = MIMEText("This is a test email sent via OAuth 2.0.")
msg["Subject"] = "OAuth SMTP Test"
msg["From"] = sender
msg["To"] = "[email protected]"

server = smtplib.SMTP("smtp.office365.com", 587)
server.ehlo()
server.starttls()
server.ehlo()
server.docmd("AUTH", f"XOAUTH2 {auth_bytes}")
server.sendmail(sender, ["[email protected]"], msg.as_string())
server.quit()

And here's the PowerShell equivalent (this one uses Microsoft Graph instead of raw SMTP, which is honestly a smoother experience):

# Get OAuth token
 = "your-tenant-id"
 = "your-client-id"
 = "your-client-secret"

 = @{
    grant_type    = "client_credentials"
    client_id     = 
    client_secret = 
    scope         = "https://outlook.office365.com/.default"
}

 = Invoke-RestMethod -Uri "https://login.microsoftonline.com//oauth2/v2.0/token" -Method Post -Body 
 = .access_token

# Send email using Microsoft Graph API (alternative to raw SMTP)
 = @{
    message = @{
        subject = "OAuth Test Email"
        body = @{
            contentType = "Text"
            content = "This email was sent using OAuth 2.0 authentication."
        }
        toRecipients = @(
            @{ emailAddress = @{ address = "[email protected]" } }
        )
    }
} | ConvertTo-Json -Depth 5

 = @{
    Authorization = "Bearer "
    "Content-Type" = "application/json"
}

Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/users/[email protected]/sendMail" -Method Post -Headers  -Body 

Step 4: Handle Multifunction Printers and Scanners

Alright, let's talk about the real pain point. Multifunction printers and scanners are almost always the last devices clinging to Basic Auth SMTP for scan-to-email. If you work a helpdesk, you already know these things are going to generate the most tickets.

Option A: Update Firmware to Support OAuth 2.0

The good news is that most major manufacturers have released (or are releasing) firmware updates with OAuth 2.0 support:

Manufacturer	OAuth Support	Minimum Firmware
Xerox	Yes (Device Code Flow + Client Credentials Flow)	Check Xerox support portal for your model
HP	Yes	FutureSmart 5.7 or newer
Lexmark	Yes	FW24 firmware
Canon	Yes (select models)	Check Canon product docs for OAuth config
Sharp	Newer models only	Contact Sharp support
Konica Minolta	Limited	GP4-Q6 firmware (specific models)

Check with your vendor or their support portal to confirm whether your specific model supports OAuth and which firmware version you'll need.

Option B: SMTP Relay via Connector (For Devices Without OAuth Support)

If your printer or scanner simply can't do OAuth (and let's be honest, a lot of older ones can't), use SMTP Relay through an Exchange Online connector. This authenticates by IP address rather than per-message credentials, so the Basic Auth retirement doesn't touch it.

1. In the Exchange Admin Center, go to Mail flow > Connectors
2. Create a new connector: From: Your organization's email server > To: Office 365
3. Configure it to authenticate by the sending server's IP address
4. On your printer/scanner, configure SMTP to point to your MX endpoint (e.g., yourdomain-com.mail.protection.outlook.com) on port 25
5. No username or password needed on the device itself

One limitation to keep in mind: SMTP Relay with a connector can only send to recipients within your organization by default. For external recipients, you'll need to configure the connector with appropriate TLS certificate validation.

Option C: Third-Party Print Management

Solutions like PaperCut, uniFLOW, or YSoft SafeQ can sit between your MFP and Exchange Online, handling the OAuth authentication on behalf of the device. It's another moving part, but it works well when you've got a fleet of older printers that aren't getting firmware updates.

Step 5: Test Before the Deadline

Don't assume your migration worked. Seriously, test every single migrated system.

Testing Checklist

• Send a test email from each migrated application or device
• Verify the email actually arrives in the recipient's inbox (and check spam/junk folders—you'd be surprised how often this gets skipped)
• Check the SMTP AUTH report in EAC to confirm the connection now shows as OAuth instead of Basic
• Test token renewal—wait for the token to expire (60 minutes) and confirm the application grabs a new one automatically
• Test failover scenarios: what happens if the token endpoint is temporarily unreachable?
• Document the test results for each system

Proactively Disable Basic Auth to Validate

Once you're confident all systems have been migrated, you can proactively disable Basic Auth on the sending mailbox to simulate the post-deadline environment:

# Temporarily block Basic Auth at the org level to test
# WARNING: This will break any remaining Basic Auth senders
Set-TransportConfig -SmtpClientAuthenticationDisabled 

# After testing, re-enable if needed (before the deadline)
Set-TransportConfig -SmtpClientAuthenticationDisabled 

This is a great way to flush out anything you missed. Just make sure you do it during a maintenance window, not at 9 AM on a Tuesday.

Step 6: Monitor and Maintain Post-Migration

Here's the thing most guides won't tell you: migration isn't a one-and-done event. OAuth introduces ongoing maintenance that Basic Auth never required.

Client Secret Expiration

Client secrets expire (24 months max). You need a process for tracking this:

• Create calendar reminders 60 and 30 days before expiration
• Document the renewal procedure in your IT runbook
• Consider using certificates instead of client secrets—they offer higher security and longer validity periods

Conditional Access Policies

OAuth tokens are subject to your Conditional Access policies. If you add new policies (location-based, device-based, etc.), they could inadvertently block your service principal. Always test new policies against your SMTP OAuth app before enforcing them broadly.

Ongoing SMTP AUTH Monitoring

Keep checking the SMTP AUTH report monthly. New Basic Auth senders can pop up when someone sets up a new application or plugs in a new device without checking with IT first (shadow IT is real, and it never takes a day off).

Troubleshooting Common OAuth SMTP Errors

When things go wrong—and they will—here's a quick reference for the most common errors:

Error	Cause	Fix
550 5.7.30 Basic authentication is not supported	Still using Basic Auth after enforcement	Switch to OAuth 2.0 or use SMTP Relay via Connector
535 5.7.139 Authentication unsuccessful	Wrong Object ID used when creating service principal	Use Object ID from Enterprise Applications, not App Registrations
535 5.7.3 Authentication unsuccessful	SMTP AUTH disabled on the mailbox	Run Set-CASMailbox -Identity <mailbox> -SmtpClientAuthenticationDisabled
AADSTS7000215: Invalid client secret	Client secret expired or incorrect	Create a new client secret in Entra ID and update the application
AADSTS700016: Application not found	Wrong Application ID or tenant ID	Verify IDs match what's in Entra Admin Center
Email sends but lands in spam	SPF/DKIM/DMARC misconfiguration	Verify DNS records for your sending domain

Helpdesk Ticket Template: Basic Auth SMTP Migration

Here's a template you can use when a user or department reports scan-to-email or application email failures after enforcement day. Feel free to adapt it to your ticketing system:

Subject: [SMTP Auth Migration] - [Department/System Name]

1. AFFECTED SYSTEM
   - System Name: _______________
   - Type: [ ] Printer/Scanner  [ ] Application  [ ] Script  [ ] Other
   - Current SMTP Server: smtp.office365.com
   - Sending Mailbox: _______________

2. DIAGNOSIS
   - Error Message: _______________
   - Authentication Type in EAC Report: [ ] Basic  [ ] OAuth  [ ] Not shown
   - SMTP AUTH Enabled on Mailbox: [ ] Yes  [ ] No

3. MIGRATION PATH
   - [ ] OAuth 2.0 (app supports it)
   - [ ] SMTP Relay via Connector (device cannot support OAuth)
   - [ ] Microsoft Graph API
   - [ ] Azure Communication Services
   - [ ] High Volume Email

4. RESOLUTION
   - Steps Taken: _______________
   - Verified Working: [ ] Yes  [ ] No
   - Token Expiration Date: _______________

Frequently Asked Questions

Will Microsoft grant extensions for SMTP Basic Auth after April 2026?

No. Microsoft has been very clear: no exceptions after the final enforcement date. Support can't re-enable Basic Auth once it's been disabled. The phased rollout starting March 1 gives you a testing window, but treat the April 30 date as a hard wall.

Does this affect SMTP Relay or Direct Send?

Nope. SMTP Relay (using an Exchange Online connector authenticated by IP address) and Direct Send (using the MX endpoint on port 25, no authentication) are both unaffected. Only SMTP AUTH Client Submission on port 587 with username/password is being retired.

How do I find out which devices and apps are using Basic Auth SMTP?

The SMTP AUTH clients report in the Exchange Admin Center (under Reports > Mail flow) is your best friend here. Since October 2024, it distinguishes between Basic Auth and OAuth connections. You can also use PowerShell with Get-CASMailbox to check which mailboxes have SMTP AUTH enabled, then cross-reference that with your IT asset inventory.

My printer doesn't support OAuth. What are my options?

You've got three paths: (1) Check with your manufacturer for a firmware update—most major vendors like HP, Xerox, Lexmark, and Canon have released updates for newer models. (2) Switch to SMTP Relay via an Exchange Online connector, which authenticates by IP and isn't affected by the Basic Auth retirement at all. (3) Use a third-party print management solution like PaperCut or uniFLOW that handles OAuth on behalf of the device.

What happens to emails sent with Basic Auth after enforcement?

They're permanently rejected with error code 550 5.7.30. This is a 5xx permanent error—the sending server won't retry. The emails aren't queued, deferred, or stored anywhere. They're simply lost. That's exactly why testing before the deadline matters so much.