Dynamics 365 Apps
From the field archive · Learned in 2020
Email in Dynamics 365: Mailbox Enablement, Server-Side Sync and Domain Authentication
The email problems I worked on most often in 2020 and 2021, why they happened, and how the setup looks in 2026.
If you asked me which part of a Dynamics 365 rollout generated the most email to my inbox in 2020, the honest answer is email itself. Mailboxes that wouldn't enable on go-live weekend. Shared mailboxes that needed to become queues. Encrypted messages that never showed up. A marketing team that couldn't send from its own domain. None of these were exotic. They were the same few gates, missed in the same few ways.
Server-side synchronization is still how Dynamics 365 and Dataverse apps connect to Exchange. The Email Router stopped working in April 2021, and the legacy Outlook COM add-in gave way to Dynamics 365 App for Outlook. Mailbox approval no longer requires a Global or Exchange admin for every mailbox: a Delegated Mailbox Approver role exists now. Dynamics 365 Marketing is now Customer Insights - Journeys, and its outbound marketing module has reached end of life; real-time journeys is the path forward. Domain authentication is still the step that decides whether your marketing email gets delivered.
01The three gates for every mailbox
This is a common point of confusion. Licensing a user doesn't make their email work in Dynamics 365. Every user or queue mailbox has to pass three gates, and each one has a different owner.
| Gate | What it does | Who usually owns it |
|---|---|---|
| Server profile and sync methods | Points the mailbox at Exchange Online and sets incoming, outgoing, and appointments/contacts/tasks to server-side synchronization | Dynamics admin. Set it as the default for new users so you don't fix it mailbox by mailbox. |
| Approve email | Confirms the email address is allowed to be processed | Global or Exchange admin, or a delegated approver (see next section) |
| Test & Enable | Tests incoming and outgoing configuration and enables the mailbox for processing | Dynamics admin. Results land in the mailbox status columns and alerts. |
When a mailbox fails, the alert on the mailbox record usually tells you which gate. Depending on the error, the app retries later or disables the mailbox for processing, so a mailbox that worked yesterday can need attention today.
During a staffing firm's go-live weekend in June 2020, a list of several dozen users came back with mailboxes that wouldn't enable. The support ticket was already open. Rather than rerun the whole batch, I asked their systems engineer to rerun Test & Enable for one failed user first, confirm the result, and then work through the rest. When dozens fail at once, there's usually one shared cause. Fixing one mailbox tells you what it is.
02Approval: then and now
In 2020, approving mailboxes meant finding someone with Global or Exchange admin rights during a cutover window. That was often the slowest step of the weekend.
Today a Global or Exchange admin can assign the Delegated Mailbox Approver security role in Dynamics 365. A user with that role, plus System Administrator, can approve mailboxes in that environment without holding a tenant admin role. Because it's a Dynamics 365 security role, it's assigned per environment, and it can't be assigned to a team.
- Plan the approver before go-live. Assign the delegated role to your Dynamics admin in each production environment ahead of time.
- Know the self-approval rule. Users can approve their own mailbox when their UPN matches the mailbox email and other conditions are met. Test & Enable then approves it as part of the process.
- Decide whether to require approval at all. The "Process emails only for approved users/queues" settings are on by default. Turning them off is a security decision, so document who made it.
- Automate carefully. Approval can't be done from plug-ins or workflows. External applications can do it through the SDK if the caller is authorized.
03Shared mailboxes as queues
A request I answered in mid-2020: a genomics company wanted a shared support mailbox to feed Dynamics 365. My advice then still holds. If it's a shared mailbox, set it up as a queue, connect the queue's mailbox to Exchange Online, and every incoming message is tracked as an email activity. Then layer rules on top, such as creating cases automatically from email and routing them.
One thing I'd add now: queue mailboxes are often the biggest source of tracked email. Check the incoming email filter on the queue before go-live. My post on activity growth explains how that one setting shows up on your storage bill a year later.
04Encrypted email
A large automaker's HR service team rolled out email encryption in 2020, and agents stopped seeing some of those messages in Dynamics 365. A few things were tangled together: S/MIME encryption, digitally signed messages, and agents opening encrypted mail from generic accounts versus true shared mailboxes. We brought in an Exchange specialist, because the questions were as much about Exchange as about Dynamics.
The documented limit is the place to start. If you use server-side sync, you won't be able to view S/MIME encrypted messages, because S/MIME requires an S/MIME control that server-side sync doesn't support. Microsoft also says using encryption software together with server-side synchronization isn't supported.
Before you turn on any message encryption policy, test four cases in a sandbox mailbox: plain, signed only, encrypted only, and signed and encrypted. Decide with your security team what agents must see inside Dynamics 365 and what can stay in Outlook. Have a rollback plan. That team had to reverse the change in production while they sorted it out.
05When sync misbehaves
Some sync problems sit between Exchange and Dynamics 365, and that's where cases stall. In late 2020 a customer had a handful of users whose synced calendar items kept growing until their mailboxes stopped syncing. There was an Exchange case and a Dynamics case, and it wasn't obvious which side held the root cause.
My recommendation was the same one I'd give today:
- Open a support case with the Dynamics team and get it linked to the Exchange case, so both look at one problem.
- If you can, leave one impacted user untouched until engineers are engaged. Fixing everyone first destroys the evidence.
- Collect the mailbox alerts and the server-side synchronization error details before you clean anything up.
- Use the server-side synchronization monitoring and troubleshooting guidance to rule out configuration issues first.
06Marketing email and domain authentication
In spring 2021 a marketing team at that large automaker couldn't send from the corporate domain. Their DNS policy restricted the kind of records the marketing service needed, and the request was bouncing between teams. Most of my time went into finding the right DNS owner and getting every participant onto one email thread instead of three. The TXT ownership record got published quickly. The two DKIM CNAME records took longer, because they went through a separate DNS change process.
The steps in Customer Insights - Journeys are similar today. Under Settings > Email marketing > Domain authentication, a wizard walks you through four DNS records:
| Record | Purpose |
|---|---|
| TXT | Proves you own the domain |
| CNAME 1 and CNAME 2 | DKIM signing |
| CNAME (Envelope-From) | Return-Path alignment and SPF |
After you select Verify, the dashboard shows exactly which record failed. Every new instance comes with a pre-authenticated domain ending in dyn365mktg.com, but Microsoft says it's for testing only and you should authenticate your own domain before you go live. If a domain already has a CNAME that blocks the TXT record, there's a documented alternative: publish the TXT record on a dedicated subdomain instead.
The DNS work was never technically hard. The delay was organizational: who owns DNS, what ticket type to use, and whether a third-party CNAME is allowed at all. Today I ask for the DNS owner's name in the first planning meeting for any Customer Insights - Journeys project.
07A reporting gotcha: which date is right?
In early 2021 that genomics company asked why, for a small share of their emails, the "date sent" and the activity's actual end date were hours or even days apart. In that investigation, the pattern was:
- Created On is when the record was created in Dynamics 365. For email tracked from Exchange, it can be later than when the email was actually sent.
- Date Sent was populated for email sent from the app. Email that originated in Outlook didn't have it.
- Actual End was populated for both.
I suggested reporting on Actual End rather than adding a custom column and a plug-in to fill it. Validate this against your own data before you change a report, but agree on one date column up front. It saves a lot of reconciling later.
Where I'd start
Set server-side synchronization as the default for new users, assign the Delegated Mailbox Approver role before go-live, and test and enable a pilot group first. Check queue tracking filters before you connect a shared mailbox. If you encrypt email, test it in a sandbox against server-side sync before production. And if Customer Insights - Journeys is on the plan, get your DNS owner involved in week one, not the week you want to send.
Happy to go deeper on any of this.
— K.G
Related: Environment strategy and DLP and the 2026 governance toolbox.
Sources
- Microsoft Learn: Connect to Exchange Online
- Microsoft Learn: Set up server-side synchronization of email, appointments, contacts, and tasks
- Microsoft Learn: Integrate (synchronize) your email system
- Microsoft Learn: Troubleshooting and monitoring server-side synchronization
- Microsoft Learn: Authenticate your domains (Customer Insights - Journeys)
- Microsoft Learn: Troubleshoot domain authentication errors in Customer Insights - Journeys
- Microsoft Learn: Transition overview (outbound marketing to real-time journeys)
Get new posts by email
Provider: your email provider
