Microsoft Purview Data Loss Prevention: A Step-by-Step Setup Guide for Endpoint and Email

Executive Snapshot

TL;DR

• DLP is four nested objects: locations → policy → rules → conditions and actions. Almost every "DLP doesn't work" ticket is actually a rule condition that never matched, not a broken product.
• Endpoint DLP is not a standalone agent. It rides the Defender for Endpoint onboarding pipeline. If a device is not onboarded, no endpoint policy will ever apply to it, and the policy page will not tell you why.
• Simulation mode is not optional discipline, it is the deployment method. Run every new policy in test mode, review Activity explorer, tune, then promote. Blocking on day one is how DLP programmes get switched off permanently.
• Confidence level and instance count are your two main tuning dials. Most false-positive storms are fixed by raising confidence from low to high, or by requiring more than one instance of a sensitive info type in a document.
• PowerShell is where DLP scales. The portal wizard is fine for one policy; New-DlpCompliancePolicy plus New-DlpComplianceRule is how you build ten of them consistently and keep them in source control.

Introduction

Data Loss Prevention has a reputation problem. Most IT pros have inherited a tenant where someone once switched on a "block credit card numbers" policy, the finance team immediately hit it forty times a day on legitimate invoices, and the policy has been sitting in disabled state ever since. Meanwhile the actual exfiltration risk — someone dragging a customer list to a USB stick on their last day — was never covered at all.

Microsoft Purview DLP done properly is not a switch you flip. It is a measurement exercise that gradually turns into enforcement. This guide walks the full sequence: understanding what the objects actually are, checking the licensing you need before you design anything, building an Exchange email policy, onboarding devices and building an endpoint policy, running both in simulation, reading the results, tuning the noise out, and finally managing the whole thing from PowerShell so it is reproducible.

How Purview DLP Actually Works

Four concepts, in the order the service evaluates them.

Sensitive information types (SITs) are the pattern matchers. Microsoft ships hundreds of built-in ones — credit card numbers, national ID numbers, IBAN codes, health record identifiers — each defined as a regex or checksum plus supporting evidence (nearby keywords, dates, formatting) and a confidence level. A bare 16-digit number that passes the Luhn checksum is a low-confidence credit card match; the same number sitting next to the words "expiry" and "CVV" is high confidence. You can also build custom SITs, exact data match (EDM) types that compare against a hashed copy of your own database, document fingerprints for standard forms, and trainable classifiers that recognise document categories like resumes or source code rather than specific strings.

Locations are where the policy looks: Exchange email, SharePoint sites, OneDrive accounts, Teams chat and channel messages, Devices (endpoint), and — depending on your licensing and tenant configuration — Defender for Cloud Apps, on-premises repositories, Fabric/Power BI workspaces, and Microsoft 365 Copilot interactions. Location availability shifts as the product evolves, so verify the current list in your own tenant rather than trusting a screenshot.

A policy is the container: it binds a name, a set of locations, an inclusion/exclusion scope (specific users, groups, sites), and a mode.

Rules live inside the policy and do the real work. Each rule pairs conditions ("content contains at least 10 instances of a high-confidence Credit Card Number and the recipient is outside the organisation") with actions (audit only, restrict access, block, encrypt, notify the user, generate an incident report, raise an alert). A policy can hold several rules with a priority order, which is how you build graduated responses: warn at one instance, block at ten.

flowchart LR
    A[User action] --> B[Location in scope]
    B --> C[Rule conditions]
    C --> D[SIT match]
    D --> E[Action applied]
    E --> F[Alert and audit log]

Licensing Prerequisites

This is where most DLP projects hit an unexpected wall, and it is also the area Microsoft revises most often — so treat the following as the shape of the licensing, then confirm the exact SKU entitlements against current licensing docs before you commit budget.

Broadly:

