When Security Labels Meet Enterprise Applications: A Real-World Lesson from Dynamics 365 and Microsoft Purview

 

In today's security-conscious environments, many organizations rely on Microsoft Purview Sensitivity Labels and Data Loss Prevention (DLP) policies to protect sensitive information. On paper, the model is straightforward: apply a sensitivity label, have DLP enforce encryption, and ensure confidential content is protected wherever it travels.

Recently, I was involved in investigating a scenario that highlighted an important product behavior many organizations may not be aware of.

The Scenario

An organization had implemented two sensitivity labels:

• Official
• Official Sensitive

These labels were published to users through a manual label policy, while email encryption was enforced through a DLP policy targeted at the same user group.

The expected outcome was simple:

• Emails sent from Outlook with the Official Sensitive label were delivered encrypted.
• Emails sent from Dynamics 365 using the same label should also be delivered encrypted.

However, only the Outlook scenario worked as expected.

When emails were sent from Dynamics 365 using a generic outbound notification mailbox, recipients received a normal email. The sensitivity label text was visible, but the message itself was not encrypted.

At first glance, this appeared to be a configuration issue. But after a detailed investigation with Microsoft Support, the findings told a different story.

Initial Investigation

Several observations quickly became apparent:

Outlook behaved correctly

When users selected the Official Sensitive label in Outlook:

• The label was applied.
• DLP detected the content.
• Encryption was successfully enforced.

Dynamics 365 behaved differently

When the same user sent an email from Dynamics 365:

• The sensitivity label appeared in Dynamics.
• The DLP policy detected the email.
• Encryption was not applied.

This raised an important question:

If the DLP policy can detect the email, why can't it encrypt it?

Understanding the Root Cause

The key detail was that Dynamics 365 was sending outbound messages using a shared mailbox.

Microsoft confirmed that this behavior is expected by design.

While Exchange DLP can inspect emails sent from a shared mailbox, Exchange Online cannot apply encryption actions in the same way it can for a licensed user mailbox.

The reason lies in how shared mailboxes are implemented.

A shared mailbox:

• Does not have its own username and password.
• Does not authenticate as an independent user identity.
• Does not possess the same security context as a licensed user mailbox.

As a result, Exchange Online cannot assign or apply encryption keys in the same manner as it would for a regular user mailbox.

In practical terms:

✅ DLP can inspect the message.

✅ DLP can determine that the policy conditions are met.

❌ DLP cannot perform the encryption action when the email originates from a shared mailbox.

This is not a tenant misconfiguration.

It is not a Dynamics 365 issue.

It is a product design limitation.

Why This Matters

Many enterprise systems use shared mailboxes for outbound communication, including:

• Dynamics 365 Customer Engagement
• Customer Service platforms
• Case management solutions
• Automated workflow systems
• Notification engines

Security teams often assume that if sensitivity labels and DLP encryption work in Outlook, they will behave identically when emails are generated by business applications.

That assumption can lead to gaps between expected and actual security outcomes.

The lesson is simple:

Security controls should always be validated across every business process, not just user-facing applications.

Key Takeaways for Architects and Security Teams

1. Understand the difference between labeling and encryption

A sensitivity label being visible does not necessarily mean encryption has been applied.

Always validate:

• Label application
• Transport behavior
• Recipient experience

as separate controls.

2. Shared mailboxes are not equivalent to user mailboxes

Many security capabilities assume a mailbox has an authenticated user context.

Before designing controls around shared mailboxes, review the platform limitations and supported scenarios.

3. Test business applications separately

Testing Outlook alone is not sufficient.

If sensitive communications are sent from:

• Dynamics 365
• Power Platform
• Service platforms
• Custom applications

those channels should be validated independently.

4. Consider encryption requirements early

If regulatory or contractual obligations require encrypted outbound communications, the mailbox architecture should be evaluated during solution design rather than after deployment.

The Bigger Picture

This investigation reinforced an important architectural principle:

Security controls are only as effective as our understanding of the platforms implementing them.

As organizations continue integrating Microsoft Purview, Dynamics 365, Exchange Online, and Power Platform capabilities, it becomes increasingly important to understand where product boundaries exist.

Not every limitation is a bug.

Sometimes the platform is behaving exactly as designed.

The challenge for architects is identifying those design boundaries early and incorporating them into solution decisions, governance policies, and security assurance activities.

Have you encountered similar situations where a security control behaved differently across Outlook, Dynamics 365, Power Platform, or another enterprise application? I'd be interested to hear how your organization approached the challenge.

#MicrosoftPurview #Dynamics365 #Microsoft365 #CyberSecurity #InformationProtection #DataLossPrevention #Compliance #PowerPlatform #SolutionArchitecture #EnterpriseArchitecture #SecurityGovernance #DigitalTransformation