Your Copier Stopped Scanning to Email and Nobody Touched the Copier

It is a Monday. Somebody puts a contract in the feeder, presses the button on the panel marked Scan to Email that they have pressed every working day for six years, and the machine says Authentication Failed. Or Connection Error. Or, worst of all, it says nothing at all, reports a cheerful Success, and the email never arrives anywhere.

Nobody changed anything. That is not a customer being defensive, it is almost always true, and it is the most useful fact in the room. The settings inside that copier are the settings a technician typed in when it was delivered. The password has not been altered. The network has not been rewired.

What changed is at the other end. A copier does not deliver email; it hands the message to a mail service and asks that service to deliver it. Over the last two years the rules for how a machine is allowed to make that request have been rewritten by both Microsoft and Google, and for Microsoft 365 there is now a specific month attached to the next step. This piece is about how to work out in ten minutes which half is actually broken, what the correct settings are according to the people who run the mail servers rather than according to a forum post, the single line on the copier's own screen that will tell you the machine cannot be fixed, and what to do about scan-to-a-network-folder, which broke for a closely related reason and usually in the same year.

Your copier is not a mail server, and that is the entire story

Microsoft's own documentation for exactly this situation opens by describing the class of device it is talking about: machines that "create email messages, but are incapable of sending those messages without help, because they aren't email servers." The first example it gives is "Network-connected scanners that send scanned documents as attachments in email messages."

So the copier has to knock on the door of a real mail system and be let in. For most of the last twenty years, being let in meant typing a username and a password into the machine, and the mail system accepting them. That mechanism has a name — basic authentication — and it is being withdrawn everywhere, for a reason that is not hard to sympathise with: a username and password sitting in a device in a corridor can be read by anyone who can reach the machine's web page, and once stolen it lets an attacker send mail as your business from anywhere in the world.

Everything below follows from that. The copier is not being punished for being old. It is being asked for a kind of proof it was never built to give.

Ten minutes of diagnosis before you change a single setting

The commonest way this goes wrong is that somebody starts retyping passwords into the panel. Do these four things first, because between them they decide which of the following sections applies to you and which are a waste of an afternoon.

First, find out whether it is failing to connect or failing to sign in. Most machines have a Test or Send Test Email button next to the SMTP settings, and the wording of the failure matters more than the fact of it. Anything about a timeout, a host that cannot be resolved, or a connection refused is a network, port or DNS problem and has nothing to do with your password. Anything about authentication, credentials, or a numeric code in the 530 or 535 family means the connection worked perfectly and the mail service declined the sign-in. Those are two different articles' worth of causes and you can rule out half of everything by reading one sentence properly.

Second, prove the mailbox itself is alive. Sign into that same account from a phone or a browser and send a message. If that works, the account is fine and the problem is the method the machine is using, not the account.

Third, find out whether it fails for everybody or only for outsiders. Scan to somebody in your own office. Then scan to a Gmail or Yahoo address. If the internal one arrives and the external one does not, that is a specific, well-understood configuration and it is described further down — do not let anyone tell you the machine is broken.

Fourth, write down five things off the copier's screen before you touch them: the server name, the port number, whether TLS or StartTLS is ticked, the From address, and the username it signs in with. Photograph the screen if it is easier. Those five lines determine everything that follows, and the commonest way a fixable problem becomes an unfixable one is somebody overwriting them from memory.

If your mail is Microsoft 365, there is now a date on this

On 27 January 2026 the Exchange team published an updated timeline for retiring basic authentication on the path copiers use, and it is short enough to quote in full. "Now to December 2026: SMTP AUTH Basic Authentication behavior remains unchanged." "End of December 2026: SMTP AUTH Basic Authentication will be disabled by default for existing tenants. Administrators will still be able to enable it if needed." "New tenants created after December 2026: SMTP AUTH Basic Authentication will be unavailable by default. OAuth will be the supported authentication method." And "Second half of 2027: Microsoft will announce the final removal date for SMTP AUTH Basic Authentication."

Microsoft's stated reason for the revision is worth knowing too, because it tells you how the next few years go: "We understand that many customers continue to face real challenges modernizing legacy email workflows and need sufficient time to adopt viable, secure alternatives." This has already been pushed back once. It will not be pushed back forever, and the direction has never wavered.

What that means for a small office in plain terms. Nothing breaks this month because of the deadline. At the end of December 2026 a business that has been quietly relying on username-and-password sending loses it by default, and an administrator has to go and deliberately switch it back on to keep the copier working. A business that starts a new Microsoft 365 tenant after that point does not get the option at all. And at some point announced in the back half of 2027, the switch stops existing.

So this is a job for the autumn of 2026, not a job for the week it breaks. If you are reading this because it has already broken, though, the deadline is not your cause — one of the next three things is.

Three reasons it may have broken already, none of which are the copier

