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
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).