Scan to email is not working with Office 365

In short: scan to email fails on Microsoft 365 because basic SMTP authentication, the only kind a copier knows, is disabled by default on organisations created after January 2020 and is incompatible with Entra ID security defaults. The quick fix is to switch authenticated SMTP back on for the mailbox the device signs in with, and that takes admin rights on the tenant. What you do after that hangs on two answers: can the copier do OAuth, and do your scans go to people outside the company.

The copier down the corridor scanned to mailboxes for years without anyone thinking about it. Then one morning: an error code, and nothing goes out. Nobody has been near the machine. That is exactly what makes this one so annoying to pin down.

Start with one question: did it work last week? The two answers point to two different faults, and mixing them up costs hours.

• It worked, then stopped dead. Look at what changed on the security side, not on the machine. Multi-factor authentication, security defaults or a conditional access rule switched on in the preceding days explains the vast majority of these cases.
• It never worked on this copier, or not since a migration. Authenticated SMTP was most likely left off: it is disabled out of the box on every organisation created after January 2020.

Either way the problem sits in the tenant, not in the device. What remains to be established is whether you have the keys to it.

Getting a scan out this morning, in the meantime

A scanning outage blocks people straight away. The workaround that always works, without touching the tenant: scan to a USB stick or to an existing network folder, then send the attachment from Outlook. It is manual, it is immediate, and it holds for the day.

App passwords are often put forward as the quick patch. Before you go looking for one, know that it is not available while security defaults are switched on: the option simply does not appear. And where it is available, it still relies on basic authentication, so it will fall with it. A few weeks of respite, at best.

What message does your copier show

Copiers tell you almost nothing. Whatever shows on the panel has usually been chopped in half. The whole reply is sitting in the machine’s SMTP log, or in a bounce report that landed in somebody’s inbox and got ignored.

Message	What it actually means
535 5.7.139 Authentication unsuccessful, basic authentication is disabled	The credentials are fine. It is basic authentication that is being refused, at tenant or mailbox level
535 5.7.3 Authentication unsuccessful	Credentials rejected, or the account is blocked for sending spam
530 5.7.57 Client was not authenticated to send anonymous mail during MAIL FROM	The device is talking to smtp.office365.com without signing in. No password entered, or an empty field
550 5.7.60 Client doesn't have permissions to send as this sender	The From address set on the copier differs from the account signing in
550 5.1.8 Access denied, bad outbound sender	The mailbox in use is on a Microsoft internal block list
5.7.64 TenantAttribution; Relay Access Denied	A connector exists, but the site’s public IP address has changed
No message, the connection times out	Port 587 or 25 is filtered by the firewall or by the internet provider

That first one is the one you will meet, and it sends almost everybody down the wrong road. Credentials fine. Password not expired. Type it in again and you will get the same line back, word for word.

Read the tail of that 535 5.7.139 carefully, because the suffix tells you where to look. disabled for the Tenant points to the organisation-wide setting, for the Mailbox to the mailbox setting alone, basic authentication is disabled to a security policy, did not meet the criteria to be authenticated successfully to conditional access or MFA, and the user credentials were incorrect to a genuinely wrong password.

Plenty of control panels never surface the server’s reply at all and show a vendor code instead, such as 0x1102 on Kyocera. The full message then lives in the machine’s send log, reachable from its web interface rather than its screen, under a heading along the lines of “job log” or “transmission history”. The exact path differs with every brand. Failing that, message trace in the Exchange admin centre shows whether the attempt even reached Microsoft.

No message to hand, or you simply want to know whether the port leaves your network at all? Our online SMTP test opens a real connection from your browser and hands back the server’s reply. The username and password fields are optional: you can check the port and the encryption without handing over any secret.

Three causes, and none of them is your copier

Nine times out of ten this sits on the Microsoft 365 side rather than in the device. Three quite separate mechanisms end up looking identical from a copier panel. Worth knowing which one has you before you start changing things.

Authenticated SMTP is off by default. Microsoft disables it for every organisation created after January 2020. A copier installed on a recent tenant therefore never could send, and a migrated tenant can lose the setting during an unrelated change.

