Scan to Email Stopped Working: The SMTP AUTH Change and 3 Fixes

The scan button worked on Friday. On Monday it holds the job for ninety seconds and then fails with something unhelpful printed on a two-inch screen: Authentication Error, or SMTP Server Not Responding, or just a red exclamation point. Nobody touched the copier. Nobody touched the firewall. The change happened inside Microsoft 365, and it happened on purpose.

This is one of the highest-volume support calls a small office generates, and it has one of the most commonly wrong fixes. The wrong fix takes eleven minutes: type a real employee's email address and password into the copier's SMTP settings, or point the device at a free consumer mail account and use that. The scan goes through. The ticket closes. What has actually been built is a device on a public-facing wall that can send mail as a named human being, using a password that will never be rotated, over a protocol Microsoft has spent seven years dismantling.

What Microsoft actually retired, and what is still standing

Basic authentication is the scheme where a client hands over a username and password on every connection. Exchange Online began switching it off in 2019. By October 1, 2022, Microsoft had disabled it for Exchange ActiveSync, POP, IMAP, Remote PowerShell, Exchange Web Services, Offline Address Book, Autodiscover, and Outlook for Windows and Mac. Microsoft's documentation now states plainly that basic authentication is disabled in all tenants for those protocols.

One protocol was carved out: SMTP AUTH, the authenticated client submission path that printers, scanners, alarm panels, and line-of-business apps use. That exception is closing, and the schedule has moved more than once. Microsoft originally set September 2025. It then announced gradual rejections starting March 1, 2026, reaching one hundred percent on April 30, 2026. On January 27, 2026, it revised the timeline again.

The current published plan has four milestones. Behavior stays unchanged through December 2026. At the end of December 2026, basic authentication for SMTP AUTH is disabled by default for existing tenants, with administrators still able to turn it back on. Tenants created after December 2026 will not have it available at all, and OAuth becomes the supported method. Sometime in the second half of 2027, Microsoft says it will announce the final removal date.

Read that carefully, because it matters for how urgently a copier needs attention. As of now, a device using a username and password against the Microsoft submission endpoint can still connect. What is coming is a default flip, not an immediate wall. When the wall arrives, the device will receive a specific rejection stating that basic authentication is not supported for client submission, carrying the enhanced status code 5.7.30. That string is the tell. If a scanner is throwing it, no amount of retyping the password will help.

Most Monday-morning failures are not that error yet. They are usually a 535 authentication unsuccessful, or a 5.7.57 client not authenticated to send mail, and they show up because someone enabled security defaults in Microsoft Entra ID, turned on multifactor authentication for that user, applied a Conditional Access policy blocking legacy authentication, or reset the password of the person whose credentials were sitting in the copier. Security defaults and SMTP AUTH are mutually exclusive by design. Turning on the first switches off the second.

Option one: authenticated client submission on port 587

This is the method most technicians already know. The device connects to the Microsoft submission endpoint on TCP port 587, negotiates StartTLS, and signs in to a mailbox. Port 25 also works. If the device only offers port 465, that is a signal it does not support the TLS versions Exchange Online requires.

The prerequisites are specific. The device must support TLS 1.2 or TLS 1.3, and firmware on a copier from a decade ago frequently does not. The mailbox must be licensed, not a shared mailbox with no license attached. SMTP AUTH has been disabled by default for any tenant created after January 2020, so it must be enabled deliberately, either organization-wide in the transport configuration or on the individual mailbox. The per-mailbox setting overrides the tenant setting, which is the correct way to do it: leave it off everywhere and turn it on for exactly one object.

The limits are real and published. A mailbox can send to 10,000 recipients per day and 30 messages per minute. A busy scanner in a title company or a medical office will hit the rate limit during a batch, and the messages get rejected with the expectation that the client retries. Many copiers do not retry.

Two behaviors distinguish this method. Mail sent this way lands in the mailbox's Sent Items folder, so there is a record. And it bypasses most spam filtering when destined for a mailbox inside the same organization. External delivery works normally, which is the reason this path is chosen for scanning to clients and outside counsel.

There is a permission trap. The device must send from the same address it authenticated as. If the copier authenticates as one account and sets the From header to another, the message is returned with a 5.7.60 error saying the client does not have permissions to send as this sender, unless send-as permission has been granted explicitly.

For SPF, this method is the easiest. The copier's own IP address never appears as the sending host. The message enters Exchange Online authenticated and leaves through Microsoft's outbound infrastructure, which the standard Microsoft include in your SPF record already covers. Nothing needs to be added to the DNS record.

Option two: direct send to the tenant MX endpoint

Direct send skips authentication entirely. The device points at the tenant's own MX endpoint, which follows the pattern of your domain name with dots replaced by hyphens followed by the Microsoft protection suffix, on TCP port 25. TLS is optional. There is no username, no password, and no licensed mailbox required. The From address only has to belong to an accepted domain in the tenant, and it does not need a mailbox behind it, so a scanner address with no mailbox works fine.