Every one of these is a security improvement that a small business either received automatically or switched on for good reasons. None of them is a fault, and the answer to none of them is to undo it.

The first is the one that catches newer businesses, and it is stated flatly in Microsoft's setup guidance for these devices: "SMTP AUTH is disabled for organizations created after January 2020 but you can enable it per-mailbox." If your company set up its Microsoft 365 tenant in the last six years, this was never on. A copier installed since then either had it enabled specifically, or has been using one of the other methods described below without anyone telling you which.

The second is security defaults — the baseline protection Microsoft applies to make multi-factor authentication universal. Microsoft's own words, twice over: "Client SMTP submission using Basic authentication isn't compatible with Security defaults in Microsoft Entra ID," and on the settings page, "If security defaults is enabled in your organization, SMTP AUTH is already disabled in Exchange Online." If your office turned on MFA for everybody, or had it turned on for you, this is very often the day the copier stopped.

The third is a single checkbox that a tidy-minded person ticks off while hardening accounts. In the Microsoft 365 admin center it sits under Users, then Active users, then the account, then Mail, then Manage email apps, and it is labelled Authenticated SMTP. Unchecked means disabled. Nothing on that screen mentions the copier, so nobody makes the connection, and the change and the symptom can be weeks apart.

That last point generalises. When a copier stops scanning to email, ask what happened to the email system in the preceding month, not what happened to the copier. In our experience the answer is usually a security change somebody is quietly pleased about and had no reason to associate with a photocopier.

The port 465 tell, which is the most useful line on this page

Here is a two-second test that tells you whether the machine in front of you can be fixed at all, and it works from the screen you are already looking at. Microsoft's guidance carries this note: "If your device or application recommends or defaults to TCP port 465, it doesn't support the required versions of TLS for client SMTP submission in Microsoft 365 or Office 365."

The requirement it is failing is stated on the same page: "Your device or application must support TLS 1.3 or TLS 1.2. If your device or application doesn't support TLS 1.2 or later, you can't use client SMTP submission with Microsoft 365 or Office 365." The correct settings, for comparison, are the server name smtp.office365.com — not an IP address — on port 587 or port 25, with TLS or StartTLS enabled.

So if you are on Microsoft 365 and the copier's port menu offers 465 and nothing else, stop retyping the password. You are not looking at a credentials problem. You are looking at a machine whose encryption is too old for the service, and no amount of correct typing will change that. Skip to the sections on relays and alternatives.

One important caveat, because it is exactly the sort of thing that gets repeated wrongly: this rule is about Microsoft 365 specifically. Port 465 is a perfectly legitimate Gmail port, as you will see in a moment. Do not carry the rule across.

The four ways Microsoft 365 will accept mail from a machine

Microsoft publishes these as a set, with the trade-offs written out, and it is worth knowing all four exist because vendors and installers tend to know one.

Client SMTP submission is the familiar one: the device signs in as a real mailbox, on port 587 or 25, with TLS required. It can send to people inside and outside your organisation, it saves a copy in that mailbox's Sent Items, and it needs a licensed mailbox to sign in as. Its published limits are 10,000 recipients per day and 30 messages per minute, which no scanner will ever trouble. This is the method almost every copier in the world is configured for, and its username-and-password form is the one with the December 2026 date on it. If the machine supports OAuth for it, that is the version to be on.

SMTP relay is the durable answer for a device that cannot do modern sign-in. Instead of proving who it is with a password, it is recognised by an inbound connector you create, authenticated by a TLS certificate — which Microsoft recommends — or by your public IP address. It uses port 25, it does not need a licensed mailbox at all, it can send to the outside world, and it can send from an address that has no mailbox behind it, such as a do-not-reply address. There is one sentence that decides whether it is available to you, and it is worth reading before anyone starts configuring: "Dynamic IP addresses aren't supported or allowed." A great many small offices are on a business internet plan whose address is not genuinely static, and the certificate route or a different method is then the honest answer.

Direct Send is the no-authentication option, aimed at your own domain's mail endpoint on port 25, and it has two properties that matter enormously here. It "sends email to Microsoft 365 or Office 365 recipients only. Mail sent to recipients outside your cloud-based organization is rejected." And Microsoft has put a marker down about its future: "Most customers don't need to use Direct Send. We're working on an option to disable Direct Send by default to protect customers." It works, plenty of installers use it, and it will scan to your own staff quite happily — but do not build a permanent workflow on it, and do not be surprised when it becomes the next thing that stops.

High Volume Email is the newest of the four and is aimed at internal recipients only, on port 587 with TLS required, using either its own account credentials or OAuth. For a scanner that only ever emails documents to colleagues, it is a legitimate landing spot, and it is the alternative Microsoft itself points to first when it tells you client submission with basic auth is going away.

