ScanRelay / Guides

Scan to email after Microsoft 365 SMTP Basic auth is turned off: what to do

From the end of December 2026, printers and apps that log in to smtp.office365.com with a username and password stop sending by default. Here are the five realistic replacements, with the trade-offs vendors tend to leave out.

What exactly is changing

Microsoft's updated timeline (Exchange Team blog, January 27, 2026) says that at the end of December 2026, Basic authentication for SMTP AUTH is disabled by default in existing Exchange Online tenants. Admins can still turn it back on for the tenant or for single mailboxes. Tenants created after that date won't have it at all, and Microsoft will announce the final removal date in the second half of 2027.

Re-enabling SMTP AUTH (Set-TransportConfig -SmtpClientAuthenticationDisabled $false, or per mailbox with Set-CASMailbox) buys time for existing tenants. It isn't a plan. Microsoft has said a final removal date is coming, and SMTP AUTH won't work while Security Defaults are on anyway. To see what's still using Basic auth, run the SMTP AUTH Clients report in the Exchange admin center and check the Authentication Protocol column.

The options compared

1. Native OAuth 2.0 firmware

Pros: vendor-supported, no extra infrastructure, and mail goes out as a real mailbox. Ricoh, Konica Minolta, Xerox, Kyocera, Canon, Sharp, Brother and HP Enterprise all have OAuth firmware for at least some current models (see the brand guides below). Cons: older and entry-level models often never get it. HP says its LaserJet Pro MFPs don't support it. Each vendor's flow is different (device code, client secret, admin consent), and tokens or secrets can expire or be revoked by Conditional Access changes, password resets or long outages. Then scanning quietly stops until someone re-authorizes the device. Best for: current fleets from one vendor.

2. A local SMTP relay that sends through Microsoft Graph (ScanRelay)

The device keeps plain SMTP on your LAN, and the relay authenticates to Microsoft 365 with OAuth client credentials and sends through Graph. Pros: works with any device that can send SMTP, whatever its age or brand. Internal and external recipients both work. Mail is sent as your own mailbox, so it's saved in Sent Items and your retention and DLP rules still apply. No DNS changes are needed, and with RBAC for Applications the app can send as one mailbox only. Cons: it's one more component to run, patch and monitor. The client secret expires, so you need an alert for that. Treat the relay as critical, since if it's down, nobody can scan to email. Best for: older devices, mixed fleets, and MSPs.

3. A third-party SMTP service (SMTP2GO, SendGrid, Mailgun and similar)

Pros: quick to set up, with good delivery dashboards, and it doesn't depend on Microsoft at all. Cons: you add SPF and DKIM records for your domain. Messages don't pass through your tenant, so nothing reaches Sent Items and retention and journaling don't apply. A third party handles scanned documents, which matters for regulated data, and there's usually a per-message or monthly cost. Best for: organizations comfortable with an outside sender that want no local component.

4. Microsoft High Volume Email (HVE)

Pros: it's Microsoft's own service, needs no license per account, and still accepts Basic auth at smtp.hve.mx.microsoft:587. Microsoft has said it will support that until September 2028. Cons: it's "Internal recipients within the tenant only", so scanning to a client's or accountant's external address fails. It's billed pay-as-you-go per recipient, and Basic auth there has its own end date. Best for: scan-to-self or scan-to-colleague only.

5. Direct send, or SMTP relay through an inbound connector

Microsoft documents both. The device sends to your MX endpoint (tenant-com.mail.protection.outlook.com) on port 25. Direct send needs no credentials, but it "can't deliver email to external recipients", and many tenants now block it with Set-OrganizationConfig -RejectDirectSend $true because attackers abuse it for spoofing. Connector relay reaches external recipients, but it needs a static, unshared public IP or a TLS certificate, an SPF entry, and port 25 open outbound, which many ISPs block. Microsoft also warns that mail "can be disrupted if your IP addresses are added to a spam blocklist." Neither method saves anything to Sent Items. Best for: sites with a static IP and an admin comfortable with connectors.

A practical plan for the next three months

1. Run the SMTP AUTH Clients report and list every device and app that uses Basic auth.
2. For each device, check the vendor's OAuth list (links below). Update firmware where OAuth is supported.
3. Move everything else to a relay, or to HVE if nothing ever needs to go outside the tenant.
4. Remove per-mailbox SMTP AUTH exceptions once nothing uses them, and leave SMTP AUTH disabled.

Brand guides

Seeing 535 5.7.139 already? Read what the error means and how to fix it.

Sources

1. Microsoft Exchange Team: Updated Exchange Online SMTP AUTH Basic Authentication deprecation timeline (Jan 27, 2026)
2. Microsoft Learn: How to set up a multifunction device or application to send email using Microsoft 365
3. Microsoft Learn: Enable or disable SMTP AUTH in Exchange Online
4. Microsoft Learn: High Volume Email for Microsoft 365
5. Microsoft Exchange Team: High Volume Email, continued support for Basic Authentication and other updates
6. Practical 365: Microsoft changes strategy for High Volume Email
7. Microsoft Exchange Team: Introducing more control over Direct Send in Exchange Online
8. Office 365 for IT Pros: Microsoft introduces Reject Direct Send
9. ScanRelay on GitHub