• DLP for Exchange, SharePoint and OneDrive is the long-standing baseline capability, included at the Office 365 E3 / Microsoft 365 E3 tier. If all you need is "stop bank details leaving by email", you very likely already own it.
• Endpoint DLP and Teams DLP are the premium capabilities, associated with Microsoft 365 E5, the E5 Compliance add-on, or the Information Protection and Governance add-on. Microsoft 365 Business Premium has also carried endpoint DLP entitlement for small-tenant customers — check this explicitly if you are on a Business SKU, because it materially changes what you can deploy.
• Advanced classification techniques — exact data match, trainable classifiers, optical character recognition on images — generally sit at the E5 tier even when the underlying DLP location does not.
• Licences are assigned per user, and for endpoint DLP the relevant user is the one signed in to the device. A device onboarded but used by an unlicensed account will not produce the enforcement you expect.

Two practical consequences. First, do a licence inventory before you design policies, or you will build an endpoint policy you cannot legally enable. Second, if you are mid-negotiation on an E5 uplift, the email-side policies are the ones you can build and prove value with today.

Step 1: Build an Exchange Email DLP Policy

Start with email. It is the highest-volume egress path, the licensing is the least likely to block you, and policy tips render well in Outlook.

1. Sign in to the Microsoft Purview portal and open the Data Loss Prevention solution, then Policies → Create policy.
2. Choose a template or start from scratch. Templates (Financial, Medical and health, Privacy, grouped by country/region) pre-populate a sensible SIT bundle — the "U.K. Financial Data" or "U.S. HIPAA" templates are reasonable starting points. Custom is the right choice once you know what you are doing.
3. Name it descriptively. DLP-Email-PCI-Simulation-2026Q3 beats Test policy 2. You will be reading this name in alerts for years.
4. Assign admin units if your tenant uses them, then choose locations. For this first policy, select Exchange email only and leave everything else off. Scope it to a pilot group rather than the whole tenant if you have one available.
5. On the policy settings page, choose Create or customise advanced DLP rules and add a rule.
6. Conditions: set Content contains → Sensitive info types → pick your types. Then, critically, set the instance count and confidence level for each. A good starting posture is high confidence, minimum 1, maximum any. Add a second condition of Recipient is outside my organisation — internal-only mail is rarely the risk and including it multiplies your noise.
7. Actions: for the first deployment, choose Restrict access or encrypt the content but leave the policy in test mode (next step). This defines what would happen without it happening yet.
8. User notifications: turn on notifications and enable policy tips, but decide deliberately whether to show them during simulation — more on that below.
9. Incident reports: set a severity level and send reports to a monitored mailbox or distribution group, not to an individual admin's inbox.
10. On the final page, choose Run the policy in simulation mode (labelled "Test it out first" in some views), then create the policy.

Step 2: Onboard Devices for Endpoint DLP

Endpoint DLP has one dependency that catches everyone: devices must be onboarded to the Defender for Endpoint service before any endpoint DLP policy applies to them. Purview and Defender share the same onboarding pipeline. Onboard once, both work.

If your fleet is already onboarded to Defender for Endpoint, you may only need to enable device monitoring in Purview. If it is not, plan the onboarding as its own project phase.

1. In the Purview portal, go to Settings → Device onboarding and turn on device monitoring. Allow time for the tenant to provision the capability — this is not instant, and the exact wait varies.
2. Choose a deployment method appropriate to your fleet: Intune (the right answer for cloud-managed Windows estates), Group Policy, Configuration Manager, a local script for a small pilot, or the VDI-specific package for non-persistent desktops.
3. Deploy the onboarding package. For Intune, this is a configuration profile carrying the onboarding blob; for a pilot, running the downloaded local script as administrator on five machines is faster.
4. Verify the platform prerequisites. Endpoint DLP supports current Windows 10/11 builds and recent macOS versions, with expanding Linux coverage — verify the currently supported build floor in Microsoft's documentation, because it moves. On Windows, the device should be Entra joined or hybrid joined, Microsoft Defender Antivirus should be present with real-time protection active, and antimalware client versions need to be reasonably current.
5. Confirm enrolment on the Devices list in Purview or the Defender portal. A device that does not appear here is not covered, regardless of what your policy says.
6. Configure Endpoint DLP settings (Settings → Data loss prevention → Endpoint DLP settings) before writing policy: file path exclusions for backup and dev directories, restricted app groups, unallowed browsers, sensitive service domain groups, and — if you need forensic detail — evidence collection to an Azure storage account.

Step 3: Build the Endpoint DLP Policy