Entra ID security defaults block basic authentication. Microsoft states it plainly: client submission with basic authentication is not compatible with security defaults. Switch on multi-factor authentication, or a conditional access rule that bars legacy authentication, and you get the same refusal, word for word. When an outage lands a few days after somebody tightened security, this is nearly always why.

Where to look: Microsoft Entra portal, Overview, Properties, Manage security defaults. Conditional access hides somewhere else entirely, under Protection, then Conditional Access, where you want any policy that bars legacy authentication. Two mechanisms, and either one stops you on its own.

The device’s encryption is too old. Exchange Online dropped support for TLS 1.0 and 1.1 in October 2020 and rejects a share of the connections that use them. One shortcut does the rounds here, Microsoft’s own documentation included: that a device set to port 465 must be obsolete. That is not accurate. Microsoft does not open that port, but 465 remains a valid standard and serves TLS 1.2 perfectly well elsewhere. A copier genuinely stuck on TLS 1.0, on the other hand, will not get through to Microsoft on any port.

There is a documented way out for that last case, and it is widely overlooked: Microsoft keeps an endpoint reserved for legacy TLS clients. Details at the end of this article.

The immediate fix, if you administer the tenant

This one addresses the first cause, and nothing else. It also assumes you are an administrator on the tenant. A technician standing in front of somebody else’s copier has neither, as a rule.

Click path: Microsoft 365 admin centre, Users, Active users, pick the account the copier signs in with, Mail, Manage email apps, tick Authenticated SMTP. Same thing in PowerShell, module and sign-in included, because those two lines are what everybody forgets:

Install-Module ExchangeOnlineManagement -Scope CurrentUser
Connect-ExchangeOnline -UserPrincipalName admin@example.com

Get-CASMailbox -Identity scanner@example.com | Format-List SmtpClientAuthenticationDisabled
Set-CASMailbox -Identity scanner@example.com -SmtpClientAuthenticationDisabled $false

Careful, the per-mailbox setting wins over the organisation-wide one, so check that as well with Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled.

This fix fails in three cases, which accounts for most of the “I ticked the box and it still does not work” reports: if Entra ID security defaults are on, if an authentication policy blocks basic authentication for SMTP, or if a conditional access rule bars legacy authentication. The suffix on the error code tells you which of the three you are facing.

To inventory the estate before other machines fall over, the Exchange admin centre publishes a report under Reports, then Mail flow, called SMTP AUTH Clients: its protocol column separates basic authentication from modern authentication, over a rolling 90 days.

A word of caution to finish. Re-enabling basic authentication reopens the door to password spraying on that account. Give the device a dedicated mailbox and a long password.

This fix also has an expiry date, set out at the end of this article.

If security was just tightened, the most common case

Here, ticking the box will not save you. The copier’s account has to come out of whatever is blocking it, and the two mechanisms behave nothing like each other.

A conditional access policy can be worked around cleanly. In the Microsoft Entra portal open Protection, then Conditional Access, then Policies. Find the one blocking legacy authentication, open it, go to Users, the Exclude tab, and add the copier’s account. You are excluding one account, not your company.

Security defaults cannot. It is all or nothing: apart from directory synchronisation accounts, they allow no exceptions. Excluding a single mailbox means turning them off and rebuilding your protection as conditional access policies, which requires an Entra ID P1 licence. That is not a checkbox on a Monday morning, it is a project to plan with whoever handles your IT.

That is precisely the trade-off to weigh: weaken everyone’s security for one copier, move up to a P1 licence, or take the sending out of Microsoft 365 altogether. The third route is often the cheapest and the only one that touches nothing.

Can your copier do OAuth

This is the question that decides everything else, and you can only answer it machine by machine. Only the manufacturer can update the device’s code, which puts the decision outside your hands.

Brand	Requirement, as recorded on 10 August 2026
Konica Minolta	Firmware GC2-RF as a minimum on recent bizhub models. A token expiry defect is only fixed from GC4-SA
Ricoh	Models released after 2017, firmware issued from July 2025. Ricoh states that no update is planned for models absent from its list
Kyocera	Native OAuth on recent TASKalfa and ECOSYS models. The Exchange Online Connector is the workaround for older devices
Xerox	From software level xx.76.51 SP (PL7-R20)
Sharp	Recent models only
Canon	Current models

