Exchange Online: Migrate SMTP AUTH from Basic Auth Before It Breaks

Client Submission via SMTP AUTH — smtp.office365.com:587 with a username and password — is the last remaining use of Basic Authentication in Exchange Online. Every other protocol (EAS, POP, IMAP, EWS, Autodiscover, Remote PowerShell) completed the transition to Modern Auth by the end of 2022. SMTP AUTH was the exception, kept alive because of the sheer number of printers, scanners, LOB applications, and scripts that depend on it.

That exception is ending. Microsoft has updated the timeline twice — most recently in January 2026 — but the direction is unambiguous: Basic authentication for SMTP AUTH will be disabled by default in existing tenants at the end of December 2026. Microsoft plans to announce the final removal date in the second half of 2027. The question is not whether you need to migrate, but which path is right for each sender in your environment.

This article covers how to find every sender still using Basic Auth, how to evaluate the four migration paths, and what to configure in Exchange Online and Entra ID. The PowerShell examples throughout the article illustrate each step — review and adapt them to your environment before running in production.

Timeline — what changes and when

• Now
  No change in behaviourSMTP AUTH Basic Auth continues to function as today for existing tenants. Use this window to complete your inventory and migration.
• End of Dec 2026
  Disabled by default for existing tenantsMicrosoft will disable Basic Auth for SMTP AUTH across existing tenants. Admins will still be able to re-enable it if needed — but the default changes. New tenants created after this date will have Basic Auth unavailable by default.
• H2 2027
  Final removal date announcedMicrosoft will announce the permanent removal date in the second half of 2027. The final removal date itself is still to be announced.

Step 1 — Find every sender still using Basic Auth

Before you can migrate anything, you need a complete picture of what is using Basic Auth today. Exchange Online provides a dedicated report for this, and you can also query it via PowerShell for bulk export.

Option A — SMTP AUTH Clients report in the Exchange Admin Center

Option B — PowerShell audit

# Connect to Exchange Online
Connect-ExchangeOnline

# Check tenant-wide SMTP AUTH setting
Get-TransportConfig | Select-Object SmtpClientAuthenticationDisabled

# Find mailboxes with per-mailbox SMTP AUTH enabled
# SmtpClientAuthenticationDisabled = False means SMTP AUTH is explicitly enabled
# Blank means the mailbox inherits the tenant-wide setting
Get-CASMailbox -ResultSize Unlimited |
    Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } |
    Select-Object DisplayName, PrimarySmtpAddress, SmtpClientAuthenticationDisabled |
    Export-Csv -Path "C:\Reports\SmtpAuthEnabled.csv" -NoTypeInformation

# Request a historical SMTP AUTH report via PowerShell
# Replace the NotifyAddress with your email
Start-HistoricalSearch `
    -ReportTitle   "SMTP Basic Auth Audit" `
    -ReportType    "SmtpCSReport" `
    -StartDate     (Get-Date).AddDays(-30) `
    -EndDate       (Get-Date) `
    -NotifyAddress "admin@contoso.com"

# In the downloaded report, look for authMethod = TlsAuthLogin (Basic Auth)
# XOAUTH2 identifies an OAuth submission. Check other workloads on the same mailbox.

Migration paths — choosing the right one

There is no single right answer. The correct path depends on whether the sending device or application can support OAuth, whether the destination is internal or external, and whether the sending volume is high or low.

Path 1 — Migrate to OAuth 2.0 with SMTP AUTH

OAuth replaces the username/password with a short-lived access token. The SMTP endpoint and port are identical — only the authentication method changes. This is the right path for applications and scripts that can be updated.

# Enable SMTP AUTH for a specific mailbox (required even when using OAuth)
Set-CASMailbox -Identity "app-sender@contoso.com" -SmtpClientAuthenticationDisabled $false

# Verify
Get-CASMailbox -Identity "app-sender@contoso.com" | Select-Object SmtpClientAuthenticationDisabled

# Register service principal for SMTP.SendAsApp (application/daemon flow)
# Run after granting admin consent in Entra ID
# Replace AppId and ObjectId with values from your app registration
New-ServicePrincipal -AppId "<AppId>" -ObjectId "<ObjectId>"

# Grant the service principal Send As permission on the mailbox
# Note: use Add-RecipientPermission for Send As, not Add-MailboxPermission (FullAccess)
# Verify the correct permission model for your OAuth flow in the official documentation:
# learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth
Add-RecipientPermission -Identity "app-sender@contoso.com" `
    -Trustee     "<ServicePrincipalObjectId>" `
    -AccessRights SendAs `
    -Confirm     $false

Path 2 — SMTP Relay via Exchange Online connector

An IP-based SMTP relay does not use credentials at all. Instead, Exchange Online accepts mail from a specific IP address (or range) over TLS and relays it on behalf of your domain. This is the recommended path for printers, scanners, and any device that cannot support OAuth and is unlikely to receive a firmware update that adds it.

Path 3 — High Volume Email (HVE) for internal notifications

If your use case is sending high-volume notifications exclusively to internal recipients, High Volume Email provides a dedicated endpoint that removes the standard Exchange sending limits and continues to support Basic Auth until September 2028. This gives you a longer migration window for applications that cannot yet support OAuth.

Path 4 — Microsoft Graph API (sendMail)

