By Dan Briggs — Head of Relationships | 18 June 2026

Author: Dan Briggs | Published: 18 June 2026 | Reading time: 15 minutes

Executive summary

At the end of December 2026, Microsoft turns off Basic authentication for the last email function that still allows it: sending mail through Exchange Online with a username and password (the function Microsoft calls Client Submission, or SMTP AUTH). After that date, SMTP AUTH Basic authentication is disabled by default for every existing Microsoft 365 tenant. The change is confirmed in Microsoft’s own Exchange Team blog update from January 2026.

This is not a pricing story or a feature you can ignore. It is the kind of change that breaks quietly. The devices and programs that send email using a saved username and password — office multifunction printers and scanners set up to “scan to email”, accounting and practice-management software that emails invoices and statements, hotel booking and property-management systems, server monitoring alerts, and old in-house scripts — keep working right up until they don’t. Nobody gets an error popup. An invoice simply never arrives. A scanned contract never lands in the inbox. An overnight alert never fires.

There is a second deadline running alongside it. From July 2026, Microsoft blocks old encryption (TLS 1.0 and TLS 1.1) on the POP3 and IMAP4 connections used to collect mail from Exchange Online, as set out in Microsoft’s April 2026 announcement. Together, these two changes mean 2026 is the year a lot of “set and forget” email plumbing in Australian offices needs attention.

We’re already seeing clients discover, late, that a single ageing photocopier or a line-of-business app nobody has touched in years is the thing standing between them and a working invoicing run. This whitepaper explains what is changing, what it costs you if you do nothing, how to find every affected device and app in your environment, and the specific options for fixing each one before the December cut-off.

What Basic authentication is, and why Microsoft is removing it

Basic authentication means an app or device sends a username and password with every connection, and usually stores those credentials on the device itself. It is simple, which is exactly why it has survived for decades on printers, scanners and small applications. It is also the weakest link in account security. Stored credentials get stolen. Passwords sent on every request are easy targets for password-spray and credential-stuffing attacks, and multi-factor authentication cannot be enforced on a connection that only knows a username and password.

Microsoft started retiring Basic authentication across Exchange Online years ago. As the Microsoft Learn documentation records, Basic authentication was switched off for Exchange ActiveSync, POP, IMAP, Remote PowerShell, Exchange Web Services, the Offline Address Book, Autodiscover and the Outlook desktop clients back in late 2022 and early 2023. One function was given a reprieve because so many businesses depended on it: Client Submission, the SMTP AUTH path that devices and apps use to send outbound email. That reprieve ends in December 2026.

The replacement is modern authentication, built on OAuth 2.0. Instead of a stored password, an app receives a token with a limited lifetime, scoped to a specific job, that cannot be reused elsewhere and sits comfortably alongside MFA and Conditional Access. For your business, the security upside is real: turning off legacy authentication closes one of the most commonly exploited doors into a Microsoft 365 tenant, and it lines up neatly with the multi-factor authentication expectations in the ACSC Essential Eight. The catch is that the change happens whether or not your devices are ready for it.

The timeline, in plain terms

Microsoft has moved this deadline before, so it is worth being precise about where things actually stand. The company originally flagged a permanent removal of SMTP AUTH Basic authentication in March 2026. After feedback from businesses that needed more runway, it published a revised timeline in January 2026. These are the dates that matter now:

Now until December 2026: nothing changes. SMTP AUTH Basic authentication keeps working as it does today. This is your window to fix things calmly.
End of December 2026: SMTP AUTH Basic authentication is disabled by default for all existing tenants. Administrators will still be able to switch it back on if they genuinely have to, but the default flips to off.
New tenants created after December 2026: SMTP AUTH Basic authentication is unavailable, full stop. OAuth is the only supported method.
Second half of 2027: Microsoft will announce the final, permanent removal date — the point at which administrators can no longer re-enable it at all.

Read that carefully, because the “administrators can still enable it if needed” line has lulled some businesses into thinking nothing happens in December. What happens is that the default changes. If you have done nothing, your tenant’s SMTP AUTH Basic authentication switches off, and every device relying on it stops sending mail. Re-enabling it is a deliberate administrative action and, by Microsoft’s own framing, a temporary stay of execution rather than a long-term plan — the protocol is on its way out for good in 2027.

The parallel TLS deadline in July 2026

While SMTP AUTH gets the headlines, a related change lands sooner. From July 2026, Microsoft stops accepting connections that use the obsolete encryption standards TLS 1.0 and TLS 1.1 on the POP3 and IMAP4 services in Exchange Online. Connections will need TLS 1.2 or later, as detailed in coverage from The Register and Office 365 for IT Pros.

