Your Scanner Sends Email Through Microsoft 365. What Happens When Basic Authentication Ends?

Somewhere in your office there is probably a scanner, a printer or an old line-of-business application that emails documents using a mailbox username and password. It has worked for years, so nobody thinks about it. That is exactly why it deserves attention now.

Microsoft is changing how Exchange Online handles this, and the date is close.

What is changing

The feature in question is SMTP AUTH client submission with Basic authentication (a username and password). Microsoft's Exchange Team has set out the current timeline:

• Until December 2026: Basic authentication behaviour for SMTP AUTH stays unchanged.
• End of December 2026: Basic authentication is turned off by default for existing tenants. Administrators can still switch it back on if needed.
• New tenants created after December 2026: OAuth is the supported authentication method.
• Second half of 2027: Microsoft says it will announce a final removal date. That date has not been set.

Earlier dates (March and April 2026) were published and then pushed back, and Microsoft says the timeline was refined based on customer feedback. So treat the dates as current guidance, not a promise, and check Microsoft's post before you plan around them.

Why this matters beyond one setting

Microsoft's own documentation notes that virtually all modern email clients, such as Outlook and Outlook on the web, do not use SMTP AUTH to send mail. The things that do are typically:

• Multifunction printers and scanners that email scans.
• Reporting servers and older business applications.
• POP3 or IMAP clients, which need SMTP to send.

Microsoft also says that if security defaults are enabled in your tenant, SMTP AUTH is already disabled. So the first sign of trouble may be a scanner that quietly stops working, rather than a warning.

Your options, and the trap to avoid

Microsoft lists several ways for devices and applications to send mail through Microsoft 365. In summary:

• Client SMTP submission with OAuth: Microsoft recommends modern authentication here. It needs a device or app that supports it, and TLS 1.2 or later.
• High Volume Email: for sending to internal recipients only.
• Azure Communication Services Email: for internal and external recipients.
• SMTP relay through a connector: authenticated by a certificate (recommended) or a static public IP address.
• Direct Send: unauthenticated mail sent to your own mailboxes.

Direct Send is the tempting shortcut, because it needs no password. Microsoft's guidance is blunt about it: most customers do not need it, it is recommended only for advanced customers willing to take on the responsibilities of email server admins, and it should be chosen only when a legacy device supports none of the other methods.

There is a security reason for the caution. Proofpoint reported a campaign in July 2025 in which attackers used Direct Send to deliver spoofed messages that appeared to come from inside the target organisation, without needing a valid account or password. Proofpoint notes that Microsoft often flagged these messages, but they were still delivered to users' junk folders. Its suggested mitigation is to check whether you actually use Direct Send and, if you do not and it is appropriate, enable the Reject Direct Send setting. Note that "if appropriate" matters: turning it off can break a legacy device that relies on it, so test first.

A practical checklist

1. Inventory senders. List every scanner, printer, application and service that sends email using your domain.
2. Find who uses SMTP AUTH. Microsoft's documentation shows how to see which mailboxes have it enabled, and how to disable it organisation-wide while enabling it only for mailboxes that still need it.
3. Pick the right method for each sender. Prefer OAuth or a certificate-based connector. Avoid Direct Send unless nothing else works.
4. Fix the DNS basics. SPF, DKIM and DMARC should be correct for any method that sends as your domain. Our guide to SPF, DKIM and DMARC covers how to roll them out without breaking mail.
5. Retire what you can. If a device cannot support modern authentication or TLS 1.2, Microsoft says it cannot use client SMTP submission at all. That is a replacement conversation, not a setting.
6. Test before December. Do it on a quiet day, not after the scanner stops working.

The bigger picture

This is a small example of a common pattern. A default that made sense in 2015 becomes a risk in 2026, and the people who notice are the ones who keep an inventory. If you want to see how this fits with other gaps, our piece on Microsoft 365 security beyond the defaults is a good next read.

A calm takeaway

You do not need to panic, and you do not need to act today. But a few hours spent listing what sends mail from your domain, and deciding how each one should authenticate, is far cheaper than discovering it when invoices stop arriving. If you would like a second pair of eyes on your tenant, our cybersecurity services team can help you map it out.