For custom applications and scripts, the Microsoft Graph sendMail endpoint is the most future-proof path — it removes SMTP entirely and uses a standard REST API call authenticated with OAuth. There is no SMTP endpoint to manage, no per-mailbox SMTP AUTH setting to maintain, and the same Entra ID app registration approach applies.

# Requires: app registration with Mail.Send (delegated) or Mail.Send (application) permission
# Replace the placeholder values with your tenant, app, and secret

$tenantId     = "<your-tenant-id>"
$clientId     = "<your-app-client-id>"
$clientSecret = "<your-client-secret>"
$fromAddress  = "notifications@contoso.com"

# Acquire access token using client credentials flow
$tokenBody = @{
    grant_type    = "client_credentials"
    scope         = "https://graph.microsoft.com/.default"
    client_id     = $clientId
    client_secret = $clientSecret
}
$tokenResponse = Invoke-RestMethod `
    -Uri    "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" `
    -Method Post `
    -Body   $tokenBody
$accessToken = $tokenResponse.access_token

# Build the message payload
$message = @{
    message = @{
        subject      = "Automated notification"
        body         = @{ contentType = "Text"; content = "This is a test message via Graph API." }
        toRecipients = @(@{ emailAddress = @{ address = "recipient@contoso.com" } })
    }
} | ConvertTo-Json -Depth 5

# Send via Graph API sendMail endpoint
Invoke-RestMethod `
    -Uri     "https://graph.microsoft.com/v1.0/users/$fromAddress/sendMail" `
    -Method  Post `
    -Headers @{ Authorization = "Bearer $accessToken"; "Content-Type" = "application/json" } `
    -Body    $message

After migration, verify each sending path

SMTP with OAuth still needs SMTP AUTH enabled. The mailbox property SmtpClientAuthenticationDisabled controls the entire SMTP AUTH protocol. Setting it to $true also stops OAuth submissions. A blank value inherits the organisation setting. An explicit mailbox setting takes precedence.

If the sender now uses OAuth over SMTP, keep its effective SMTP AUTH access enabled. Send a test from the actual device or job to an approved recipient. Confirm delivery, then look for XOAUTH2 (Modern Auth) for that sender in a fresh SMTP AUTH Clients reporting interval. Check every application sharing that mailbox. To restrict password-based submission, review the user's Exchange authentication policy for Basic authentication and pilot the change with the OAuth sender.

If all workloads using that mailbox moved off authenticated client submission, confirm delivery through the replacement route and check the next scheduled run. Record the current mailbox override and the organisation default. Only then consider disabling SMTP AUTH for that one mailbox. A connector, Graph or HVE sender needs evidence from its own route. An empty SMTP AUTH report alone cannot prove that every scheduled job was migrated.

Get-TransportConfig | Select-Object SmtpClientAuthenticationDisabled
Get-CASMailbox -Identity "app-sender@contoso.com" |
    Select-Object PrimarySmtpAddress, SmtpClientAuthenticationDisabled

For the portal steps and examples of both reporting windows, see Find SMTP AUTH Basic authentication senders in Exchange Online.

Migration checklist

• Check the current timeline before communicating deadlinesThe SMTP AUTH Basic Auth timeline has been revised multiple times. Verify the current schedule at the official Exchange Team Blog before planning or communicating to stakeholders.
• Run the SMTP AUTH Clients report and export all Basic Auth sendersExchange Admin Center → Reports → Mail flow → SMTP AUTH clients. Record the date window, export the displayed rows to CSV and filter the Authentication Protocol column for Basic Auth or TlsAuthLogin. Trace each sending account to its devices and jobs.
• For each sender, document the application/device and OAuth capabilityIdentify whether each sender is a printer/MFP, a LOB application, a script, or a service. Determine whether it supports OAuth — check vendor documentation or firmware release notes. This determines the migration path.
• Assign migration paths: OAuth, SMTP Relay, HVE, or Graph APIOAuth for applications that support it. SMTP Relay for printers and legacy devices. HVE for high-volume internal-only senders that need more time. Graph API for custom code that can switch from SMTP to REST.
• For OAuth path — register app in Entra ID and grant admin consentCreate the app registration, add SMTP.Send (delegated) or SMTP.SendAsApp (application) permission, grant admin consent. For application flow, register the service principal in Exchange Online with New-ServicePrincipal.
• For SMTP Relay — verify static IP and create inbound connectorConfirm that the sending device has a static IP. Create an inbound connector in Exchange Online with IP-based authentication and TLS enforcement. Update the SMTP server address on the device.
• Verify delivery and authentication separatelySend a unique test from each device or job. Confirm receipt or use message trace for delivery. For SMTP over OAuth, verify XOAUTH2 in the SMTP AUTH Clients report. For relay, verify the connector and the message path. Record the next scheduled run.
• Keep SMTP AUTH available for OAuth sendersCheck the effective tenant default and mailbox override. Confirm that the sender still delivers with XOAUTH2. Review all applications that share the mailbox before restricting Basic authentication with an authentication policy.
• Retire unused SMTP AUTH access by scopeConsider disabling the protocol for a named mailbox only after every workload using it has moved off authenticated client submission. Record its previous setting for rollback. Review remaining OAuth senders and all mailbox overrides before considering any organisation-wide change.