With devices onboarded, the policy flow mirrors Step 1 but with a different action set.

Create a new policy, select Devices as the only location, and in the rule's action pane choose Audit or restrict activities on devices. You are now configuring per-activity restrictions rather than a single block:

• Copy to a removable USB device
• Copy to a network share
• Print
• Copy to clipboard
• Upload to a restricted cloud service domain or access by an unallowed browser
• Access by a restricted app
• Remote desktop transfer

Each activity can be set to Audit only, Block with override, or Block. Set every one of them to Audit only for the first pass. You are collecting a baseline of what your users actually do with sensitive files, and that baseline will surprise you.

Why You Always Start in Simulation Mode

Simulation mode evaluates the policy against real user activity and records what would have happened, without applying any action. Two variants matter:

• Test without policy tips — completely silent. Nothing reaches the user. This is where every policy should start, because it gives you a clean measurement of match volume with zero support impact.
• Test with policy tips — actions still do not apply, but users see the notifications. Use this as the second phase: it warms users up to the coming enforcement and generates the "why did I get this?" conversations while you can still say "nothing was blocked."

Run each phase for at least one full business cycle. A month-end close, a payroll run, or a quarterly reporting period will generate document patterns that a quiet week never shows you. Promoting a policy to enforcement without having seen a month-end is how you discover on the worst possible day that your finance team routinely emails spreadsheets full of bank details to a legitimate external auditor.

Purview surfaces a simulation overview per policy showing matched items and the rules that fired. Read it, then read Activity explorer for the detail.

Policy Tips and User Overrides

Policy tips are the in-product notification — a banner in Outlook, Office apps, or on the endpoint — telling the user what matched and what the consequence is. They are the single highest-leverage part of a DLP deployment, because a well-written tip converts a blocked action into a teachable moment instead of a helpdesk ticket.

Rewrite the default text. The stock message is generic; yours should name the data type, name the policy owner, and give a sanctioned alternative ("share the file via a Teams link instead of attaching it").

Overrides come in three flavours and you configure them per rule:

• Override with business justification — the user picks or types a reason and proceeds. The justification is recorded and shows in Activity explorer. This is the right default for the first enforcement wave.
• Override by reporting a false positive — the user flags the match as wrong and proceeds. This gives you a free tuning feed.
• No override — reserve this for genuinely non-negotiable data. Every no-override rule is a future escalation.

Tuning Out False Positives

When simulation produces noise — and it will — work through these in order:

1. Raise the confidence level. Moving a SIT from low to high confidence is the single biggest noise reduction available. It requires the supporting evidence (keywords, proximity, formatting) to be present, which is what separates a real credit card number from a purchase order reference.
2. Raise the instance count. One national ID number in a document is often incidental; fifty is a data extract. Setting a minimum of 10 on bulk-extract policies while keeping a separate low-count rule at audit-only gives you graduated coverage.
3. Add exclusion conditions. Exclude your own auditor and processor domains from "recipient is outside the organisation". Exclude a service account that legitimately moves files. Exclude the file paths where your line-of-business app writes temporary files.
4. Test the SIT directly. Purview lets you test a sensitive info type against a sample file and shows exactly which pattern matched. When a match makes no sense, this is the fastest route to understanding why.
5. Swap the classifier. If a regex SIT keeps misfiring on a document category, a trainable classifier or an exact data match type built from your own reference data will nearly always be more precise.
6. Split the policy. One policy trying to cover five data types across four locations is untunable. Narrow policies are easier to reason about and easier to switch off individually when one misbehaves.

Aim for a false-positive rate you would be willing to defend to the affected department before you enable any blocking action.

Alerts and Incident Review

DLP alerts appear on the Alerts page inside the Data Loss Prevention solution, and — depending on tenant configuration — flow into Microsoft Defender XDR as incidents so they can be correlated with other signals.

Set a review rhythm rather than treating alerts as interrupts. A workable pattern:

• Severity high, no override available — same-day triage.
• Severity medium with override used — weekly batch review, looking for justification text that reveals a broken business process.
• Severity low / audit only — monthly, as tuning input only.

