One of the most common help desk tickets we now see in Sydney managed IT support is some variation of the printer cannot scan to email anymore. It usually surfaces a few weeks or months after a Microsoft 365 migration, when staff finally need to send a scanned document and discover the button on the photocopier no longer works. The cause is almost always the same, and so is the solution.
Why M365 broke scan-to-email
Microsoft completed the deprecation of basic authentication for Exchange Online for most tenants in late 2023. From a security perspective this was the right move; basic auth is a known vector for credential stuffing attacks and was being abused at scale. From an office-hardware perspective it broke every scanner, photocopier, plotter and multifunction printer that knew only how to authenticate with a plain username and password.
The device is not broken; the authentication conversation it knows how to have is no longer accepted on the other end. New firmware that supports OAuth is sometimes available for higher-end devices, but for the bulk of office hardware in the field (anything more than five or six years old), the answer is firmly no.
The patches that get attempted
In our experience the typical patch sequence in a small business goes like this. First, someone generates an M365 app password for one of the staff mailboxes and pastes it into the photocopier. That works for a few weeks until the tenant’s MFA policy is tightened, the password is rotated, or the licence is touched, at which point the photocopier silently stops sending again.
Second, someone configures the device to use direct send to the office’s M365 tenant. This works for emails sent to recipients inside the same tenant, fails for external recipients, and quietly drops messages that fail SPF or DMARC alignment.
Third, someone installs Postfix or hMailServer on the office file server as a local relay. This works in principle but adds an authenticated SMTP server inside the network that needs to be patched, monitored and audited, and most small businesses do not have the IT bandwidth to maintain it well.
By the time we get the ticket, the business has tried two of these three and is frustrated that none of them are stable.
The clean fix
The pattern that actually holds up over years is to give each affected device its own dedicated send-only SMTP credential on a purpose-built relay. This is exactly what services like Kinsoft Email are designed for: per-device username and password, plain SMTP over SSL/TLS on the ports the device understands, no mailbox to protect, no OAuth complications, no surprise breakage when Microsoft changes their authentication scheme next year.
The advantages compound. Each device’s credential can be revoked individually if the device is decommissioned or transferred. Logs sit in one place rather than scattered across the M365 audit log and the local relay’s log files. The relay handles SPF, DKIM and DMARC alignment so the resulting emails actually land in recipients’ inboxes rather than spam folders. And because the relay is purpose-built for send-only legacy devices, the operating model matches what those devices need.
What the rollout actually looks like
For a typical small business with three to five affected devices, the rollout is a single afternoon’s work. Provision a credential per device on the relay; update each device’s SMTP configuration with the new server, port, username and password; test scan-to-email from each device to an internal and an external recipient; document the configuration in the asset register. Done.
The ticket category that started this story tends to disappear from the queue after that, because the configuration is stable rather than continuously breaking.
The strategic question
There is a separate, longer-term question of whether the affected devices are at end of life and should be replaced. For a 2014 photocopier coming up to its lease end, the cheapest answer might be the new device with native OAuth. For a 2018 large-format plotter with five more good years in it, the cheapest answer is almost always the dedicated SMTP fix. The decision turns on the device, not the email problem.
The bottom line
Scan-to-email failures after M365 migration are not a sign of dying hardware. They are a sign of an authentication mismatch that has a clean, durable fix. A dedicated send-only SMTP relay with per-device credentials addresses the root cause once, rather than patching around it every few months. For any Sydney business still working around the problem with app passwords on real mailboxes, the upgrade is worth a single afternoon’s attention.