Dynamics 365 On-Premises Email Sync Is on Borrowed Time — Here's the Graph API Path Forward
If you're running Dynamics 365 Customer Engagement (on-premises) with Exchange Online for email server-side synchronization, there's a hard deadline coming, and it's closer than most teams realize. This post breaks down exactly what's deprecated, what isn't, the dates that matter, and why building a custom Microsoft Graph API integration is the realistic path forward if you're staying on-premises.
First, let's clear up what's actually deprecated
There's a lot of loose talk about "server-side sync being deprecated." That's not quite right, and getting it right matters for planning.
✕ Deprecated
- The Email Router — deprecated in 2018, stopped functioning entirely on April 12, 2021. If you're still on this, you're already unsupported.
- The legacy Dynamics 365 for Outlook (Outlook COM add-in) — retired October 1, 2020, with removal completed by December 4, 2020.
✓ Not deprecated
- Server-side synchronization itself — Microsoft still documents it as the preferred sync method for Dynamics 365 Customer Engagement (on-premises).
The real issue isn't server-side sync as a feature. It's the protocol underneath it when your on-premises Dynamics 365 talks to Exchange Online specifically.
The actual problem: EWS is being retired for Exchange Online
Dynamics 365 Customer Engagement (on-premises) connects to Exchange Online using Exchange Web Services (EWS). Microsoft is retiring EWS for Exchange Online — full stop, no exceptions, no successor built into the on-prem product.
Key facts
- EWS deprecation was first announced in July 2018 (no further feature updates).
- The October 2026 disablement date was set in 2023.
- The January 2024 Midnight Blizzard nation-state security incident involved EWS and accelerated the urgency of the whole effort — Microsoft explicitly widened the scope from third-party apps to its own products.
- Microsoft names Dynamics 365 directly as one of the Microsoft products it is actively removing EWS dependencies from, alongside Outlook, Office, and Teams.
Worth knowing
This only affects Exchange Online. If your Dynamics 365 on-premises deployment syncs against a fully on-premises Exchange Server, none of this timeline applies to you — EWS is not being removed from Exchange Server on-premises.
The dates that matter for on-prem + Exchange Online
Microsoft has a dedicated page for exactly this hybrid configuration, and it spells out the end-of-life on a specific timeline.
Two things worth sitting with
- If you're on v8.0, this deadline has already passed. You're currently running an unsupported email integration.
- Microsoft's own stated remediation on that page is not "here's the Graph-based replacement." It's "migrate to Dynamics 365 (online)" or "connect to an on-premises Exchange Server instead." There is no first-party Graph-based drop-in replacement for this specific connector. If you're staying on-prem CE and staying on Exchange Online, Microsoft is not building you a fix.
Why not just wait for Microsoft to add Graph support?
Because the parity gap between EWS and Microsoft Graph isn't fully closed yet — even Microsoft admits this on the EWS deprecation page, listing several feature areas (mailbox import/export, public folder handling, in-place archive, and others) still being worked on as of this writing. For a legacy on-premises product line, closing that gap for CE specifically is not a stated priority. Waiting is a bet against a roadmap Microsoft hasn't committed to.
If you need to keep on-prem Dynamics 365 talking to Exchange Online mailboxes past 2027, the practical options are:
Migrate to Dynamics 365 online
Microsoft's recommended path, and the one it's actively pushing you toward.
Move to on-premises Exchange Server
Sidesteps the EWS retirement entirely, since it doesn't apply to Exchange Server.
Build a custom Graph API integration
Replace the EWS-based sync yourself, if migrating off on-prem CE or off Exchange Online isn't feasible in your timeline.
This post focuses on option 3, since it's the one that requires the most planning and the one Microsoft provides the least direct guidance on.
The alternative: building email integration on Microsoft Graph API
Microsoft Graph is the REST/JSON API that has replaced EWS as the supported way to access Exchange Online mailbox data — messages, folders, attachments, and change notifications — all through modern OAuth 2.0 authentication instead of legacy protocols.
There's already a precedent for this inside the Dynamics 365 ecosystem: the Dynamics 365 App for Outlook (Mail App) uses Graph API for its own authentication and mail operations.
That precedent is useful, but it's scoped to the Outlook add-in experience — it is not a full replacement for server-side sync's job of pulling every mailbox's email into Dynamics 365 as tracked activity records. For that, you need to build the pipeline yourself.
What the architecture looks like
Sync pipeline
Because Dynamics 365 CE on-premises has no native Graph-based sync engine, you need a middleware layer sitting between Graph and your on-prem Dataverse instance. This is the core architectural difference from server-side sync: instead of Dynamics 365 talking directly to the mail server, you're building and maintaining the connective tissue yourself.
Step-by-step build
Register an application in Microsoft Entra ID
Go to the Entra ID admin center → App registrations → New registration. Decide between:
- Application permissions (daemon/service account model — no signed-in user, requires admin consent, better fit for a background sync service covering many mailboxes).
- Delegated permissions (tied to a signed-in user's consent — simpler for single-mailbox scenarios, not practical at scale).
Grant the right Graph API permissions
For a full read/write mail sync, you'll need:
Mail.Read(orMail.ReadWriteif you need to modify/move messages)Mail.Send(for outbound email from Dynamics 365)offline_access(for delegated flows needing refresh tokens)
Application permissions require admin consent — grant this deliberately and scope it to only the mailboxes you need via application access policies, rather than tenant-wide mail access.
Choose your authentication method
Certificate-based authentication is the safer long-term choice for a background service over client secrets, which expire and are easier to leak. Store the certificate securely (Azure Key Vault, or equivalent for on-prem).
Decide: polling vs. webhooks
- Polling
/me/messagesor/users/{id}/messageson an interval is simpler to build but has higher latency and consumes more API calls (subject to Graph throttling). - Change notifications (webhooks) give near-real-time updates but require a publicly reachable HTTPS endpoint and a subscription renewal job, since Graph mail subscriptions expire (roughly every 3 days) and must be renewed proactively.
Build the middleware service
This is the piece that doesn't exist out of the box. An Azure Function or a Windows service that:
- Authenticates to Graph and retrieves/receives mail data.
- Authenticates to your on-premises Dynamics 365 instance (via its IFD/OAuth-secured Web API endpoint).
- Creates or updates email activity records in Dataverse.
Map data fields
Translate Graph message properties — conversationId, internetMessageId, sender/recipient addresses, attachments — into Dynamics 365 email activity fields, and resolve addresses to the correct contact, lead, user, or queue records.
Handle outbound send
Trigger /me/sendMail or /users/{id}/sendMail from a Dynamics 365 plugin or workflow when a user sends email from within the CRM, and correlate the sent message back to the originating activity record.
Build in throttling, retry, and error handling
Graph enforces per-app and per-mailbox rate limits. Your service needs backoff logic and a dead-letter path for failed syncs, mirroring the alerting that server-side sync gives you natively today.
Replicate mailbox provisioning
Server-side sync's "Test & Enable Mailbox" step has no Graph equivalent out of the box — you'll need your own process (manual or scripted) to associate each Exchange mailbox with the correct Dynamics 365 user or queue record.
What you're actually signing up for
This is the part that's easy to underweight in a project plan: you are not swapping one connector for another. You're taking on ownership of authentication, token lifecycle, webhook reliability, throttling, retry logic, and every future breaking change Microsoft makes to Graph — permanently. Server-side sync gave you a supported, patched, Microsoft-monitored integration. A custom Graph build gives you full control, but every piece of that control is now your team's responsibility to build, test, and maintain.
That trade-off is worth making if you're locked into on-premises Dynamics 365 and can't migrate to Dynamics 365 online or on-prem Exchange Server before April 2027. It's not worth making just to avoid a migration project that Microsoft is already steering you toward.
Where to go next
If you're not sure which version you're running: check now. If it's v8.0, your support window for this configuration already closed on May 25, 2026.
If migration to Dynamics 365 online is feasible, Microsoft's guidance is the fastest and lowest-risk path: Dynamics CRM (on-premises) to Dynamics 365 migration ↗
If you're staying on-premises and need to keep Exchange Online in the picture past April 2027, start scoping the Graph API build now — this is a multi-month engineering effort, not a weekend project, and the clock is already running.
The bottom line
Server-side sync isn't dead — but its only supported path to Exchange Online, EWS, is being switched off permanently on April 1, 2027. If you're on v8.0, that clock already ran out. Everyone else has three real options: move to Dynamics 365 online, move to on-premises Exchange, or own a custom Microsoft Graph integration for good. There's no fourth option where you wait and Microsoft builds it for you.
Related reading
IntegrationDual-Write Between Dynamics 365 (Dataverse) and Finance and Operations: Setup, Master Data, and Troubleshooting
A working runbook for linking Dataverse and Finance and Operations: prerequisites, the linking wizard, master data maps, Entra ID app users, the health check, and the errors you'll actually hit.
IntegrationIntegrating Social Media Engagement with Dynamics 365 Customer Insights – Journeys: What Actually Works in 2026
The native social-posting module is being retired, the old Hootsuite connector targets a different product, and X's API pricing has changed twice. Here's the architecture that actually holds up.