Action pack #001 Action needed

SMTP AUTH Basic Auth goes off by default at the end of December 2026

Microsoft will disable Basic authentication for SMTP AUTH by default in existing Exchange Online tenants at the end of December 2026. Scan-to-email copiers and older line-of-business apps are the usual casualties. Find them now, while there's time to fix them before the holidays.

Microsoft deadline
End of December 2026
Who's affected
Tenants where devices/apps use SMTP AUTH with a password
Effort per tenant
~30 min discovery, plus remediation
Facts verified
Oct 19, 2026

The short version

Microsoft's Exchange team updated the SMTP AUTH Basic Authentication timeline on January 27, 2026. Here is what it says:

WhenWhat Microsoft says happens
Now to December 2026SMTP AUTH Basic Authentication behavior stays the same.
End of December 2026SMTP AUTH Basic Authentication is disabled by default for existing tenants. Admins can still turn it back on if they need to.
New tenants created after December 2026SMTP AUTH Basic Authentication is unavailable by default. OAuth is the supported method.
Second half of 2027Microsoft announces the final removal date.

Why this matters to MSPs: SMTP AUTH is the one Exchange Online client protocol where Microsoft hasn't already switched Basic auth off, and it mostly lives in places nobody looks: the copier in the back office, the accounting system that emails statements, the camera NVR that sends alerts. When it stops working, the first sign is usually a client ticket that says "scanning is broken." The re-enable switch buys time, but Microsoft has already said a final removal date is coming.

Who's affected

Affected: existing Exchange Online tenants where a device or application sends mail through smtp.office365.com (port 587 or 25) using a mailbox username and password. That's client SMTP submission (SMTP AUTH) with Basic auth. POP3 and IMAP4 clients also use SMTP AUTH to send. Microsoft's post says the timeline applies to tenants in all cloud environments.

Usually not affected (per Microsoft Learn):

  • Tenants with security defaults on. SMTP AUTH Basic is already incompatible with security defaults.
  • Devices and apps already using OAuth for SMTP AUTH.
  • Devices that send through an SMTP relay connector (certificate or static IP) or Direct Send. Neither uses SMTP AUTH.
  • Normal Outlook clients. Microsoft notes that virtually all modern mail clients don't use SMTP AUTH to send.

What to do, in order

  1. Run the read-only script (below) against each client tenant. It reports the org-wide SMTP AUTH setting, mailboxes where SMTP AUTH is explicitly turned on, authentication policies, security defaults, and, if the tenant has Entra ID P1/P2, which accounts actually signed in with SMTP AUTH recently.
  2. Check the usage report. In the Exchange admin center, go to Reports > Mail flow > SMTP AUTH Clients report. Its Authentication Protocol column shows Basic Auth or Modern Auth for each sender. The report covers up to 90 days.
  3. Inventory every sender: device or app, location, owner, vendor, and firmware version.
  4. Pick a replacement path for each one (table below).
  5. Tell the client using the notice template, and get approval for billable work.
  6. Schedule and test before the holiday freeze. Then check for send failures in the first business week of January 2027.

Detection script (read-only)

Get-SmtpAuthBasicReadiness.ps1 sends only Get-* cmdlets and Graph GET requests to the tenant (plus the connect/disconnect calls), and writes CSVs and a summary.txt to a local folder. It changes nothing in the tenant.

# One-time: install the modules (Graph is optional)
Install-Module ExchangeOnlineManagement -Scope CurrentUser
Install-Module Microsoft.Graph.Authentication -Scope CurrentUser

# Run it (Exchange + Graph checks, 7-day sign-in lookback)
.\Get-SmtpAuthBasicReadiness.ps1 -SignInLookbackDays 7

# Exchange-only (no Graph connection or consent prompt)
.\Get-SmtpAuthBasicReadiness.ps1 -SkipGraph

Heads-up: the first Graph connection in a tenant may ask for admin consent for the Microsoft Graph Command Line Tools app. Granting consent is a tenant change in itself. Use -SkipGraph if you'd rather not grant it. The sign-in log check needs Entra ID P1 or P2.

Here's how to read the output:

VerdictMeaning
ACTION NEEDEDMailboxes have SMTP AUTH explicitly enabled, or accounts signed in with SMTP AUTH recently. Check each one's protocol in the EAC report.
REVIEWSMTP AUTH is enabled org-wide, but no obvious senders were found. Confirm with the EAC report.
LIKELY READYNo mailboxes have SMTP AUTH explicitly enabled and SMTP AUTH is off org-wide, or security defaults are on and no SMTP AUTH sign-ins were found.

Replacement paths

These are summarized from Microsoft Learn's guidance for multifunction devices and applications.

SituationPathNotes
Device/app supports OAuthKeep SMTP AUTH, switch to OAuthLeast disruptive. Needs a firmware or app version with OAuth support.
Sends to internal recipients onlyHigh Volume Email (HVE)Microsoft recommends this for internal-only senders. HVE supports Basic or OAuth on an HVE account. It uses Microsoft 365 pay-as-you-go billing through an Azure subscription, and an HVE account can't send until a billing policy is assigned. Microsoft Learn lists it for the Worldwide cloud only. Check current pricing.
Internal + external, no OAuthAzure Communication Services Email, or an SMTP relay connector (certificate or static IP)ACS Email is the option Microsoft lists first for this case. Microsoft positions the relay connector for when the other methods don't work. A relay needs port 25 and a certificate or a static IP that isn't shared with another organization. It can't be used from third-party hosted services such as Azure, and it doesn't save to Sent Items.
On-prem Exchange/SMTP server existsRelay through itMicrosoft lists Basic auth to the on-prem server, or anonymous (not open) relay.
Legacy device, no updatesReplace itA good opportunity to quote new hardware.

Microsoft also documents Direct Send (internal-only, unauthenticated, port 25). It says most customers don't need it and that it is working on an option to disable Direct Send by default. Treat Direct Send as a last resort.

What we don't know yet

Here's what's still open as of our verification date:

  • The exact day. Microsoft says "End of December 2026" and gives no specific date. UNVERIFIED for any specific day.
  • Which setting flips. MC786329 says details will follow in a later Message Center post. We haven't found that post yet. We checked the public Message Center archive on Oct 19, 2026. Whether tenants that have explicitly enabled SMTP AUTH get changed too is UNVERIFIED.
  • New tenants. Microsoft says Basic will be "unavailable by default" for tenants created after December 2026. Whether an admin can turn it on in those tenants is UNVERIFIED.
  • The final removal date is due to be announced in the second half of 2027.

We'll update this pack, and note it in the newsletter, when Microsoft publishes more detail.

What's in the kit

  • Detection script: read-only and well commented. Run it per tenant.
  • Client notice: plain English, ready for your branding, with blanks for what you found.
  • PSA ticket: title, fields, checklist, and resolution notes. Works in any PSA.
  • Calendar file: four planning reminders (Nov 2, Nov 16, Dec 1, Jan 4) plus a Dec 31 marker for Microsoft's "end of December" date.

Sources