What breaks when Microsoft 365 turns off SMTP AUTH Basic auth

A risk assessment of the systems that stop sending email when Basic authentication for SMTP AUTH is disabled — by default at the end of December 2026, per Microsoft's updated deprecation timeline.

For the timeline itself and the full list of migration options, see EXCHANGE-ONLINE-SMTP-AUTH.md. This page is about inventory: finding the things in your environment that will quietly stop working.

Why this is easy to miss

The systems most at risk share a nasty property: they only send email when something is already wrong. A backup failure alert, a UPS on battery, a disk in a NAS degrading, a monitoring alarm. Nobody notices they've stopped working until the day one of them needed to reach you and didn't.

Scan-to-email breaks loudly — a user complains the same morning. Alerting breaks silently, and you find out during the incident it should have warned you about.

Find your exposure first

Before auditing devices one by one, ask Exchange Online who is actually still using SMTP AUTH. The report covers the last 90 days:

Connect-ExchangeOnline
# Which mailboxes still have SMTP AUTH enabled?
Get-CASMailbox -ResultSize Unlimited |
  Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } |
  Select-Object DisplayName, PrimarySmtpAddress

# Tenant-wide setting ($false here means SMTP AUTH is allowed)
Get-TransportConfig | Select-Object SmtpClientAuthenticationDisabled

The snippet above misses one case on purpose kept simple: a mailbox whose SmtpClientAuthenticationDisabled is $null inherits the tenant setting, so it is fully exposed whenever the tenant allows SMTP AUTH — and filtering on -eq $false never shows it. Find-SmtpAuthExposure.ps1 handles all three states, counts them separately and can export a CSV to hand to whoever owns the devices. It is read-only.

Microsoft also exposes a SMTP AUTH client submission report in the Exchange admin center (Reports → Mail flow) showing which clients and IPs have authenticated recently — that's usually the fastest way to find the forgotten device nobody remembers configuring.

Confirmed affected — vendors have published advisories

These aren't predictions; the vendor or a support channel has documented the breakage publicly.

System	Evidence	Quick fix notes
Ricoh multifunction printers	Official advisory listing affected products and firmware status	Gist
Konica Minolta / DEVELOP ineo MFPs	Vendor advisory listing affected models across 10 product groups — and, notably, a set marked "N/A": no OAuth firmware planned (ineo 306/7228/266, ineo+ 266/256/226, ineo 4750/4050, ineo 4700P/3301P/4000P, ineo 165/185 variants). For those, the vendor itself suggests a different mail service.	Update firmware if your model is in a supported group. If it's on the "N/A" list, firmware won't save it — see devices that will never get OAuth firmware for the full list and the options that remain.
Xerox printers and MFPs	Vendor advisory — names Scan to Email, Internet Fax (Send), Fax Forward to Email and Auto Email Notifications as affected. OAuth firmware exists for the supported list (Device Code Flow broadly; Client Credentials Flow only on ConnectKey models such as VersaLink B415/C415, B620/C620, B625/C625, AltaLink and PrimeLink). Devices off that list are the problem cases.	Check your model against Xerox's supported-firmware list first — no hardware change is needed if it's there. If it isn't, change the SMTP settings.
Microsoft Dynamics NAV / Business Central	Vendor guidance for affected installs	Follow the linked guidance for your version; older on-prem NAV installs generally need their SMTP account repointed at a relay.
Laserfiche workflows	Community thread — workflow emails failing	Gist
ManageEngine OpManager	Vendor fix guide for the SMTPClientAuth error	Gist
Cerberus FTP Server	Support article on the exact 535 5.7.139 error	Gist
Fax servers (e.g. Faxination)	Vendor timeline notice	Apply the vendor's update if one exists for your version; otherwise repoint the outbound SMTP account.
Cisco Unity Connection	Named in Microsoft's own deprecation docs	Check your release for OAuth support first; if it has none, repoint the SMTP notification settings at a relay.
Microsoft Teams Rooms	Named in Microsoft's docs as needing modern auth enabled	Enable modern auth on the resource account — this one is Microsoft's own product, so no relay is needed.
QNAP NAS	QNAP's own notification settings don't support OAuth for Microsoft 365 SMTP, only username/password	Gist
Veeam (older versions)	Veeam docs — some versions support only SMTP basic auth; newer ones added OAuth	Gist
Kyocera "Send Error 1102"	Kyocera's device-side code for an SMTP auth failure	Gist
Generic 535 5.7.3 from smtp.office365.com	Same root cause, different wording	Gist