You read the installed version from the device’s web interface, never from its screen. The page is called “device information”, or “firmware version”, or “maintenance”, depending on who built the thing. Write it down. It is the first question the manufacturer’s support desk will ask you.

Three remarks beat a longer table. These requirements move quickly, so confirm them with the manufacturer for the exact model. A machine written off years ago will probably never receive the firmware it needs. And enabling OAuth almost always requires administrator consent inside the tenant: without access, even a compatible machine stays stuck.

Every option, compared

The external recipients column settles half the table. A scan sent to the accountant, the insurer or a customer leaves the organisation. The characteristics below were taken from Microsoft’s documentation on 10 August 2026.

Option	External recipients	What it requires
Client SMTP submission	Yes	A licensed mailbox, TLS 1.2, and OAuth by default from December 2026
SMTP relay via connector	Yes	A TLS certificate, or failing that a static, unshared public IP address. Port 25
Direct Send	No	Nothing, but sending is limited to internal recipients
High Volume Email	No	An HVE account, active Azure billing, and 10 MB per message maximum
Azure Communication Services	Yes	An Azure subscription, billed per message and per megabyte transferred
External SMTP relay	Yes	A username and a password. Annual cost, a sending quota, and no copy in Sent Items

Direct Send and High Volume Email are out immediately for a copier that scans to the outside world. Direct Send can moreover already be refused by an administrator, through Set-OrganizationConfig -RejectDirectSend $true, which returns 550 5.7.68 TenantInboundAttribution, and tenants created since early 2026 have it blocked by default. As for High Volume Email, its 10 MB per message ceiling rules it out for scanning before the recipient question even arises.

Relaying through a connector assumes infrastructure, not a setting. Microsoft recommends a TLS certificate first, which a copier almost never knows how to present, and only accepts a static, unshared public IP address as a fallback. Its documentation is categorical: dynamic IP addresses are neither supported nor allowed. A move or a change of provider therefore breaks the connector, and the 5.7.64 you will see says nothing about any of that.

Azure Communication Services, Microsoft’s recommended route for external mail, is billed per message and per volume transferred. Scans are heavy, and you have to create then administer an Azure resource for a copier.

The thing all five have in common is worth stating: every one of them requires work inside the tenant. Flipping a setting, licensing a mailbox, registering an OAuth application, building a connector. Not one of them is configured from the machine’s own panel. For a reseller or a managed service provider standing at a customer site, that is a ticket, a wait, and more often than not a second trip out.

Already running a mail server in-house, Exchange or anything else? Microsoft lists it as a supported fallback. The copier relays through it, and that server alone deals with Microsoft 365. It costs nothing, so look there first.

Otherwise the sixth route becomes interesting. An external SMTP relay accepts a username and a password, which is what the device has known how to do since day one. The copier is configured entirely from its own panel, without changing anything in Microsoft 365, and the settings are identical across every machine in the estate.

Two limits, stated plainly. An external relay leaves no copy in the Outlook Sent Items folder, as is the case for every option other than client SMTP submission: if a record matters, arrange a blind copy to a shared mailbox. And a copier genuinely stuck on TLS 1.0 will remain a problem whoever the provider is.

The settings to enter on the copier

Whichever route you take, a device always asks for the same fields.

Setting	Value
SMTP server	smtp.office365.com for client submission, the domain’s MX endpoint for a connector, or the host given by your relay
Port	587 with TLS, 25 for a connector, 465 with direct SSL where the device cannot do STARTTLS
Encryption	TLS 1.2 or above on the Microsoft side
Authentication	The address and password of the account in use
From address	The same as the account signing in, or you get a 550 5.7.60

Three traps come up repeatedly. The MX endpoint looks like example-com.mail.protection.outlook.com, and it is sometimes longer than the device’s input field allows. You cannot put an IP address there instead. Where port 587 is filtered on the network, alternative ports spare you a negotiation with whoever owns the firewall. And the obligation to send from the address that signs in is specific to client submission: a relay or a connector let you pick any sender within the domain.

