Small Town Sysadmin
Free CJIS checklist

Tech basics

Scan-to-email and Microsoft 365: your options before Basic auth for SMTP goes away

Microsoft is turning off Basic authentication for SMTP AUTH by default at the end of December 2026. Here's what that means for copiers, scanners, and apps that send mail, and the four ways to keep them working.

Most small offices have at least one device that sends email through Microsoft 365 with a plain username and password: the copier’s scan-to-email, a UPS or NAS that sends alerts, a line-of-business app that emails reports. That setup uses SMTP AUTH with Basic authentication, and Microsoft is retiring it.

The good news is that the date moved, so there’s time to fix it properly instead of in a panic.

The current timeline

Microsoft first planned to start rejecting Basic auth for SMTP AUTH in March 2026. In January 2026 it put that on hold and published a new timeline:

  • Now through December 2026: nothing changes. Basic auth for SMTP AUTH keeps working as it does today.
  • End of December 2026: Basic auth for SMTP AUTH is turned off by default in existing tenants. Admins can still turn it back on.
  • New tenants created after December 2026: Basic auth isn’t available by default. OAuth is the supported method.
  • Second half of 2027: Microsoft plans to announce the final date when Basic auth for SMTP AUTH is removed for good.

So a device that breaks in January can be brought back by re-enabling Basic auth, but that’s a stopgap. Use the time to move each device to one of the options below.

Option 1: SMTP AUTH with OAuth

This keeps the same server and port. The device signs in to a mailbox, but with a token instead of a password.

  • Server: smtp.office365.com, port 587 (port 465 isn’t supported)
  • Encryption: TLS 1.2 or 1.3 required
  • Sends to: anyone, inside or outside your organization
  • Limits: 10,000 recipients per day, 30 messages per minute

The catch: the device or app has to support OAuth. Many newer copiers and apps have an “OAuth” or “Microsoft 365” option, or fields for a Tenant ID, Client ID, and client secret. If yours only has a username and password box, check for a firmware update before giving up on it.

If the app asks for a Tenant ID, Client ID, and secret, it’s using an app registration in Microsoft Entra. Microsoft’s steps, in short:

  1. Register the app in the Entra admin center, create a client secret, and under API permissions add Office 365 Exchange Online > Application permissions > SMTP.SendAsApp. Grant admin consent.
  2. In Exchange Online PowerShell, register the app’s service principal in Exchange. The -ObjectId is the Object ID from the Enterprise applications page, not from App registrations. Using the wrong one causes authentication to fail.
Connect-ExchangeOnline
New-ServicePrincipal -AppId <Application (client) ID> -ObjectId <Enterprise application Object ID>
  1. Give the service principal access to the mailbox it sends from:
$sp = Get-ServicePrincipal -Identity "<service principal display name>"
Add-MailboxPermission -Identity "[email protected]" -User $sp.Identity -AccessRights FullAccess

If the app sends as a different address than the mailbox it signs in to, it also needs Send As on that address (Add-RecipientPermission). Without it, messages fail with 5.7.60 SMTP; Client doesn't have permissions to send as this sender.

The mailbox also needs SMTP AUTH enabled. It’s off by default in tenants created after January 2020, and security defaults in Entra ID turn it off too. To check or enable it for one mailbox:

Get-CASMailbox -Identity [email protected] | Format-List SmtpClientAuthenticationDisabled
Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false

False means enabled, True means disabled, and blank means it follows the organization-wide setting.

Option 2: SMTP relay through a connector

For a copier that can’t do OAuth, this is usually the best fit. The device sends to your domain’s MX endpoint (something like example-com.mail.protection.outlook.com) on port 25, with no sign-in at all. Microsoft accepts the mail because an inbound connector recognizes your office.

  • The connector identifies you by a certificate (Microsoft’s recommendation) or by your office’s static public IP address. Dynamic IPs aren’t allowed.
  • Mail can go to anyone, inside or outside your organization.
  • The sender address must be in one of your domains, but it doesn’t need a mailbox or a license.
  • Add the IP to your domain’s SPF record if you use IP-based matching.
  • Your internet provider must not block outbound port 25.

Option 3: Direct send

Direct send also uses your MX endpoint on port 25 with no sign-in and no connector, but it can only deliver to mailboxes in your own Microsoft 365 organization. Mail to outside addresses is rejected. Microsoft recommends it only for admins willing to manage SPF, DKIM, and DMARC carefully. It can work for scan-to-yourself, but relay is usually cleaner.

Option 4: High Volume Email

High Volume Email (HVE) is a separate Microsoft 365 service for apps that send a lot of internal mail. It’s worth knowing about, but read the fine print:

  • Internal recipients only. HVE accounts can’t send outside your organization.
  • It needs no Microsoft 365 license, but it’s pay-as-you-go: each HVE account needs a billing policy tied to an Azure subscription before it can send.
  • It uses smtp.hve.mx.microsoft on port 587 with TLS and supports both OAuth and Basic auth.

For a copier that only scans to staff, it’s an option. For anything that emails customers or vendors, it isn’t.

Which one to pick

  • Device supports OAuth: Option 1.
  • Device only does username and password, and you have a static IP: Option 2.
  • Only ever sends to your own staff and you’d rather not build a connector: Option 3 or 4.

Whatever you choose, make a list now of every device and app that sends through Microsoft 365, and test each change before the end of December.

Sources

All articles