Categories to audit

Whether a specific unit breaks depends on two things: can its firmware do OAuth 2.0, and has your admin re-enabled Basic auth as a stopgap. Older and cheaper hardware overwhelmingly cannot do OAuth and never will.

Printers, scanners, MFPs — the largest group

Scan-to-email on Ricoh, Canon, Konica Minolta, Xerox, Sharp, Kyocera, Brother, HP, Epson, Lexmark. Devices more than a few years old rarely get firmware adding OAuth. See PRINTERS.md for per-brand settings.

Storage and infrastructure hardware

NAS units (QNAP, Synology, TrueNAS), UPS monitoring (APC PowerChute and similar), RAID controller alerts, IPMI/iDRAC/iLO out-of-band notifications, switch and firewall alerting. This is the silent-failure category — these only email you when hardware is already failing.

Backup and disaster recovery

Veeam, Acronis, Macrium, Bacula, Nakivo, and custom backup scripts. A backup job that fails silently for months is materially worse than one that fails loudly on day one.

Monitoring and alerting

Nagios, Zabbix, PRTG, Icinga, LibreNMS, ManageEngine, Checkmk. Same silent failure mode, and often the very system meant to catch the others.

Line-of-business and legacy applications

ERP and accounting (Dynamics NAV/BC, Sage, older SAP integrations), document management (Laserfiche and similar), ticketing and helpdesk, HR and payroll systems, hospital/lab/school information systems. Frequently vendor-locked, out of support, or maintained by someone who left years ago.

Web applications and self-hosted software

WordPress with an SMTP plugin, WooCommerce order mail, Nextcloud, GitLab, Jenkins, Grafana alerts, Zabbix, Home Assistant, phpBB, and any in-house app whose mail config is a hardcoded username and password.

Scripts and automation

PowerShell using Send-MailMessage (itself deprecated), Python smtplib, cron jobs, scheduled tasks, database jobs (SQL Server Database Mail), CI/CD pipelines. Usually the easiest to fix — someone can edit the code — but also the easiest to forget, because they're not in any asset inventory.

Physical security and building systems

Alarm panels, camera/NVR motion alerts, access control, environmental sensors in server rooms. Old, rarely touched, and often the last thing anyone thinks to audit.

Practical triage

1. Run the PowerShell audit above and pull the SMTP AUTH client submission report — start from what's actually authenticating, not from memory.
2. Sort by silent vs. loud. Anything whose only job is to warn you (backups, monitoring, UPS, hardware alerts) goes first, because its failure hides itself.
3. Check firmware/version support for OAuth per device. If the vendor has no OAuth path, no amount of planning changes the outcome — it needs a different relay.
4. Pick a route per system from the five options in EXCHANGE-ONLINE-SMTP-AUTH.md.
5. Test before December, not after. Re-enabling Basic auth is available until then and buys planning time, but it is not a fix.

Where ZeroSMTP fits — and where it doesn't

ZeroSMTP accepts ordinary SMTP AUTH (username + password over TLS), so for a device with no OAuth path it's a three-field change: server, port, credentials. Nothing else about the device changes.

It fits the silent-alert category well: NAS and UPS notifications, backup job results, monitoring alarms, scan-to-email inside an organization, homelabs, schools and small offices with no budget for a paid relay. For those, what matters is that the message arrives at all — the sender address is irrelevant.

It does not fit anything customer-facing, anything that must come from your company domain, anything above roughly 200 messages a day, or regulated environments where sender identity is auditable. For those, use OAuth/Graph, a Direct Send connector, your own relay, or a paid service — all covered in the migration guide, which recommends them over this project where they're the better answer.

Test the network path first with check-connection.sh — corporate firewalls often block outbound 587/465 to a new host, which looks identical to an authentication problem.