Two Microsoft 365 changes land in the same quarter, and both hit the quiet devices nobody in an office thinks about until they stop working. On 1 October 2026 the Exchange team wrote that "the deprecation of EWS in Exchange Online starts today". By 21 October it confirmed that retirement "is now in progress" and that tenants were already seeing EWS turned off. Then, at the end of December 2026, SMTP AUTH Basic Authentication will be disabled by default for existing tenants. That is the username-and-password login most scanners and older business apps use to send mail through smtp.office365.com.
For a small company in Dubai or Riyadh that sends from its own domain, the symptoms are dull and expensive. Scan-to-email stops. Invoices never reach the customer. A Mac user gets a password prompt every ten minutes. Below: what changes when, how to find the affected devices first, and how to move each one without landing in spam.
What exactly is changing
EWS: switched off tenant by tenant
Exchange Web Services is an old API apps use to read mailboxes and calendars. According to Microsoft's October 2026 deprecation post, setting EWSEnabled to True is no longer enough on its own: an allow list called EWSAllowedAppIDs now has to name every app that may use EWS. Microsoft filled that list on October 10-11 for tenants that had EWS explicitly enabled. Tenants that never touched the setting get a 7-day warning in Message Center. After that, Microsoft populates the allow list from 60 days of usage and sets EWSEnabled to False.
The Exchange team's troubleshooting post names the software most likely to break: Apple Mail and Calendar on macOS, classic Outlook for Mac, some Outlook desktop add-ins, outdated Outlook builds on Windows, and third-party tools such as backup applications. Admins can turn EWS back on, but only for a while. In Microsoft's words, "Re-enabling EWS will stop working in April 2027."
SMTP AUTH: Basic auth off by default at the end of December
This deadline has moved before. Microsoft's April 2024 announcement planned to start rejecting Basic auth submissions on 1 March 2026 and reach 100% rejection on 30 April 2026. In January 2026 it revised the plan: no change until December 2026, Basic auth disabled by default for existing tenants at the end of December with admins still able to enable it, no Basic auth by default for tenants created after December, and a final removal date to be announced in the second half of 2027.
So December is a change of default, not the end. But re-enabling only helps if someone knows the scanner depends on it and is at their desk in late December. Microsoft's 2024 notice documents the reply a client gets when Basic auth is refused: 550 5.7.30 Basic authentication is not supported for Client Submission. If that line shows up in a device log or an app's error screen, you have found your cause.
What usually breaks in a small office
From the software Microsoft names and what we see at customer sites:
- Multifunction printers and scanners set up with smtp.office365.com, port 587 and a mailbox password.
- Accounting, ERP or e-invoicing software that emails invoices and statements from a shared address such as [email protected].
- Website contact forms and WordPress SMTP plugins that log in with a real mailbox password.
- Mac users on Apple Mail or classic Outlook for Mac, through EWS.
- Backup, archiving and migration tools that read mailboxes through EWS.
The SMTP group carries the bigger delivery risk, because the usual fix changes the path your mail takes (step 3).
Step 1: find every device and app that depends on them
For SMTP AUTH, start in the Exchange admin center. Microsoft's original notice said the SMTP AUTH Clients Submission report would show, from mid-October 2024, whether Basic auth or OAuth is used, so it tells you which accounts still submit with a password. Then check the settings in Exchange Online PowerShell. Both commands come from Microsoft's SMTP AUTH documentation:
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
Get-CASMailbox -ResultSize unlimited | where {$_.SmtpClientAuthenticationDisabled -eq $false}The first shows the organization-wide setting. The second lists mailboxes where SMTP AUTH is explicitly enabled, which in a small tenant is usually exactly the shared mailboxes your scanners and apps log in as. Mailbox settings override the organization setting.
For EWS, search Message Center for "EWS will be disabled in your tenant in 7 days" or "EWS has been disabled in your tenant". Those are the two subjects the Exchange team tells admins to look for. Then run:
Get-OrganizationConfig | Fl EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Fl EwsAllowedAppIDsThe second command lists the apps Microsoft detected in your tenant over the last 60 days. An app you rely on that is missing from that list will stop working once EWS is restricted. Per the deprecation post, changes to EWSEnabled usually apply within an hour and can take up to 4 hours, while changes to the allow list take 24 hours. Microsoft support cannot re-enable it for you; only a tenant admin can.
Step 2: pick a replacement for each sender
Microsoft's guide for printers, scanners and line-of-business apps sets out the options. In short:
| Method | Who it can reach | Limits Microsoft states | Good fit |
|---|---|---|---|
| SMTP AUTH with OAuth, smtp.office365.com port 587 | Inside and outside your company | 10,000 recipients a day, 30 messages a minute | Devices and apps whose current firmware or version supports OAuth |
| High Volume Email, port 587 | Internal recipients only | No recipient or message rate limits | Internal reports and alerts |
| Azure Communication Services Email | Inside and outside | Set by the Azure service | Apps that cannot do OAuth but must email customers |
| SMTP relay through an inbound connector, your MX endpoint on port 25 | Inside and outside | "Reasonable limits" | Office devices on a static, unshared IP or with a certificate |
| Direct Send, your MX endpoint on port 25 | Internal recipients only | Standard anonymous throttling | Last resort |
Our view: use OAuth where the vendor's firmware supports it, put old scanners behind a connector relay from the office's static IP, and give cloud apps that email customers their own authenticated sending service. We would not build anything new on Direct Send. Microsoft's own page says it is meant for "advanced customers", that it cannot deliver to Gmail or Yahoo addresses, and that Microsoft is "working on an option to disable Direct Send by default".
One detail from the same page saves guessing: if a device "recommends or defaults to TCP port 465, it doesn't support the required versions of TLS" for client submission. That scanner needs new firmware, a relay, or replacing.
Step 3: make sure the new path passes SPF, DKIM and DMARC
With SMTP AUTH, mail left through Microsoft's servers and your existing include:spf.protection.outlook.com covered it. With a connector relay, Microsoft's guide says you need to add the office IP address "as a message source in the SPF record" or the messages risk landing in Junk. Move an app to another sending service and the sending servers change again.
Google's sender guidelines require everyone who sends to Gmail to set up SPF or DKIM, keep valid forward and reverse DNS, use TLS, and keep the spam rate reported in Postmaster Tools below 0.3%. Above 5,000 messages a day to Gmail you also need DMARC, and the From domain has to align with SPF or DKIM. Outlook.com has its own rules for high-volume senders, which we covered in our guide to the 550 5.7.515 error.
Check your current records from any terminal:
dig +short TXT yourcompany.ae
dig +short TXT _dmarc.yourcompany.ae
dig +short CNAME selector1._domainkey.yourcompany.aeThe first should return one record starting with v=spf1; Microsoft's SPF setup guide says to use only one SPF record per domain. The second should return your DMARC policy. The third should point to a Microsoft hostname if you have turned on DKIM signing in Microsoft 365, using the selector1 and selector2 CNAMEs Microsoft describes. After adding a relay IP, an SPF record looks like Microsoft's own example:
v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -allWatch the count of includes. RFC 7208, section 4.6.4 limits SPF evaluation to 10 DNS-querying terms, and every include: counts, along with the includes nested inside it. Add two or three outside services to a record and you can go over the limit, at which point SPF returns a permanent error for every message, including the ones that used to pass.
Then test: send from each migrated device to a Gmail address and an Outlook.com address you control, and open the full headers. You want spf=pass, dkim=pass and dmarc=pass for your own domain in the Authentication-Results line. On messages received by Microsoft, the same header also carries a compauth result, explained in Microsoft's anti-spam message headers reference. After the change, keep an eye on Google Postmaster Tools for your domain's spam rate, and on Microsoft SNDS if you now send from an office IP you control.
The dates in one place
- Now: Microsoft is disabling EWS tenant by tenant, with a 7-day Message Center warning before it happens (source).
- End of December 2026: SMTP AUTH Basic is disabled by default for existing tenants, and new tenants created after December do not get it by default (source).
- April 2027: the option to re-enable EWS stops working (source).
- Second half of 2027: Microsoft announces the final removal date for SMTP AUTH Basic (source).
If you do one thing this month, export the SMTP AUTH report, label each account with its device or app, and test the replacement for anything that emails customers. A scanner can wait. A billing system that silently stops sending invoices in January cannot.
Where self-hosted mail fits
Some teams read this as a reason to run their own mail server. Fair, up to a point. On your own server the authentication policy for scanners is yours: you can allow password login from the office subnet and nowhere else, and no vendor retires it on its own calendar. Receivers, though, apply the same rules to you as to Microsoft: SPF, DKIM, DMARC, reverse DNS and a clean IP. FanMail, our business email product built on Stalwart Mail Server, is available managed or self-hosted, with those records set up from the first day. If you are weighing the options, our FanMail vs Google Workspace vs Zoho Mail comparison covers cost and data control, and our piece on Exchange's last ESU update covers companies still running Exchange on their own servers.
Frequently asked questions
Will my scanner stop sending email on 1 January 2027?
It might. Microsoft says SMTP AUTH Basic will be disabled by default for existing tenants at the end of December 2026. An admin can enable it again until Microsoft announces a final removal date, which it plans to do in the second half of 2027.
Does this affect Outlook on staff laptops and phones?
Mostly not. Microsoft finished removing Basic auth from the other Exchange Online protocols in late 2022. The exceptions are classic Outlook for Mac and very old Windows builds that use EWS.
Can I point my scanner at Direct Send instead?
Only if it emails people inside your company. Direct Send cannot deliver to external addresses, Microsoft recommends it only for advanced customers, and Microsoft is working on an option to turn it off by default.
Our Mac users keep getting password prompts. Is this the EWS change?
Very likely, if they use Apple Mail or classic Outlook for Mac. Microsoft's advice is to move to the new Outlook for Mac, which is not affected. For classic Outlook, the "Microsoft Office" app ID must be in your EWSAllowedAppIDs list.
Do we need DMARC if we send fewer than 5,000 emails a day?
Gmail only requires SPF or DKIM below that volume. We would still publish DMARC, starting with p=none, because it is what stops others sending as your domain.
Sources: Microsoft Exchange Team posts of 1 October 2026, 21 October 2026, January 2026 and April 2024; Microsoft Learn on sending from devices and apps, SMTP AUTH, SPF and DKIM; Google sender guidelines; RFC 7208.