For each alert, the detail pane gives you the user, the activity, the matched SIT with confidence, the policy and rule that fired, and — if you enabled it — the incident report and evidence. Resolve alerts with a status and a note; an alert queue nobody closes stops being a signal within a fortnight.

Monitoring with Activity Explorer

Activity explorer is the analytical view: every DLP-relevant activity, filterable by activity type, user, device, sensitive info type, policy, and whether an override or false-positive report was used. It is where you answer "is this policy ready to enforce?" rather than "what happened to this one file?"

Three queries worth running weekly during a rollout:

• Filter by policy, group by rule — shows which rule inside a multi-rule policy is generating the volume.
• Filter by activity type "file copied to removable media" with no policy filter — shows your endpoint exfiltration baseline independently of whether a policy caught it.
• Filter by override justification present — reads as a list of business processes that your policy is currently fighting.

Activity explorer data has a retention window and a reporting lag, so export anything you need for long-term trend reporting rather than assuming it will still be queryable next quarter.

Managing DLP from PowerShell

The portal is fine for one policy. For anything reproducible, use Security & Compliance PowerShell — it is the same object model, and the output can live in source control.

Connect first. The cmdlets ship in the ExchangeOnlineManagement module, and Connect-IPPSSession is the compliance-side entry point (distinct from Connect-ExchangeOnline):

# Security & Compliance PowerShell — modern auth, MFA-friendly
Install-Module ExchangeOnlineManagement -Scope CurrentUser -Force
Import-Module ExchangeOnlineManagement

Connect-IPPSSession -UserPrincipalName admin@contoso.com

# Confirm the session is live and see what already exists
Get-DlpCompliancePolicy | Select-Object Name, Mode, ExchangeLocation, Workload

Create an email policy in simulation mode, then attach a rule. Note that Mode on the policy is what controls simulation — TestWithoutNotifications is the silent first phase, TestWithNotifications shows policy tips without enforcing, and Enable turns on real enforcement:

# 1. The container: Exchange only, silent simulation
New-DlpCompliancePolicy `
    -Name "DLP-Email-PCI-Simulation" `
    -Comment "PCI data over email — phase 1, silent test" `
    -ExchangeLocation All `
    -Mode TestWithoutNotifications

# 2. The rule: high-confidence card data leaving the org
New-DlpComplianceRule `
    -Name "PCI-Email-External-HighConfidence" `
    -Policy "DLP-Email-PCI-Simulation" `
    -ContentContainsSensitiveInformation @{
        Name            = "Credit Card Number"
        minCount        = "1"
        confidencelevel = "High"
    } `
    -AccessScope NotInOrganization `
    -BlockAccess $true `
    -NotifyUser Owner, LastModifier `
    -NotifyAllowOverride WithJustification, FalsePositive `
    -GenerateIncidentReport SiteAdmin `
    -ReportSeverityLevel Medium

The endpoint equivalent uses a device location and per-activity restrictions rather than a single block flag:

New-DlpCompliancePolicy `
    -Name "DLP-Endpoint-PII-Audit" `
    -EndpointDlpLocation All `
    -Mode TestWithoutNotifications

New-DlpComplianceRule `
    -Name "PII-Endpoint-Egress-Audit" `
    -Policy "DLP-Endpoint-PII-Audit" `
    -ContentContainsSensitiveInformation @{
        Name            = "U.S. Social Security Number (SSN)"
        minCount        = "10"
        confidencelevel = "High"
    } `
    -EndpointDlpRestrictions @(
        @{ Setting = "RemovableMedia";   Value = "Audit" },
        @{ Setting = "NetworkShare";     Value = "Audit" },
        @{ Setting = "Print";            Value = "Audit" },
        @{ Setting = "CloudEgress";      Value = "Audit" }
    )

Promotion and routine maintenance are one-liners, which is exactly why this belongs in a script rather than a click path:

# Phase 2: show policy tips, still no enforcement
Set-DlpCompliancePolicy -Identity "DLP-Email-PCI-Simulation" -Mode TestWithNotifications

# Phase 3: enforce
Set-DlpCompliancePolicy -Identity "DLP-Email-PCI-Simulation" -Mode Enable

