Microsoft Purview Data Loss Prevention Diagnostics Explained
- 10 hours ago
- 6 min read

Introduction
If you work with Microsoft Purview regularly, you’ll know that testing and troubleshooting policies can take a bit of patience, especially in larger Microsoft 365 environments where there are multiple policies, exceptions, and workloads all interacting with each other.
In any moderately sized tenant, it’s completely normal to have a mix of different configurations across Exchange, SharePoint, OneDrive, Teams, and endpoints, which can make it harder to quickly work out why something is or is not happening as expected.
You’ve probably been in that situation where you’ve created or updated a Data Loss Prevention (DLP) policy, it shows as synced, but the result still isn’t quite what you expected. At that point, it’s easy to start wondering whether the policy is still propagating, whether a specific user or location was missed, whether the rule scope is correct, or whether the client app being used supports the behaviour you were expecting, such as a policy tip in Outlook.
That’s exactly where Microsoft Purview Data Loss Prevention Diagnostics comes in. It gives you a much easier way to verify what’s happening behind the scenes, so you can spend less time guessing and more time pinpointing whether the issue is with policy scope, configuration, client support, or simply timing.
Table of contents
TL;DR
Microsoft Purview Data Loss Prevention Diagnostics helps you quickly check why a DLP policy is not working as expected, especially when a policy says it has synced but nothing seems to be happening.
You can use it to check whether the issue is caused by propagation delays, policy scope, a missing user or location, alerting, endpoint DLP, file matching, or policy tips in Outlook on the web.
To use it:
=> Microsoft Purview portal > Solutions > Data Loss Prevention > Diagnostics -> choose the relevant DLP scenario -> enter the requested details -> select Check for issues
Useful Microsoft links:
Microsoft Purview Data Loss Prevention Diagnostics
At its core, Microsoft Purview Data Loss Prevention Diagnostics is a built-in troubleshooting tool that helps you figure out why your DLP policies aren’t behaving the way you expect them to. Instead of guessing, jumping between workloads, or running multiple PowerShell commands, you can run targeted checks directly from the Purview portal and get actual insights into what’s going on.
Behind the scenes, when you run a diagnostic, it:
Executes Check-PurviewConfig to validate tenant configuration
Runs additional scenario-specific cmdlets depending on the issue selected
What you get back is genuinely useful, including what’s configured, what might be misconfigured, and in some cases, suggestions on how to fix the issue.
To run these diagnostics, you’ll need to be an administrator and have the Organization Configuration role assigned. For guidance on Purview permissions, check out one of my previous posts here.
Why is this feature relevant?
Most Microsoft 365 environments aren’t clean or simple, and over time they naturally grow into something quite complex, with policies layered across Exchange, SharePoint, OneDrive, Teams, and endpoints. When something breaks, like a rule not triggering, an alert not appearing, or endpoint DLP (eDLP) behaving inconsistently, it’s rarely obvious why, and trying to trace it manually can take far longer than it should.
DLP diagnostics cuts through that noise by pulling together relevant configuration and policy data into one place, which means you spend less time guessing and more time actually fixing the issue.
New updates, endpoint DLP always-on diagnostics
There’s also a notable update rolling out tied to Message Centre MC1246003 and Microsoft 365 roadmap item 499431, which focuses on Endpoint DLP always-on diagnostics (Phase 2).
Here’s what that means in practice:
Admins can collect diagnostic traces directly from Windows endpoints
There’s no need for user interaction or disruption
Logs can be uploaded straight to Microsoft support using a request ID
Existing DLP policies remain unchanged
This is rolling out globally from March 2026 and needs to be enabled by an admin, so it won’t just appear automatically in your tenant.
If you want to read more or prepare for it, Microsoft’s documentation is here:
The six built-in DLP diagnostics explained
At the time of writing, Purview provides six main diagnostic scenarios, each designed to help with a specific type of issue, and each one can be run directly from the Solutions or Diagnostics page.

1. A DLP rule isn’t enforced for a specific user
This diagnostic checks which policies are applied to a user and where those policies are active.
You’ll need to enter:
A data source such as Exchange, OneDrive, Teams, SharePoint, or endpoint

The user principal name

It returns all DLP policies and rules that apply to that user or location, which is often the quickest way to spot gaps or conflicts.

2. Endpoint DLP not working
If endpoint DLP doesn’t seem to be working as expected, this is usually the first place to start.
You provide:
Policy name
Device name

The diagnostic checks for policy sync issues and returns the DLP status of that endpoint, along with recommendations where possible.
3. Alerts not working for a DLP rule
This one focuses on alerting issues, which are a common pain point.
You’ll enter:
The DLP rule name
The approximate time the alert should have triggered

It validates the rule configuration and searches for alerts within the previous five days, and it’s worth knowing that multiple alerts generated within a one-minute window are grouped into a single alert.
4. Can’t find an alert for an activity or audit event
This diagnostic helps when you know something happened but there’s no alert to match it.
You can search using:
Activity record ID from Activity Explorer
Incident ID from audit logs

It identifies whether the alert exists or explains why it might be missing.
5. Analyze whether DLP matches a SharePoint or OneDrive file
This is particularly useful when dealing with file-based DLP issues.
You enter:
The file path
The data source, either SharePoint or OneDrive

The diagnostic retrieves the current DLP status of the document and shows whether it matched a policy and why.
6. Policy tips not displaying in Outlook on the web
This scenario uses a HAR file to analyse what’s happening in the browser when policy tips fail to appear.

It’s a bit more technical, but once you understand HAR files, it becomes quite straightforward.
HAR files explained, and how to capture one
A HAR file, or HTTP Archive file, is essentially a log of all the network activity happening in your browser while you reproduce an issue, and it captures things like requests, responses, load times, and errors.
It gives support engineers a detailed view of what’s happening behind the scenes, which makes it much easier to diagnose issues that aren’t obvious from the UI.
How to capture a HAR file using Edge or Chrome
Using Microsoft Edge or Google Chrome:
Open the page where the issue occurs
Press Ctrl + Shift + IÂ to open Developer Tools
Go to the Network tab
Clear any existing logs
Start recording network activity
Reproduce the issue
Stop recording
Export the HAR file
You can then attach that file to your support ticket or upload it when running the diagnostic.
Microsoft has a full guide here if you want the official steps:
GUI vs PowerShell troubleshooting
If you’ve worked with Purview for a while, you’ve probably relied on PowerShell commands like Test-IRMConfiguration, Get-Label, Get-LabelPolicy, and Test-DlpPolicies, and those tools are still useful in certain scenarios.
That said, the shift towards GUI-based diagnostics is pretty clear, and most of the common troubleshooting paths are now available directly in the portal, which makes the process far more accessible and a lot quicker for day-to-day issues. It is worth noting that the Diagnostics feature is also available in Microsoft Purview Information Protection, for scenarios such as 'Email encryption isn't working as expected', 'A user can't find the sensitivity label they need', or 'Analyze whether auto-labeling was applied to a SharePoint or OneDrive file'.
If you want to explore more self-service diagnostics across Purview, including sensitivity labels and encryption, Microsoft’s troubleshooting guide is here:
Conclusion
Troubleshooting any security or compliance tool can take time, especially once policies, workloads, and user scenarios start to overlap.
That’s what makes Microsoft Purview Data Loss Prevention Diagnostics so useful, because it helps reduce guesswork and gives you a quicker way to verify what’s actually happening in your environment.
If you work with DLP regularly, this is definitely one of those features worth getting familiar with, especially with the added improvements around endpoint diagnostics and the growing number of troubleshooting options available in the GUI.