This one mostly affects the systems that read or collect mail rather than send it: older email gateways, mail-archiving tools, ticketing systems that poll a shared mailbox, and the occasional scanner or appliance configured to retrieve mail by POP or IMAP. Modern clients and libraries already use TLS 1.2 or higher, so most people will notice nothing. But if you run anything older that talks to Exchange Online over POP or IMAP, July is the date to have it tested and, if necessary, updated.

What this actually means for your business

The reason this matters more than a typical Microsoft notice is the failure mode. There is no warning to your staff, and no obvious error. The system that breaks is usually one that runs in the background and that nobody owns. Here is where we most often see the damage in Australian offices.

Multifunction printers and scanners

The “scan to email” button on the office multifunction device is the classic example. Most were configured years ago with a mailbox username and password typed into the printer’s web interface, pointed at smtp.office365.com on port 587. When Basic authentication switches off, that button stops working. Staff press scan, the document goes nowhere, and the first anyone hears about it is a complaint that “the scanner is broken”. For an accounting or legal practice that scans signed documents all day, this is not a minor inconvenience.

Line-of-business applications

This is the expensive one. A great many business applications send email through SMTP AUTH using a stored password: accounting and ERP platforms such as Microsoft Dynamics 365 Business Central and older NAV systems, customer-relationship and practice-management tools, job-management and field-service software, and the booking or property-management systems that hospitality venues live on. When these stop sending, the consequences are immediate and commercial. Invoices, quotes, statements, booking confirmations and appointment reminders silently fail to go out. Cash flow and customer experience both take the hit, often before anyone connects the dots back to a Microsoft authentication change.

Monitoring, alerting and backup systems

Server monitoring tools, network devices, backup software and security appliances frequently email their alerts through SMTP AUTH. If that path goes dark, you lose the warnings — the failed-backup notice, the disk-nearly-full alert, the after-hours intrusion warning. The system keeps running; it just stops telling you when something is wrong, which is arguably worse than an obvious outage because you are flying blind.

In-house scripts and integrations

Plenty of businesses have a small PowerShell script, a website contact form, or a custom integration that someone built to send mail through the tenant. These are easy to forget precisely because they work. They are also the hardest to inventory, because the knowledge often left with the person who wrote them.

How to find every affected device and app

You cannot fix what you cannot see, and the goal between now and December is a complete inventory of everything in your environment that sends or collects mail using Basic authentication. There are three practical ways to build that list, and we recommend using all three.

1. Run Microsoft’s SMTP AUTH clients report. The new Exchange admin centre includes a report that shows which accounts are submitting mail and, importantly, which authentication protocol they are using. Microsoft’s engineers point administrators to the SMTP AUTH clients report for exactly this purpose. One caveat worth knowing: the authentication-protocol detail can take up to 90 days to fully populate, which is another reason to start now rather than in November.

2. Use message trace. Message trace in Exchange Online lets you see mail originating from your devices and applications, which helps you tie a stream of messages back to a specific printer, server or app and the mailbox it uses.

3. Walk the floor and ask your vendors. Technology reports will not capture the photocopier in the corner that nobody thinks of as a computer. Make a physical list of every multifunction device, every appliance and every business application that sends email. For each one, ask the supplier a direct question: does the current version support OAuth 2.0 / modern authentication for sending mail through Microsoft 365, and if so, what is the configuration? Vendors have had years of notice; the good ones already have a documented answer.

Your options for fixing each device or app

There is no single replacement that suits every situation. The right fix depends on what the device or app can support and who it needs to send mail to. Microsoft’s official guidance on retiring Basic auth for Client Submission sets out the supported alternatives. Here is how they map to real-world Australian environments, from simplest to most involved.

Option 1 — Switch the device or app to OAuth 2.0

If the printer, appliance or application supports modern authentication, this is the cleanest answer: keep using the same SMTP AUTH protocol, but authenticate with OAuth 2.0 instead of a stored password. Many current-generation multifunction devices and most actively maintained business applications now offer this. It usually means updating the firmware or software to a recent version and reconfiguring the mail settings using an app registration in Microsoft Entra ID. This keeps everything inside Microsoft 365 with no extra services to buy.

Option 2 — Move the application to the Microsoft Graph API

For custom applications and integrations you control, the modern way to send mail is the Microsoft Graph API’s sendMail capability rather than SMTP at all. This is a development task, so it suits in-house software or anything where you have access to a developer or the original vendor. It is the most future-proof option because it does not depend on SMTP AUTH surviving at all.

Option 3 — Use an SMTP relay connector with a static IP address

For older devices that cannot do OAuth and only know how to send unauthenticated mail (a common situation with printers and appliances), you can set up a relay through your tenant’s mail endpoint (the address that looks like yourdomain-com.mail.protection.outlook.com on port 25) combined with a connector in Exchange Online that authorises your office’s public IP address. Because there is no password involved, this path is unaffected by the Basic authentication change. The trade-offs are real and worth stating plainly: you need a static public IP address on your internet connection, you must add that IP to your domain’s SPF record so the mail is not treated as spam, and it only works for devices sending from inside that network. For a single-site office with a fixed IP, it is often the most pragmatic fix for legacy hardware.