# Tune: raise the instance threshold after reviewing simulation output
Set-DlpComplianceRule -Identity "PCI-Email-External-HighConfidence" `
    -ContentContainsSensitiveInformation @{
        Name            = "Credit Card Number"
        minCount        = "10"
        confidencelevel = "High"
    }

# Snapshot every policy and rule to JSON for source control / change review
Get-DlpCompliancePolicy | ConvertTo-Json -Depth 6 |
    Out-File ".\dlp-policies-$(Get-Date -Format yyyyMMdd).json"

Disconnect-ExchangeOnline -Confirm:$false

Parameter names and accepted values on these cmdlets do change between service releases — run Get-Help New-DlpComplianceRule -Full against your own tenant and verify in current docs before scripting a bulk deployment.

Common Mistakes to Avoid

• Enabling enforcement straight from the wizard. The wizard offers it; take simulation instead, every time.
• Assuming endpoint policies apply to un-onboarded devices. They silently do not, and the policy page will happily show "on" while covering nothing.
• Leaving SITs at low confidence. This is the root cause of the majority of DLP false-positive complaints.
• Sending incident reports to a personal mailbox. The person leaves, the reports vanish, and nobody notices for months.
• One giant policy. Untunable, unattributable, and impossible to disable partially when it misfires.
• Skipping the licence check. Building an endpoint policy you are not entitled to enable wastes a sprint.
• Never closing alerts. An alert queue with a thousand open items is indistinguishable from having no alerting.
• Copying policy text from a template and shipping it. Users read the tip; make it say something useful and specific to your organisation.

Key Takeaways

• DLP resolves as locations → policy → rules → conditions → actions. Debug in that order and most mysteries evaporate.
• Endpoint DLP depends on Defender for Endpoint onboarding. Confirm devices appear in the Devices list before trusting any endpoint policy.
• Simulation mode, silent first and then with policy tips, is the deployment method — not a preliminary step you can skip under time pressure.
• Confidence level and instance count fix most false positives; exclusions and better classifiers fix the rest.
• Overrides with business justification are a feature, not a weakness — they convert enforcement into a feedback channel.
• Activity explorer answers "is this ready to enforce?"; the Alerts page answers "what happened to this file?". Use both.
• Security & Compliance PowerShell (Connect-IPPSSession) makes policies reproducible and reviewable; the portal does not.
• Licensing detail around E3 versus E5 and E5 Compliance shifts regularly — verify entitlements in current licensing documentation before designing around them.

Next Steps

1. Inventory your licences and establish which DLP locations you are actually entitled to enable today.
2. Build one email policy in TestWithoutNotifications, scoped to a pilot group, targeting the single data type your organisation genuinely cares most about.
3. Start device onboarding in parallel — it has the longest lead time of anything in this guide, and endpoint policy work is blocked until it completes.
4. Book a review 30 days out, with Activity explorer open, and only then decide whether to move to policy tips.
5. Script what you built with New-DlpCompliancePolicy and New-DlpComplianceRule, commit it, and make the portal the exception rather than the norm.

Related Articles

• Microsoft Purview in 2026: DSPM, DLP for Copilot, and Auto-Labeling for AI Content
• Microsoft 365 Licensing in 2026: Business Premium vs E3 vs E5
• Exchange Online Protection vs Defender for Office 365: Which Email Security Tier Do You Need?
• Microsoft Intune Device Compliance Policies: A 2026 Configuration Guide

Sources:

• Learn about data loss prevention | Microsoft Learn
• Data Loss Prevention policy reference | Microsoft Learn
• Design and create a data loss prevention policy | Microsoft Learn
• Learn about Endpoint data loss prevention | Microsoft Learn
• Get started with Endpoint data loss prevention | Microsoft Learn
• Onboarding tools and methods for Windows devices | Microsoft Learn
• Learn about sensitive information types | Microsoft Learn
• Get started with the data loss prevention alerts dashboard | Microsoft Learn
• Get started with activity explorer | Microsoft Learn
• Connect-IPPSSession | Microsoft Learn
• New-DlpCompliancePolicy | Microsoft Learn
• New-DlpComplianceRule | Microsoft Learn
• Microsoft 365 security and compliance licensing guidance | Microsoft Learn