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 20

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.
Charan Venkat Sai Thambi 0 Reputation points Microsoft External Staff Moderator

2026-10-28T19:52:46.5333333+00:00

Hello Chris,

Greetings of the day!

We noted that you raised a service request regarding the issue, so we have engaged the relevant team to investigate it further.

Thank you.

Answer accepted by question author

0 additional answers

Your answer

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.
Charan Venkat Sai Thambi 0 Reputation points Microsoft External Staff Moderator

2026-10-28T19:52:46.5333333+00:00

Hello Chris,

Greetings of the day!

We noted that you raised a service request regarding the issue, so we have engaged the relevant team to investigate it further.

Thank you.

Answer 1

Hi Chris Irving & thx for join me at Q&A platform,

key detail is that Purview DLP's Message Type exclusions refer to specific encryption technologies, not every message that appears encrypted.

Microsoft defines these exceptions as:

Encrypted: S/MIME-encrypted messages.

Permission Controlled: Messages protected using Rights Management, Office 365 Message Encryption (OME), or sensitivity labels with encryption.

https://learn.microsoft.com/en-us/purview/dlp-exchange-conditions-and-actions

I'd first verify how the affected messages were actually protected at the time DLP evaluated them. TLS transport encryption, for example, doesn't satisfy either exception.

Check the Activity Explorer event for the exact policy and rule that matched. Confirm that both exclusions belong to that rule and were active when the message was processed.

u can verify the effective configuration using Security & Compliance PowerShell

Get-DlpComplianceRule -Identity "YourRuleName" |
    Format-List Name,ExceptIfMessageTypeMatches

Pls test separate messages using S/MIME and Microsoft Purview sensitivity-label encryption, then compare their DLP events.

If a correctly protected message still matches the same rule despite an active exclusion, open a Microsoft Purview support case with the rule configuration, message trace details, and Activity Explorer event information.

That would help distinguish an encryption-type mismatch from a possible DLP evaluation issue.

Best regards,

Alex Burlachenko

💬 P.S. Did this help? Mark it as the solution: it keeps me motivated!

➕ Follow me on Q&A for more answers

📝 And feel free to visit my blog → https://ctrlaltdel.blog/

Chris Irving 20 Reputation points

2026-10-29T19:56:23.89+00:00

Thank you. I am working with support now. the steps you gave were great.

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

Problem description

Environment

What I've already tried

Current status

Recommended action

0 additional answers

Your answer