Your block list is lying to you

This blog post was written by my brilliant colleague, Tommy Nielsen. I’ve contributed by proofreading and restructuring it into its final blog format, and I fully agree with the perspectives shared here. The credit for the content belongs to Tommy, and it strongly reflects the principle we consistently advocate: allow where possible, block only where necessary.

Why a domain allow list is the most underrated control in microsoft purview

Most organisations approach external collaboration in microsoft 365 the same way: “which domains should we block?”

That mindset feels safe. But in practice, it leads to fragile controls, endless exceptions, and noisy security signals. You are always reacting, always one domain behind.

With microsoft 365 purview, the better question is the opposite:

Which domains do we explicitly allow our users to work with?

This shift, from blocking the bad to approving the trusted, is one of the most underrated improvements you can make to data loss prevention (DLP) and insider risk management (irm). And the best part? You define the list once, then reuse it everywhere.

Why block lists don’t scale

Block-based thinking breaks down quickly:

• New domains appear every day
• Saas vendors change infrastructure without warning
• Partners use multiple domains across their services
• Risk is contextual, not static

Trying to enumerate every bad destination is a losing game. Worse, block lists tell you nothing about intentional collaboration. They only tell you what hasn’t been caught yet.

Turn the model around: allow what you trust

An allow-list approach starts with a governance decision:

Which external organisations do we intentionally trust with our data?

This isn’t a technical question; it’s a business one. Think:

• Strategic partners
• Auditors and legal counsel
• Subsidiaries
• Key customers

Everything else is simply… not trusted by default. And once that decision exists, purview becomes far more powerful.

One list, three security wins

Here is what happens when you define your trusted domains and apply them across purview.

1. Insider risk management: signal, not noise

IRM policies often trigger on uploads to cloud services, file sharing to external domains, and email exfiltration patterns. Without exclusions, this includes expected, everyday collaboration, and that creates alert fatigue.

By using your allowed domain list as exclusions in IRM, you can:

• Suppress alerts for approved partner domains
• Maintain focus on unexpected, anomalous data flows
• Reduce alert fatigue without weakening detection

✔ fewer false positives
✔ higher signal quality
✔ legitimate alerts for abnormal activity

This shifts insider risk from activity monitoring to behaviour monitoring.

2. DLP: default deny, business-aware

DLP rules become dramatically more effective when combined with domain awareness. Instead of:

“block sharing confidential data externally (except dozens of manual exceptions)”

You can flip the model:

• Allow sensitive data only to approved domains
• Block everything else by default

Your policy becomes: “sensitive content is allowed only when the recipient domain is on our approved list.”

✔ simpler DLP architecture
✔ less ongoing maintenance
✔ stronger external data control

3. Consistent user experience across Microsoft 365

When domain trust isn’t defined, users get mixed signals: some external sharing works, some gets blocked, and some triggers alerts with no explanation.

With a domain allow list:

• Collaboration rules become predictable
• Exceptions are intentional, not accidental
• User training becomes simpler: “these domains are approved”

This consistency is often underestimated, but it’s essential for adoption and reduces helpdesk tickets.

One list, many controls

The real power comes from treating the domain allow list as a shared governance artifact. You define it once and reuse it across:

• Insider risk management exclusions
• DLP service domains (endpoint DLP)
• SharePoint external sharing policies
• Conditional access for external collaboration

Think of it as: identity governance, but for organisations rather than users.

How to build your allow list

Convinced? Here’s how to do it. The process is straightforward: audit first, then enforce.

Step 1: Switch service domains to “allow” mode

Go to Microsoft Purview → Settings → Data loss prevention → Endpoint DLP settings → Browser and domain restrictions to sensitive data → Service domains.

Change the dropdown from block to allow. This flips the model: instead of blocking specific domains, you’ll be defining which domains are permitted.

The service domains setting under endpoint DLP settings. Switch the dropdown to “allow” to flip from block-based to allow-based control.

Step 2: Create an audit-only endpoint DLP policy

Before you enforce anything, you need to know which domains your users are working with. Create a new endpoint DLP policy targeted at all users, scoped to the devices location.

Set the conditions to match the file types you care about (Word, Excel, PowerPoint, archives — or whatever makes sense for your organisation). Under actions, choose audit or restrict activities on devices and set the service domain activity to audit only.

An endpoint DLP policy set to audit only. This captures which cloud domains users upload to, without blocking anything yet.

Let this policy run for one to two weeks to gather a representative picture of your users’ behaviour.

Step 3: export results from activity explorer

Once you have enough data, go to Microsoft Purview → Activity explorer. Filter on:

• Activity: DLPrulematch
• Policy: the audit policy you created in step 2

Add the target domain column to your view, then click export to download the results.

Activity explorer filtered by your audit policy. Add the “target domain” column to see where users are uploading files, then export.

Step 4: analyse the domains in excel

Open the exported csv in excel. Insert a pivot table (or pivot chart) with:

• Rows: target domain
• Values: count of activity

Sort by count from largest to smallest. This gives you a clear picture of every domain your users are sending data to.

Import the exported data and insert a pivot table to aggregate domains by activity count.

Your pivot table will show all target domains sorted by frequency. Now you can see exactly where data is going.

Go through the list and sort the domains into three categories:

1. Obviously trusted — known partners, customers, and SAAS platforms you use
2. Obviously untrusted — personal file-sharing sites, unknown domains
3. Needs discussion — domains that need a business decision before you allow or block them

Take that third category to your business stakeholders. This is the governance conversation that makes the whole approach work.

Step 5: add approved domains and enforce

Once your domain list is finalised, add the approved domains back in Microsoft Purview → Settings → Data loss prevention → Endpoint DLP settings → Service domains (the same place from step 1).

Then create a new endpoint DLP policy (or update your existing one) and change the action from audit only to block for uploads to domains not on the allow list.

The enforcement policy: same structure as the audit policy, but with the action set to block. Users can still upload to approved domains.

Tip: the DLP rule conditions are up to you. You could scope this to specific sensitivity labels, sensitive information types, or all documents. Don’t forget to configure policy tips so users understand why an upload was blocked.

Step 6: Reuse the same domains in insider risk management

Now take the same domain list and add it as exclusions in IRM. Go to Microsoft Purview → Settings → Insider risk management → Global exclusions → Domains.

The IRM domain exclusions page. Add the same approved domains here so that expected collaboration doesn’t generate risk alerts.

This means activity involving your approved partner domains won’t generate unnecessary risk signals, while anything outside the list still gets flagged.

Note: as of writing, IRM global exclusions is still in preview. The UI and feature set may evolve, but the concept is stable and worth implementing now.

Start with the list, build from there

Most organisations pour effort into classifying data, sensitivity labels, DLP rules, retention policies. That’s important. But far fewer take the time to answer a simpler question:

Which external domains do we trust our users to work with?

A well-defined domain allow list is a foundational control that quietly enables stronger security, cleaner detections, and less operational noise across purview. It costs nothing to build, takes about two weeks to baseline, and pays off across multiple workloads.

Define the list. Apply it everywhere. And stop chasing bad domains.