Your scanner is about to stop emailing: SMTP basic auth ends in December

Published: 6 October 2026

Somewhere in your building there’s probably a copier that emails scans to people. It was set up years ago with a Microsoft 365 username and password, pointed at smtp.office365.com on port 587, and nobody has thought about it since.

It might not be just the copier. Finance systems emailing invoices and remittances, accounting software, CCTV and door-entry alerts, NAS and UPS warnings, website contact forms, the odd script someone wrote to send a daily report. Anything that sends email through Microsoft 365 using a plain username and password is about to have the same bad week.

At the end of December 2026, Microsoft switches that method off by default. The first anyone will know about it is when the scans stop arriving.

What’s changing, and when

Microsoft’s current timeline was set out in January 2026 (Exchange Team blog):

• Until the end of December 2026, nothing changes.
• At the end of December 2026, basic authentication for SMTP sending is disabled by default in existing tenants. Administrators can switch it back on for now.
• New tenants created after that won’t have it at all.
• In the second half of 2027, Microsoft will announce a date for removing it permanently.

This date has already moved three times. The original plan was to remove it in September 2025, then a gradual switch-off across March and April 2026, then this. It’s tempting to assume it’ll slip again. I wouldn’t plan around that. The switch to “off by default” is the part that breaks things, and Microsoft hasn’t yet published exactly how it will roll out, so treat late December as the deadline and aim to be done well before the Christmas shutdown.

To be clear about scope: this is SMTP sending only. Basic authentication for everything else in Exchange Online, including Outlook, POP and IMAP, was switched off back in October 2022 (Microsoft Learn). SMTP was the exception, because so many devices depended on it.

Why Microsoft is doing it

Basic authentication checks a username and password and nothing else. No MFA, no Conditional Access, no device check. That makes it the favourite door for anyone spraying common passwords at Microsoft 365 accounts, and it’s why every other protocol lost it years ago.

So “just switch it back on” is available, briefly, but it’s a stopgap with a known expiry date, and it keeps an MFA-free route into your tenant open in the meantime. Use it to buy a few weeks if you’re caught out, not as the plan.

How to find what’s affected

You don’t have to guess. Two places in Microsoft 365 will tell you what’s still sending this way:

• The SMTP AUTH clients report in the Exchange admin centre, under Reports > Mail flow. It lists the accounts sending via SMTP AUTH and shows which are using basic authentication rather than modern authentication (Microsoft Learn). It defaults to the last seven days, so run it over a longer period to catch monthly jobs.
• Entra sign-in logs, filtered by client app “Authenticated SMTP”. Check the non-interactive sign-ins tab as well, because that’s where most device traffic lands.

Then walk the building. The report tells you which accounts are sending. It won’t tell you that the account called scanner@ is used by three copiers, a label printer and a line-of-business app on the server in the comms cupboard. Write down every device and application, the account it uses and who to call when it stops.

Your options

Microsoft documents several ways for devices and applications to send email through Microsoft 365 (Microsoft Learn). In plain English:

1. Keep SMTP AUTH, but with modern authentication (OAuth). This stays supported. The catch is the device: plenty of newer copiers and applications support it, and plenty of older ones don’t. Check the manufacturer’s documentation or firmware updates first, because if it’s supported this is the least disruptive fix.
2. Microsoft 365 SMTP relay through a connector. The device sends to your Microsoft 365 mail endpoint, and Microsoft trusts it because it comes from your office’s static public IP address, or presents a certificate for your domain. No licensed mailbox needed, and it can send to anyone. It needs a fixed IP that isn’t shared, so it suits a single office with a proper business connection. It doesn’t suit devices on dynamic broadband or applications hosted elsewhere.
3. Direct send. The device sends straight to your mail endpoint with no authentication, but it can only deliver to your own staff, not external addresses. Microsoft has also added a setting to block direct send and has said it plans to make that the default for new tenants (Exchange Team blog), because attackers abuse it to send convincing internal-looking phishing. I wouldn’t build on it now.
4. High Volume Email for Microsoft 365. Microsoft’s newer service for internal bulk mail, billed per recipient through Azure (Microsoft Learn). Like direct send, it’s internal recipients only, so it won’t help a copier that scans to a customer.

You may also see Microsoft’s Azure Communication Services Email suggested. Microsoft has since announced it’s being retired, and it’s closing to new customers this month (Microsoft Learn). Don’t start there.

The fix we usually use: a dedicated SMTP relay

For most small businesses, the cleanest answer is to take device and application email out of Microsoft 365 altogether and send it through a dedicated SMTP relay service. We typically use SMTP2GO for clients. Others such as SendGrid and Mailgun work on the same principle.

It works like this. Each device or application gets its own SMTP credentials that can do one thing: send email through the relay. They can’t log into Microsoft 365, read a mailbox or reset a password. The relay sends on your behalf from your own domain, and you authorise it in your DNS so recipients trust it: an SPF entry, DKIM signing with your domain’s key, and DMARC alignment (the NCSC’s email security guidance explains why all three matter). SMTP2GO now requires you to verify your sending domain this way before it will send at all (SMTP2GO docs), which is a good thing. It also has UK and EU infrastructure, if data location matters to you.

The advantages for an SME are practical. It works for internal and external recipients, from any site and any internet connection. It doesn’t depend on a device supporting modern authentication. It takes a licensed mailbox and a password with no MFA out of your Microsoft 365 tenant. And when Microsoft next changes how SMTP works, your copier doesn’t notice.

Where we look after a client’s email, devices have usually been moved to a relay like this already, so the December change shouldn’t touch them. Most businesses we meet for the first time haven’t, and won’t know until the scans stop.

Choosing between them

• The device supports OAuth: use it, and keep it inside Microsoft 365.
• One office, a static IP, internal and external recipients: a Microsoft 365 connector is a sound choice.
• Several devices, several sites, dynamic broadband, or hosted applications: a dedicated relay service is usually simpler and more robust.
• Internal-only alerts, and nothing else works: direct send or High Volume Email, knowing Microsoft is tightening both.

What to do before December

• Run the SMTP AUTH clients report over at least a month, and check the sign-in logs.
• List every device and application that sends email, and the account each one uses.
• For each, decide: OAuth, connector, or relay.
• Make the change and test it, including a scan to an external address.
• Check SPF, DKIM and DMARC for any new sending route, so the fix doesn’t send everything to junk.
• Then turn SMTP AUTH off for accounts that no longer need it, rather than waiting for Microsoft to do it for you.

Not sure what’s still sending this way? Our free security and IT health check includes legacy sign-ins like this, or read about our Microsoft 365 service. For the wider picture of what’s changed in Microsoft 365 this year, see Microsoft 365’s July 2026 changes, explained plainly.