A Customer Service administrator at a regulated financial services firm spent most of Q1 rolling out Microsoft Purview sensitivity labels across the organization’s email traffic, a project driven by a compliance mandate that had nothing to do with the contact center. Once Dynamics 365 email sensitivity labels went live in the Customer Service workspace, the security team considered the job done. Three weeks later, a supervisor noticed that case summaries were quietly missing for a cluster of escalated tickets, and Copilot’s intent detection wasn’t firing on a subset of inbound email at all. The two projects, security and AI, had never been evaluated together, and nobody had checked whether the feature that satisfied the compliance mandate was compatible with the feature the contact center had spent the prior year building its workflows around.
That collision is becoming common enough to plan for directly. Data sensitivity labels for email reached general availability in Dynamics 365 Customer Service on May 1, 2026, giving service representatives a native way to classify and protect outbound and inbound messages using labels defined centrally in Microsoft Purview. It is a genuinely useful capability, and for regulated industries it is close to mandatory. But it was shipped as a security feature, evaluated by security teams, and its interaction with Copilot-driven case automation is easy to miss until an agent asks why a summary never generated.
What Actually Ships With the Feature
The capability itself is narrow and well-scoped: agents get a Sensitivity Label dropdown in the command bar, available both when reading an inbox item and when composing or replying to an email, inside the Customer Service workspace and Contact Center apps. Labels are not created in Dynamics 365 at all. They are authored in the Microsoft Purview compliance portal, under Information Protection, where an administrator defines the label’s name, priority, scope, and, critically, its protection settings, including whether it carries encryption, a Do Not Forward restriction, or a visual marking like a watermark or header. Once that label policy is published tenant-wide, it becomes available inside Dynamics 365 without any additional publishing step on the Dataverse side.
What surprises a lot of technical teams is how much of the actual behavior is inherited from Purview rather than configured in Dynamics 365. A label that carries an encryption policy behaves identically whether it was applied from Outlook, from Word, or from a Customer Service email form: the message becomes a protected, rights-managed object the moment the label is applied, not a cosmetic tag on a Dataverse record.
Configuring Dynamics 365 Email Sensitivity Labels: The Two-Step Setup
The rollout has two distinct halves, and skipping the prerequisites is the most common reason a pilot stalls. Before anything happens inside Dynamics 365, the environment needs an email server profile configured for Server-to-Server Authentication against the same tenant’s Exchange Online, and server-side synchronization for email has to already be running. Neither of those is new infrastructure specific to this feature, but plenty of sandbox and dev environments never had them fully wired up, since basic email testing doesn’t require them.
With that in place, enabling the feature itself is a single toggle: in the Power Platform admin center, under the target environment’s Settings, expand Email, open Email Settings, and switch on “Enable data sensitivity labels for emails.” The second half of the work happens in Power Apps rather than the admin center. Inside the relevant solution, add the Email table’s main form to the solution if it isn’t already there, open the form in the designer, locate the “Sensitivity label” column, and drag it onto the canvas. On its own that column just stores a value, so the practical step is adding the “Email sensitivity label control” component to the same field and configuring it, then saving and publishing the form. Skip that control and the column exists on the record but agents never see anything to interact with.
One detail worth flagging to the security team directly: the Entra ID identity associated with the mailbox needs its own permissions in Microsoft Purview to apply the labels that are relevant to that queue. This is a common gap in shared-mailbox and queue-based routing setups, where the mailbox identity was provisioned years ago for basic send/receive and never touched again.
How Enforcement Actually Behaves in Practice
Once labels are live, the enforcement rules mirror what a user would expect from Outlook, and that consistency is deliberate. A label like Do Not Forward or Do Not Reply restricts the corresponding action for recipients inside the organization, and an agent cannot manually downgrade a message to a less restrictive label than the one already applied, so a “Confidential” thread can’t be quietly relabeled “General” to make it easier to forward externally. Replies and forwards inherit the label of the message being responded to by default, which is the behavior most compliance teams actually want, since it removes the judgment call from the agent in the moment they’re least likely to think about it. Attachments carry their own labels independently, and when an attachment’s label conflicts with the email’s label, the interface surfaces which one takes precedence rather than silently picking one.
Where this gets operationally interesting is auto-labeling. Purview supports content-based auto-labeling, where a label gets applied automatically based on what the message contains, and that setting lives entirely in Purview, invisible from the Dynamics 365 side. A queue that starts seeing a spike in encrypted, auto-labeled mail didn’t necessarily have a policy change made against it directly. Somewhere upstream, a Purview label’s auto-apply conditions matched more content than before.
The Gap Nobody Tests For: Encrypted Mail and Copilot
This is the part of the rollout that deserves its own test plan rather than a footnote. When a label applies encryption protection, Dataverse does not decrypt or store the message content. The email still appears in the case timeline, so an agent knows the correspondence exists, but the body is not readable inside the application at all. Agents are redirected to Outlook on the web to open and decrypt the message there.
That gap propagates directly into every Copilot capability that depends on reading email content. Case summarization skips encrypted messages entirely, meaning a case summary generated near the end of a long thread may be missing the specific email that actually contains the customer’s core complaint, if that thread’s most detailed message happened to carry a Confidential-and-Encrypted label. Case enrichment, intent detection, and any Copilot workflow built around analyzing inbound email content behave the same way: they simply do not see encrypted mail, and there is no fallback summarization or partial analysis. From the AI feature’s perspective, the message is invisible, not redacted.
For a technical team that built intent-based routing or auto-summarization as part of a Copilot rollout, this means the encryption policy decided in a completely separate Purview governance project can silently degrade the reliability of automation the contact center is depending on operationally. Neither team is wrong about their own configuration. The interaction between the two simply isn’t visible from inside either admin surface on its own.
Rolling This Out Without Breaking What Already Works
The practical fix isn’t to avoid sensitivity labels, since for a regulated organization that usually isn’t optional, and blanket-disabling encryption defeats the purpose of the compliance project in the first place. The fix is sequencing the two conversations that normally never happen in the same room. Before a label policy that carries encryption goes anywhere near production mailboxes tied to Customer Service queues, pull a sample of real case threads that currently drive summarization or intent detection, and run them through the label to see which specific messages would become invisible to Copilot under that policy. That test takes an afternoon and reliably surfaces problems that would otherwise take weeks to notice in production, one confused agent at a time.
It’s also worth treating auto-labeling as a change management event even though it technically lives entirely in Purview. Any time compliance adjusts an auto-apply condition on a label with encryption attached, that change has a direct, measurable effect on Copilot coverage in the contact center, and the service delivery team should be in the notification loop for that change, not discovering it through a drop in summarization quality. Finally, agents need to know the Outlook-on-the-web redirect path exists and why it exists, rather than treating an unreadable encrypted email in the case timeline as a bug to escalate. A short addition to onboarding material covers this permanently; a support ticket every time it happens doesn’t.
Routeget has walked several clients through exactly this sequencing problem when a compliance-driven Purview rollout landed on top of an existing Copilot investment in Customer Service, and the fix is almost always coordination rather than reconfiguration. Getting the security and the AI roadmap talking to each other before go-live is considerably cheaper than untangling the symptoms afterward.
#DynamicsCustomerService #DataSensitivityLabels #MicrosoftPurview #CopilotService #EmailSecurity #ComplianceGovernance
No comment yet, add your voice below!