Option 4 — High Volume Email or Azure Communication Services

For applications that send larger volumes of automated mail, Microsoft points to two purpose-built services. High Volume Email for Microsoft 365 is designed for bulk application mail sent to recipients inside your own organisation. Azure Communication Services Email handles application mail to recipients both inside and outside your organisation. These suit higher-volume or transactional sending and come with their own setup and, in the case of Azure Communication Services, their own consumption-based pricing. They are overkill for a scanner, but the right call for an app blasting thousands of notifications.

Option 5 — A third-party SMTP relay service

If a device genuinely cannot be updated and a static IP is not available, a dedicated email-relay service (the well-known names include SendGrid, Mailgun and SMTP2GO) can sit between the device and the internet, accepting mail from the device and delivering it on. This adds a monthly cost and another supplier to manage, and you will want to get the sender authentication right, but it can rescue otherwise stranded hardware.

What to avoid

Re-enabling SMTP AUTH Basic authentication in December and hoping for the best is not a strategy. It buys you a few months at most before Microsoft announces the final removal in the second half of 2027, and it leaves the exact security weakness this whole exercise is meant to close. Treat any re-enabling as an emergency stopgap for a single stubborn device while you arrange a proper fix, not as the plan.

An action checklist with deadlines

Use the table below to match each type of device or application to the right fix and the date it needs to be done by. We suggest working through your inventory item by item and recording the chosen option against each one.

If you have…	The risk	Recommended fix	Do it by
A printer/scanner using “scan to email” with a saved password	Scan-to-email stops working	Update firmware and switch to OAuth 2.0, or set up an SMTP relay connector with a static IP	December 2026
Accounting, ERP or practice-management software emailing invoices/statements	Invoices and statements silently fail to send	Update to a version that supports OAuth 2.0; confirm the exact configuration with the vendor	December 2026
Booking or property-management systems sending confirmations	Guest and customer emails stop	Vendor update to OAuth 2.0, or move sending to Azure Communication Services	December 2026
Monitoring, backup or security tools emailing alerts	You stop receiving warnings	OAuth 2.0 if supported, otherwise SMTP relay connector	December 2026
In-house scripts or website forms sending mail	Integrations break with no error	Re-write to use the Microsoft Graph API or OAuth 2.0	December 2026
Anything collecting mail via POP3 or IMAP4 (gateways, archivers, pollers)	Connection fails on old encryption	Update the system to support TLS 1.2 or later	July 2026
No idea what you have	Unknown exposure	Run the SMTP AUTH clients report and message trace; physically audit devices	Start now

A sensible plan for the next six months

You have until December, which sounds generous and disappears quickly once you account for vendor lead times, firmware testing and the 90-day lag on Microsoft’s reporting. A realistic schedule looks like this.

Over the next few weeks, build the inventory. Run the SMTP AUTH clients report so the data has time to populate, pull message-trace data, and walk the office listing every device and application that touches email. By the end of that exercise you should have a single list with an owner and a current authentication method against every item.

Through the middle of the year, deal with the July TLS deadline first because it arrives first, then start contacting vendors about OAuth support for everything on the SMTP AUTH list. Vendor responses are the long pole; the sooner you ask, the sooner you know which devices need firmware updates, which need replacing, and which will need a relay connector instead.

From spring onward, work through the fixes and — this is the step people skip — test each one by actually sending mail and confirming it arrives. A printer that has been reconfigured but not tested is not fixed. Aim to have everything migrated and verified well before December, so the default switch-off in late December is a non-event for you rather than a crisis.

One more piece of housekeeping worth doing at the same time: while you have the bonnet up on mail flow, confirm your domain’s SPF, DKIM and DMARC records are in good order, especially if you adopt a relay connector or a third-party sending service. Getting authentication right keeps your legitimate mail out of recipients’ junk folders and makes your domain harder to spoof.

How All IT Services can help

This is precisely the kind of change that is straightforward in principle and fiddly in practice, where the hard part is finding every affected device before it finds you. We work with professional-services firms, hospitality venues and not-for-profits across Sydney, Brisbane, the Central West of New South Wales and Melbourne, and we are already running this migration for clients ahead of the December deadline.

We can run the discovery for you — the SMTP AUTH clients report, message trace and a physical audit — produce a clear inventory of what needs to change, handle the vendor conversations and the OAuth or relay configuration, and test every device and application so nothing breaks the day the default flips. If you would rather not find out the hard way that an invoice run or a scanner has gone quiet, let’s get ahead of it now while there is time to do it calmly.

Call us on 1300 425 548 or get in touch through our contact page, and we will help you map out exactly what needs to happen before December.

1300 425 548