Microsoft purview exchange online DLP duplicate events and alerts

This is documented behaviour rather than a bug, though there is something to check in your rule configuration and there is a setting that will stop it.

WHY MULTIPLE EVENTS APPEAR FOR ONE MESSAGE

Rules in a policy are processed in priority order. When content matches more than one rule, the first rule evaluated that has the most restrictive action is the one enforced, but the documentation is explicit that matches for all of the rules are recorded in the audit logs and shown in DLP reports, even though only the most restrictive rule is applied.

So two events does not mean the message was scanned twice. It means two rules matched, one action was taken, and both matches were logged.

https://learn.microsoft.com/purview/dlp-policy-reference 

THE FIRST THING TO CHECK

Open both events in Activity Explorer and compare them. Two questions decide which path you are on.

Are both rows the activity type DLP rule matched, or is one of them a related activity row rather than a second rule match? Activity Explorer records rule matches alongside the associated activity, so two adjacent rows are not always two matches.

If both are genuine rule matches, which rule does each one name? If they name two different rules, your count ranges are overlapping in practice even though they look mutually exclusive on paper.

WHY MUTUALLY EXCLUSIVE RANGES CAN STILL BOTH MATCH

The instance count you configure applies per sensitive information type, not per message. A message carrying 60 instances of one SIT and 5 instances of another will match your High rule on the first and your Low rule on the second. Both are correct, both get logged, and only the most restrictive action is enforced.

Worth opening each rule and checking exactly which SITs are listed and what the minimum and maximum instance count is on each one. A maximum left empty behaves as Any, which silently overlaps the range above it.

HOW TO STOP THE DUPLICATE LOGGING

Under Additional options in each rule there is a setting to stop processing further rules when that rule matches. The documentation notes that this is supported for Exchange and Teams locations, so it is available to you.

Set it on your High rule so that a high severity match ends evaluation and does not also log a Medium or Low match.

Before you do, check the rule order. For hosted service locations like Exchange, each rule is assigned a priority in the order in which it was created. The rule created first has first priority. If you built Low, then Medium, then High, your Low rule is being evaluated first, and putting the stop setting on the wrong rule will suppress the severity you actually care about. Confirm High is evaluated first, then apply the setting.

ON ACTIONS THAT ALREADY HALT PROCESSING

Some actions stop subsequent rule processing on their own. Restrict access or encrypt the content in Microsoft 365 locations is one of them, and when it triggers, no further rules or policies are processed. If your High rule only notifies rather than restricting, that is another reason lower rules keep evaluating.

ON THE ALERTS, WHICH ARE A SEPARATE MECHANISM

Do not assume duplicate alerts have the same cause as duplicate events. Single event alerts are aggregated when events from a single rule occur within a one minute window on E5, or fifteen minutes on E3. That aggregation is per rule, so matches on two different rules produce two alerts by design even inside the window.

There is also user and rule based alert aggregation, currently in preview, which aggregates per rule per user. Worth looking at if the volume is the real problem rather than the duplication itself.

https://learn.microsoft.com/purview/dlp-alerts-get-started 

WHAT I WOULD DO IN ORDER

Confirm whether the two events name the same rule or two different rules. If two different rules, inspect the SIT list and instance counts in each. Then verify rule priority order, and set stop processing more rules on the highest severity rule. Recheck after a fresh test message rather than looking at historical events, since existing entries will not be rewritten.