Why EWS Impersonation Breaks: It's Not Throttling
When EWS impersonation starts failing on specific mailboxes, the real cause is usually a scoped Application Access Policy, not throttling. Diagnosis and fix inside.
When a stable EWS integration suddenly starts failing on a subset of mailboxes, the instinctive suspect is throttling — but genuine Exchange Online throttling scales cleanly with request volume and resolves once you back off. The increasingly common cause instead is a scoped Application Access Policy: many tenants now apply mailbox scope groups as a default hardening step without touching the app's actual ApplicationImpersonation right or the service account's RBAC role, so the app quietly loses reach to mailboxes as group membership drifts over time, producing mailbox-specific, intermittent failures.
Distinguishing the two comes down to one question: do failures correlate with volume, or with specific mailboxes? HTTP status codes alone can't tell you, since a 503 throttling response and a 403 access-denied response look similar at that level — you need to inspect the response body (X-MS-Diagnostics or the SOAP fault) to know which one you're actually facing. Checking the Microsoft 365 unified audit log around policy changes often reveals the real trigger happened weeks before anyone noticed.
The fix has two layers: short-term, replace static scope groups with an attribute-driven dynamic distribution group so membership updates itself instead of relying on manual maintenance. Long-term, move away from tenant-wide impersonation altogether toward RBAC for Applications, assigning narrowly scoped, resource-specific roles directly to the app registration. Since EWS itself is on Microsoft's retirement path in favor of Graph API, doing this permission-model migration first turns one large risky change into two smaller, safer ones.