The constraint that ends most conversations: direct send cannot deliver to external recipients. Mail addressed to an outside consumer mailbox is rejected. Microsoft's own troubleshooting documentation lists messages not being sent to recipients outside the organization as expected behavior. If the front desk scans purchase orders to a vendor, direct send is not the answer.

What arrives is treated as anonymous mail from the internet. Every scan is filtered like a stranger's message, so SPF, DKIM, and DMARC all have to be correct or scans start landing in Junk. The SPF record must list the office's public IP address, which means the office needs a static IP from the ISP. A dynamic address that renumbers overnight silently breaks the record and, with it, deliverability.

Direct send is also being narrowed. In April 2025 Microsoft introduced an organization setting that blocks anonymous mail arriving with an envelope sender in one of the tenant's own accepted domains. It defaults to off and propagates within about thirty minutes when enabled. Blocked messages get a 5.7.68 error stating that direct send is not allowed for this organization from unauthorized sources. Microsoft has stated it plans to enable this by default for new tenants, and that those tenants will not be able to disable it. The multifunction device article carries a matching note saying most customers do not need direct send and that an option to disable it by default is being developed.

One clarification worth holding onto: the setting evaluates the envelope sender from the MAIL FROM command, not the From header the recipient sees. A device that puts the right address in one field and the wrong one in the other will behave inconsistently.

Option three: a dedicated connector for relay

The third method is an inbound connector, and it is the right answer when the device needs to send outside the organization at volume, or when it needs to send from an address that has no mailbox at all.

The device points at the same MX endpoint on port 25. The difference is that the tenant has a connector that recognizes the source and attributes the mail to the organization. Attribution can happen two ways. The preferred method is a TLS certificate whose subject or subject alternative name field contains a verified accepted domain. The alternative is source IP address. If IP validation is used, the address must be static, publicly visible, and not shared with any other organization, because that address is functioning as the credential. Microsoft states outright that dynamic IP addresses are not supported.

This path relays to the internet, is not subject to the per-mailbox recipient ceiling, and requires no license. In exchange, it gives up several things. Nothing is written to a Sent Items folder anywhere, so the only record lives in message trace and in the device's own logs. Anti-spam filtering is not bypassed. And Microsoft explicitly says relay cannot be used from a third-party hosted service such as a cloud virtual machine.

SPF here is load-bearing in a way that is easy to miss. The office IP goes into the record alongside the Microsoft include. Beyond spam scoring, there is a routing consequence: messages relayed through Microsoft 365 can be sent from a separate relay pool of IP addresses that is not published and is not part of the standard Microsoft 365 SPF record. A message avoids that pool if its outbound sender is in an accepted domain of the organization, or if SPF passes on arrival. Getting the record right keeps scans on normal outbound infrastructure instead of a pool shared with forwarded and relayed traffic.

Microsoft's suggested enforcement is softer than instinct suggests. Its guidance on direct send recommends a soft fail configuration rather than hard fail, because legitimate routing paths fall foul of strict SPF more often than administrators expect.

The trap, stated plainly

The eleven-minute fix puts a licensed user's mailbox credentials into a device in a room that vendors, temps, and cleaning crews walk through. Consider what that actually creates.

• A mailbox that sends as a named person, with every scan sitting in that person's Sent Items next to real correspondence.
• A password stored in a copier's web interface, retrievable by anyone who reaches the admin page, which on most units still has the factory default password.
• A credential that is never rotated, because rotating it breaks scanning and nobody connects the two events.
• An exception to the tenant's own security posture, since SMTP AUTH had to be enabled on that mailbox and security defaults or a legacy-auth Conditional Access policy had to be relaxed to accommodate it.
• A sender that, during an incident review, appears in message trace as a human account transmitting at odd hours from an odd place, with no one able to say why.

That last item is the expensive one. When a tenant is investigated after a compromise, an account sending mail through a path nobody documented is indistinguishable from an account an attacker is using. Hours get spent proving a copier did it.

Choosing between them without guessing

The decision comes down to three questions. Does the device send to people outside the organization? If yes, direct send is eliminated. Does the office have a static public IP and a device that can present a certificate or be pinned by address? If yes, a connector is available. Does the device support TLS 1.2 and OAuth, or can its firmware be updated to? If yes, authenticated client submission survives the December 2026 default change without further work.

For devices sending only to internal recipients, there is a fourth path worth knowing. High Volume Email uses a separate endpoint on port 587 with TLS required, uses dedicated accounts rather than user mailboxes, carries no recipient or message rate limits, and is billed per delivered recipient. It cannot deliver externally, caps messages at fifty recipients and 10 MB, and allows up to one hundred accounts per tenant. For an office where scanning means scanning to coworkers, it removes the user mailbox from the equation entirely.

Whichever path is chosen, the device should send from an address that is obviously a machine. A sender named for the scanner or the lobby copier costs nothing to create, appears in message trace as itself, and can be revoked in one action without locking a human out of email. The reason the copier stopped scanning is that Microsoft stopped accepting a password as sufficient proof of identity for an unattended device. The correct response is to stop giving unattended devices a person's identity to borrow.