Microsoft Purview: Inconsistent DLP rule behavior with exclusions — Unexpected message matches despite exclusions

Question

Microsoft Purview: Inconsistent DLP rule behavior with exclusions — Unexpected message matches despite exclusions

Chris Irving 0

Problem description

I am experiencing an issue with a Microsoft Purview Data Loss Prevention (DLP) rule configured to exclude messages that are Encrypted or Permission Controlled. Despite these exclusions, Activity Explorer shows that certain messages, including those containing sensitive information like a test U.S. Social Security Number, are still matching the rule. I am seeking clarification on why this discrepancy occurs and how to ensure the rule's exclusions are functioning correctly.

Environment

Microsoft Purview DLP in Exchange email within Microsoft 365, region not specified in case information.

What I've already tried

I have reviewed the rule configuration manually in the Purview policy editor to confirm that the exclusions for Message Type = Encrypted and Permission Controlled are present. I compared the rule behavior with an Activity Explorer event showing a match on an email containing sensitive information. The troubleshooting is limited to initial validation at case intake; no additional diagnostic outputs or configuration changes have been documented.

Current status

I am seeking assistance to understand why messages are matching the rule despite the exclusions and how to verify the message's encryption or permission control status at the time of evaluation.

Charan Venkat Sai Thambi 0 Reputation points Microsoft External Staff Moderator

2026-10-08T20:27:14.1733333+00:00
Hello Chris,

Thank you for reaching out regarding the Microsoft Purview DLP behavior.

The behavior you are seeing may depend on how Microsoft Purview DLP classified the message when it was evaluated.

For Exchange DLP, the Message type exceptions specifically identify:

Encrypted as S/MIME

Permission controlled as Rights Management

Therefore, a message that appears encrypted or protected may not necessarily meet one of these specific message-type exceptions. If the exception doesn't apply, other conditions in the rule, such as detecting a U.S. Social Security Number, may still cause the rule to match.

Recommended action

We recommend testing with one affected message and:

Confirming whether it was protected using S/MIME or Rights Management.

Verifying that the Encrypted / Permission controlled exceptions are configured in the same DLP rule shown in Activity Explorer.

Reviewing the corresponding Activity Explorer event to determine which conditions contributed to the match.

If the message is confirmed as S/MIME encrypted or Rights Management protected and the exception was already active when the message was evaluated, we recommend investigating the specific DLP event and message details further.

For additional information, please refer to:

Microsoft Learn: DLP Exchange conditions and actions

Microsoft Learn: Activity Explorer

I hope this helps clarify the behavior and provides a clear path to validate the DLP rule.