Office Copiers Can't Authenticate to Microsoft 365 Anymore: Why It Broke and How to Fix It

The Helpdesk Ticket Everyone Knows

The ticket comes in at 9:14 a.m. on a Tuesday. Reception cannot scan to email. The contracts team cannot send the signed PDFs they batched on Friday. Accounting cannot push invoice scans into the shared mailbox. The copier itself looks fine: it powers on, it copies, it prints, the touchscreen behaves. But every scan-to-email job ends with a polite, generic error. “Could not send. Please contact your administrator.”

The IT lead checks the logs. The copier is trying to authenticate to smtp.office365.com on port 587. Microsoft is rejecting it. The exact error varies by manufacturer, but the substance is the same: the username and password the copier has been using for three years no longer work, even though nothing on the copier was changed.

Nothing on the copier was changed. That is the point.

What Actually Broke

For more than a decade, Microsoft 365 (and Exchange Online before it) accepted what Microsoft now calls “basic authentication”: a username and a password sent over TLS. Copiers, label printers, line-of-business apps, scanners, and old backup software all spoke this way. SMTP AUTH on port 587 with basic auth was the universal duct tape of office IT.

Microsoft has been telegraphing the end of that era since 2019. In stages, it has:

• Disabled basic auth for Exchange protocols (EWS, IMAP, POP, ActiveSync, MAPI, RPS).
• Set SMTP AUTH to “disabled” by default for newly created Microsoft 365 tenants.
• Begun disabling SMTP AUTH on existing tenants where the protocol shows little or no use.
• Pushed administrators toward OAuth 2.0 and modern authentication for any client that needs to send through Microsoft’s servers.

The reason is straightforward and, honestly, defensible. Basic auth is a password-spray buffet. Attackers hammer smtp.office365.com with credential lists and a small percentage land. Disabling it shuts that door. The cost is that every device built before OAuth was widely available now finds itself locked out.

Most office copiers fall into that bucket. Even relatively recent multifunction printers (MFPs) often ship with firmware that supports only username and password for SMTP. Some manufacturers have released OAuth 2.0 capable firmware for newer models, but coverage is uneven, and a copier purchased in 2020 may simply never receive an update that teaches it how to do modern auth.

Why Restoring Basic Auth Is Not the Answer

It is technically possible, in some scenarios, for a Microsoft 365 admin to re-enable SMTP AUTH on a per-mailbox basis. Some IT teams do exactly that as a stopgap. We understand the temptation. It is also a bad long-term idea, for three reasons:

1. Microsoft is moving the goalposts. Each year the per-tenant exceptions get narrower, and at some point the override will be gone entirely. You are buying months, not years.
2. It reintroduces the attack surface Microsoft removed. A service account with SMTP AUTH enabled and a static password is the exact thing attackers spray.
3. It does not scale. Every new copier, every replaced device, every change of service account password becomes another ticket and another exception.

The right path is to stop sending the copier’s traffic through Microsoft 365 at all.

The Three Real Options

When an MFP can no longer authenticate to Microsoft 365, the IT team has three honest choices.

Option 1: Modernize the Device

Some copier vendors have released firmware that supports OAuth 2.0 against Microsoft 365 or Google Workspace. If the device is still in its support window and the manufacturer offers a firmware update that adds modern auth, that is the cleanest answer. The device handles its own login, Microsoft is happy, and there is no extra service in the path.

The honest limitation: most installed copiers cannot do this. The firmware does not exist, the device is out of its support window, or the OAuth flow the manufacturer implemented is awkward enough that it falls over after a token refresh. We have seen plenty of “modern auth capable” copiers that work for two weeks and then quietly break.

Option 2: Run an Internal SMTP Relay

The classic enterprise pattern is to stand up an internal SMTP relay (IIS SMTP service, Postfix on a Linux VM, hMailServer, an Exchange hybrid connector, or similar). The copier sends unauthenticated to the relay on the LAN. The relay then authenticates to Microsoft 365 on the copier’s behalf, often using a connector that authorizes the relay’s IP rather than a password.