Finally, think about weight. Microsoft caps outbound messages at 35 MB by default, adjustable from 1 to 150 MB, and attachment encoding adds roughly a third as soon as the message leaves its data centres. A thirty-page colour scan at 600 dpi sails past that ceiling without trying. Drop to 300 dpi, scan in black and white, split the big batches: it fixes more of these faults than anyone expects.

What changes around the sending

Changing sender calls for two precautions. Add the new path to your SPF record without removing Microsoft’s, since your staff keep writing from Outlook, and sign the messages with DKIM using a separate selector. Watch the ten DNS lookup limit on an SPF record, quickly reached once includes pile up. And because a scanned document often carries personal data, payslips or sick notes, where it is hosted and under what contract are not details. That is the question your management will ask before the one about price: our French IP addresses and security framework answer it, and our data processing agreement under article 28 of the GDPR can be signed online.

The Microsoft timeline, and what is not settled

Position on 10 August 2026. This deadline has already moved once. Microsoft planned a phased rejection from 1 March to 30 April 2026, then announced the postponement on 27 January 2026 (official timeline). The schedule as announced: basic authentication for SMTP AUTH stays usable until the end of December 2026, when it will be disabled by default on existing tenants, with administrators still able to re-enable it. Tenants created after December 2026 will not have it available by default. No final removal date is set: Microsoft has said it will announce one in the second half of 2027. A further postponement is not out of the question, and a great many articles still quote September 2024, September 2025 or April 2026, all abandoned.

What you can do within the hour

Unblock your users first, with the workaround described at the top of this page. Then take down the full error message from the device’s log rather than the one on its screen. Check the state of security defaults and of your conditional access rules, especially if anything moved on that front recently. Open the SMTP AUTH Clients report in the Exchange admin centre to find out which machines still use basic authentication. Then ask the manufacturer whether your exact model will get OAuth-capable firmware, because that answer governs everything else.

If it is no, or if you do not hold the keys to the tenant, an external relay is the only route that is configured entirely from the copier. Do the arithmetic before choosing: Microsoft’s client submission needs one licensed mailbox per device, multiplied by the number of machines and renewed every year. Our plans for an estate of devices start at €29 a year for 100 daily sends, €44 for 500 and €99 for 1,000, and a single account covers the whole estate. Setup is immediate and the copier can be reconfigured straight away. We have run this service since 2009, on French IP addresses we manage ourselves.

Frequently asked questions

Why has my Microsoft 365 scan to email stopped working?

In the great majority of cases the basic SMTP authentication the copier uses has been disabled. It is off by default on organisations created after January 2020, and it stops working the moment security defaults or multi-factor authentication are switched on for the account.

Does a Microsoft 365 app password fix the problem?

No, it just buys time. An app password is still basic authentication underneath, so it dies on the same day. It also will not appear at all while security defaults are on. Fine for a couple of weeks, never something to roll out across an estate.

Should I use Direct Send for a copier?

Rarely. Direct Send only reaches people inside your own organisation, so your accountant and your customers are out. Microsoft has been rejecting it by default on new tenants since early 2026, and wants to disable it more widely, because phishing campaigns lean on it heavily.

What exactly happens at the end of December 2026?

Basic authentication for SMTP AUTH will be disabled by default on existing tenants, but an administrator will be able to re-enable it. So it is not a removal. Tenants created after December 2026 will not have it available by default, and Microsoft will announce the final removal date in the second half of 2027.

Will scans sent through an external relay end up in spam?

Not if the domain is declared properly. You add the relay to the domain’s SPF record and sign the messages with DKIM. That is the same work as for any other sender, including Microsoft’s own Direct Send and connector routes, both of which need an up-to-date SPF record.

My copier only supports TLS 1.0, is that really the end?

Not necessarily. Microsoft maintains a dedicated endpoint for legacy TLS clients, smtp-legacy.office365.com, opened with Set-TransportConfig -AllowLegacyTLSClients $true. It remains a stopgap: the device will run into the OAuth requirement next.