The practical verdict for a four-to-thirty-person business. If the copier's firmware supports OAuth, use it and you are finished. If it does not and you only ever scan to your own staff, High Volume Email is the tidy option and Direct Send is the expedient one. If you need to scan to clients and the copier cannot do OAuth, a connector is the durable answer, and the question that decides it is whether you have a static address or can load a certificate. If none of those are true, the copier itself is now the limiting factor, and that is a purchasing conversation rather than a settings one.

It emails us fine, but not the customer

This is common enough, and diagnostic enough, to deserve its own heading, because it has two clean causes and neither of them is a broken machine.

The first is that somebody configured Direct Send, deliberately or by accident, and it is behaving exactly as documented: internal recipients arrive, external recipients are rejected. If the outcome you need is scanning to clients, that method cannot give it to you and no adjustment will make it.

The second is a permissions mismatch that produces a specific and quotable bounce: "5.7.60 SMTP; Client doesn't have permissions to send as this sender." This happens when the From address configured on the copier is not the same as the account it signs in with — the classic case being a machine that logs in as a scanner account but is set to send as info@ or accounts@ so that replies land somewhere sensible. Microsoft's fix is to grant that sign-in account Send As permission on the mailbox it is impersonating. The quicker fix, if nobody needs the vanity address, is to make the two match.

There is a third outcome that looks like this and is not: the mail is being sent and delivered, and it is landing in the recipient's junk folder. Microsoft recommends an SPF record entry for both relay and Direct Send, and for Direct Send says you also need DKIM and DMARC configured correctly for the domain, warning that "misconfiguration can lead to security gaps." If the copier reports success and the recipient swears nothing arrived, ask them to look in junk before anyone reconfigures anything.

If your mail is Google Workspace or Gmail

Google publishes three options for exactly this device class, and the shape of the choice is the same as Microsoft's even though the names are different: identify the machine by a credential, identify it by its address on the internet, or accept that it can only mail your own people.

The relay service is the one Google recommends. The server is smtp-relay.gmail.com, it accepts ports 25, 465 or 587, it supports SSL and TLS, and it is authorised by IP address rather than by a username and password — which means there is no password sitting in the copier to be stolen. Its published limit is generous: "Each user in your organization can relay messages up to 10,000 recipients per day."

The ordinary Gmail server is smtp.gmail.com on port 465 for SSL or 587 for TLS, and it is the option that needs credentials — specifically "your complete Google Workspace email address" and "an app password." It sends to anyone inside or outside the organisation, and Google states "the sending limit is 2,000 messages per day."

The restricted server, aspmx.l.google.com, runs on port 25 only, where "TLS and authentication aren't required," and the trade-off is stated plainly: "this option lets your organization send messages to Gmail or Google Workspace users only." It needs your IP address on an allowlist and your SPF record set up. It is Google's Direct Send, in other words, with the same internal-only ceiling.

One thing to know before you go hunting for the app password, because it saves an argument. An app password is "a 16-digit passcode that gives a less secure app or device permission to access your Google Account," and Google is explicit that they "can only be used with accounts that have 2-Step Verification turned on." Google's account help also lists being "logged into a work, school, or another organization account" among the situations where the option to create one may not be available to you. If the app-password screen simply is not there, that is an administrator's policy rather than a fault, and the person to ask is whoever runs your Workspace — not the copier's manufacturer.

Do not fix this by making the office less safe

There are three shortcuts that will get the copier scanning again this afternoon, and we would rather talk you out of all three.

The first is switching off security defaults or relaxing multi-factor authentication for the whole organisation so the copier can sign in. This trades every account in the business against one machine's convenience, and multi-factor authentication is the single most effective control a small business has against the account takeovers that lead to invoice fraud. If the copier genuinely cannot work alongside it, use a connector, not a downgrade.

The second is putting the owner's own mailbox credentials into the copier. Consider what that actually is: the password to the account that holds the bank correspondence, the payroll thread and the legal advice, stored in a device that sits in a corridor, whose administration page is very often still on the manufacturer's default password, and which several unknown people service each year. If a device must sign in as somebody, it should be a dedicated account created for the purpose, used for nothing else, and treated as disposable.

The third is re-enabling basic authentication in December 2026 and considering the matter closed. That switch is explicitly temporary and Microsoft has already said the final removal date gets announced in the second half of 2027. Using it is reasonable; using it as a plan is not.

The version of this that ages well is boring: either the device holds no credential at all, because a connector recognises it, or it holds a credential to an account that can do nothing except send mail.

Scan to a folder stopped working for a closely related reason

The other half of every copier's delivery menu is scanning to a shared folder on a PC, and in a great many offices that broke in the same era, which understandably gets read as the copier failing. It is the same story: the machine is asking to be let in using a method that no longer exists on the other side.