This works. It is also more infrastructure than most small and mid-sized offices want to own. You now have a server to patch, a service account to rotate, a connector to maintain, and a single point of failure that is suddenly responsible for every scan job in the building. For a 500-person office with a dedicated IT team, fine. For a 25-person office with an MSP that visits twice a month, this is the wrong shape of solution.

Option 3: Use a Hosted Outbound SMTP Relay

The third option is to point the copier at a hosted SMTP relay that is built for exactly this situation. The copier sends to the relay on port 587 with basic auth (which is what the copier already knows how to do), and the relay handles delivery onward, including any authentication, alignment, and reputation work that the receiving side requires.

This is what DuoCircle Outbound SMTP does. From the copier’s point of view, nothing exotic is happening: it is still doing the username-and-password SMTP it was designed for. From Microsoft’s point of view, the copier is no longer trying to authenticate to Microsoft 365 at all. The two problems decouple.

How the Relay Fix Actually Works

The configuration is the part most IT teams expect to be hard, and it is not.

1. Create a sending account on the relay. You get a username and a password scoped to outbound SMTP only.
2. Update the copier’s SMTP settings. Change the server name to the relay’s hostname, keep port 587, keep TLS, and replace the old Microsoft 365 credentials with the new relay credentials. The “from” address can remain a real mailbox at your domain (for example, scans@yourcompany.com) so replies still flow to a human.
3. Update SPF. Add the relay’s include: to your domain’s SPF record so receiving servers recognize the relay as an authorized sender. This step is what keeps the scan-to-email message out of the recipient’s spam folder.
4. Send a test scan. It arrives. Reception goes back to filing.

The first time you do this on a copier, it takes about fifteen minutes including the SPF change. Subsequent devices are a copy-paste of the SMTP credentials.

Where the Free Tier Fits

A small detail that matters more than it sounds: the DuoCircle Outbound SMTP free tier covers 1,000 emails per month with no credit card required. For a typical small office whose copier sends a few dozen scan-to-email jobs a day, that is enough to solve the problem permanently without a budget conversation. The paid tiers exist for higher volume, but a 25-person office with one MFP rarely needs them.

We mention the free tier not as a marketing flourish but because the most common variation of this ticket is “the copier broke and I have no budget approved this quarter.” For that scenario, the free tier is the honest answer.

Where This Fits in the Bigger Picture

Scan-to-email is one symptom of a larger pattern. As organizations finish moving to Microsoft 365 and tighten their authentication posture, every device and application that sends mail without modern auth surfaces as a small fire: the warehouse label printer, the legacy ERP, the alarm system, the network monitoring tool. The pattern of fixes is the same in every case. Either modernize the sender, run your own relay, or hand the authentication problem to a service that does it as its core job.

DuoCircle’s Deliver portfolio groups Outbound SMTP with the rest of the sending and deliverability tools, which is the right way to think about it. Scan-to-email is not really a copier problem. It is an outbound mail problem that happens to live on a copier today and will live on something else next quarter.

If you are in the middle of a Microsoft 365 migration when this ticket lands, our tenant migration team has seen this exact failure mode dozens of times. Surfacing legacy SMTP-AUTH dependencies before cutover, rather than after, is the part of the project most teams underestimate.

What to Do Today

If a copier just stopped sending scans through Microsoft 365, you have three reasonable choices and one bad one. The bad one is reopening basic auth and hoping. The reasonable ones, in order of effort:

1. Check whether the copier vendor has a firmware update that adds OAuth 2.0 support. If yes, do that.
2. If not, point the copier at a hosted SMTP relay. The free tier of DuoCircle Outbound SMTP is the fastest entry point for offices under 1,000 messages per month.
3. If you operate at enough scale to justify it, stand up an internal relay and connect it to Microsoft 365 properly.

In every case, update SPF, send a test scan, and close the ticket. The copier will work tomorrow. The next legacy SMTP device on the network is already in the queue.