Exchange Web Services (EWS) is approaching end of service in Exchange Online. We first announced this change was coming in 2018, when we announced that Exchange Web Services (EWS) will no longer rece...
Updated Mar 17, 2026
Version 4.0
Blog Post
On Saturday 4 April 2026, I made the following changes to my Org, which relies on Apple Mail to access ~40 Exchange Online accounts.
PowerShell:
Set-OrganizationConfig -EwsApplicationAccessPolicy True
(was previously $null)
Set-OrganizationConfig -EwsApplicationAccessPolicy EnforceAllowList -EwsAllowList @{Add="f8d98a96-0999-43f5-8af3-69971c7bb423"}
---
Next day (Sunday, yesterday), none of my users could access their Exchange accounts through Apple Mail!
---
Why? Is there a known bug here? How can I enable EWS access for Apple Mail successfully, using the Allow List and EWSEnabled=True?
---
Also, it seems there a mistake in the table in this article on the last row.
- In the last row of the table, it says that for Orgs with EWSEnabled = Null, that in Oct 2026, they will be switched to EWS Allowed = True (i.e. "All EWS Allowed"), allow list ignored.
- Then, in the sentence after the table, it says that for any tenant with EWSEnabled = Null, on 1 October, it will be switched to EWS Allowed = False, thereby blocking all EWS access.
- These 2 pieces of information contradict each other. Which is it?
The EWSEnabled property in your tenant will change on (or soon after) Oct 1, 2026, as follows:
EWSEnabled value | Before Oct 2026 | Starting Oct 2026 |
True | All EWS Allowed | Only Apps in the Allow List Allowed |
False | All EWS Blocked | All EWS Blocked |
Null | All EWS Allowed | All EWS Allowed (allow list ignored) |
Any tenant with EWSEnabled still set to Null on October 1, 2026, will see the value changed to False as the deployment rolls out. That will block EWS for all applications in the tenant at that time.
Greg Taylor - EXCHANGE
Microsoft
MicrosoftThe -EWSAllowList feature works on UserAgent strings, not AppIDs. That's why we're adding a new feature to restrict based on AppIDs alone. You need to use a variety of user agents to allow ALL the Apple macOS apps to access Exchange Online, it's a bit tricky. Maybe someone else here can share the strings they use to ensure all apps and versions of Apple's app can use EWS?
The table describes the behavior of the configured EWSEnabled value after the Oct 1st switch.
So, before Oct 1st using Null, means all EWS is allowed. After the Oct 1st, it remains unchanged. But, before/after Oct 1st, the behavior when EWSEnabled is set to True does change. Before, True means all EWS is allowed. After Oct 1st, only apps in the Allow List (which is based on AppID, and coming soon) will be allowed.
Thanks for clarifying Greg.
Since Microsoft are planning to add support for AppIDs in the -EWSAllowList, and there's one App ID for Apple Mail on MacOS (f8d98a96-0999-43f5-8af3-69971c7bb423), it sounds like the best course of action is for me to wait until that's implemented by MS, and then I can simply implement a simpler AllowList at the Org level, ensuring my entire Org continues to have access to Apple Mail.
Would you agree?
What's the timeline on AppIDs being supported in -EWSAllowList (so I can schedule doing this)?
- Greg Taylor - EXCHANGE
100% spot on. I would wait (I'm hoping we can ship this at the end of April, early May, but as with all things... until it's real, it's not real). Then it's one AppID, and not some combo of user agents. Apple use a lot of variations based on version and app. (which is actually a good thing, when it comes to troubleshooting an issue - apps that give no clue what version they are, don't help us or the developer).