The oldest cause is the file-sharing protocol itself. Microsoft's documentation is unambiguous: "Windows 11 doesn't contain the SMBv1 server or client by default after a clean installation," and it has not been installed by default since Windows 10 version 1709. A copier old enough to speak only that first version of the protocol now has nothing to talk to on a new front-desk PC. The temptation is to turn it back on, and Microsoft's warning is worth reading before anybody does: "We strongly recommend that you don't reinstall SMBv1. This older protocol has known security issues regarding ransomware and other malware."

The newer cause is stranger and produces the most baffling symptom in the whole of this subject. In Windows 11 version 24H2, message signing became mandatory, but not on every edition. Microsoft's page sets it out edition by edition: "Windows 11, version 24H2 Enterprise, Pro, and Education require both outbound and inbound SMB signing," while "Windows 11, version 24H2 Home edition doesn't require outbound or inbound SMB signing." The same page adds the consequence that catches copiers: "Requiring SMB signing also disables guest access to shares."

Read that twice, because it explains a scene we have walked into more than once. The same copier still scans happily to the older machine in the back office and refuses the newer one at reception — not because either PC is broken, but because one of them is Home and the other is Pro. Nobody would ever guess that from the copier's error message.

The errors you may see on the Windows side of the same fault are worth recognising: the code 0x80070035, the message "You can't access this shared folder because your organization's security policies block unauthenticated guest access," and, when signing is the sticking point, STATUS_INVALID_SIGNATURE.

Before any of that, though, check the dull explanation, because it is more often right than all of the above put together. The folder lived on a PC that has since been replaced, renamed, moved to a new Wi-Fi network with a new address, or switched from a local account to a Microsoft account sign-in — and the copier is still carrying the old computer name and the old local username in its address book. That is a five-minute fix and it costs nothing to rule out first.

The options nobody offers you, because nobody sells them

If the machine cannot be made to authenticate the modern way, the conversation usually jumps straight to replacing it. Three cheaper things are worth trying first.

Scan to a USB stick. It is free, it is instant, it needs no account, no server and no permission from anyone, and it will still work in ten years. For a two- or three-person office where the scans get filed on one computer anyway, it is genuinely the right answer more often than anybody admits, and it is never suggested because there is nothing to sell.

Use the copier's own cloud buttons. Most machines made in the last decade have panel apps for Google Drive, OneDrive, SharePoint or Dropbox, and those apps sign in the modern way — you approve them once from a browser and no password is stored on the device. They are usually the newest and best-maintained code on the machine, they sidestep the entire email question, and on many models they are already licensed and simply switched off.

Check for a firmware update before you write the machine off. OAuth support arrived on a lot of mid-range multifunction devices as firmware rather than as new hardware, and the update is free. It is ten minutes of somebody's time against a four-figure replacement, and it is worth doing even if you expect it to fail.

And the honest limit: on a device made before roughly 2015, none of this arrives, and no configuration recovers it. At that point the arithmetic is the real annual cost of the workarounds — including the hour somebody loses every time it breaks again — against a machine that speaks the current language. We have no stake in which way that goes.

What to write down before you call anybody

Whether you call us, the copier dealer or whoever runs your email, the same short list turns this from a site visit into a phone call, and gathering it takes about ten minutes.

The make, model and firmware version off the copier's panel. Who actually hosts your email — Microsoft 365, Google Workspace, or a mailbox that came with your website hosting, which is a third case with its own settings. The five lines from the copier's SMTP page: server, port, TLS on or off, From address, sign-in username. The exact wording of the error, photographed rather than paraphrased, because the difference between a connection failure and an authentication failure is the whole diagnosis. Whether scanning to a colleague works while scanning outside fails. Whether that mailbox sends normally from Outlook or a phone. Roughly when the business set up its Microsoft 365 tenant, since anything after January 2020 changes the starting assumption. And who has administrator access, because for several of the fixes above, somebody with that access has to be in the room.

What we do here, and what is not ours to do

The boundary first. We do not sell copiers, we do not sell mail service, and we take nothing from any manufacturer, so we have no reason to tell you the answer is a new machine. If your dealer is willing to update the firmware and reconfigure it, that is a good outcome and we will happily tell you so.

What we do is the join between the two, which is precisely where this fault lives and precisely why it gets bounced between the copier company and whoever set up your email. We work out which side has actually changed, set the device up on the method that suits your tenant rather than the one that was standard in 2016, move it off anybody's personal mailbox onto an account that can do nothing but send, get scan-to-folder working again without turning an obsolete protocol back on, and — if your mail is on Microsoft 365 — tell you honestly whether that machine will survive the end of December 2026 or whether you should be budgeting.

We cover homes and small businesses across Southern California. If you send us the make and model, a photo of the error, and the name of whoever hosts your email, that is usually enough for us to say over the phone whether this is a settings job, a firmware job or a hardware one.