Purview DLP: The Warning That Wasn’t

I ran into a Purview DLP behavior recently that confused everyone involved for a bit.

The policy was correct. The configuration was correct. The user experience was not.

The reason ended up being licensing and where DLP evaluation happens in the mail flow.

Notes from the field: If your DLP policy requires justification but users never see a warning, check where the policy is being evaluated. You may be dealing with post-submission enforcement.

The Goal

The client wanted something pretty common.

If users send sensitive data outside the organization:

• warn the user

• make them think about it

• require justification if they proceed

  
  

In Purview terms that usually looks like this:

Condition
Content contains label: Confidential
Recipient: External

Action
Require override with justification.

The expectation is that Outlook shows a policy tip before the email is sent. The user reviews it, decides whether to continue, and provides a justification.

Pretty standard user-awareness pattern.

What Actually Happened

Users sent the email.

Then they received an NDR saying the message was blocked by policy.

No warning beforehand. No opportunity to justify. Just a rejected email.

The policy still prevented the message from leaving the tenant, so technically the control worked.

But the behavior was completely different than what we designed.

Why the Purview DLP Warning Never Appeared

The environment was Microsoft 365 G3 (and it wouldn't matter if it was A3 or E3 instead).

Certain DLP experiences, especially pre-send policy tips in Outlook desktop, depend on licensing, DLP conditions, and client support.

Without that support, the flow looks different.

Instead of evaluating the policy before the message is sent, Exchange evaluates it after submission.

So, the flow becomes:

User sends email > Exchange evaluates policy > Message blocked > User receives NDR

The user never sees a warning.

Why This Confused Everyone

From a security standpoint, both approaches stop the data.

From a human standpoint, they are very different.

With pre-send evaluation:

Users pause. They think about what they’re sending. They justify the action.

With post-send enforcement:

The system just rejects the email. No signal. No decision point. Just frustration.

How We Diagnosed It

The first assumption was that something in the policy was wrong. We verified the rule conditions, confirmed the sensitivity label was applied correctly, and checked the DLP rule actions. Everything looked correct.

The next step was testing different clients. Outlook on the web behaved differently than Outlook desktop, which was the first clue.

From there we checked licensing and how DLP evaluation occurs in the mail flow. Once we confirmed the tenant was licensed with G3 and relying on post-submission evaluation, the behavior made sense.

Nothing was misconfigured; the platform was simply enforcing the policy after the message was sent instead of before.

Quick Test

If you want to see how this behaves in your environment, it’s easy to test.

1. Create a simple DLP rule that triggers on a sensitivity label.

2. Configure the rule to require override with justification.

3. Send a labeled email externally using Outlook desktop.

4. Repeat the test using Outlook on the web.

Watch what happens before the message is sent.

In some environments you’ll see a policy tip prompting the user before sending.

In others the message will send normally and then return an NDR after submission.

If the latter happens, the policy is likely being enforced post-submission in Exchange, not pre-send in the client.

Purview Licensing Reality Check

One of the recurring challenges with Purview is that policy configuration and user experience don’t always line up across licensing tiers.

The controls might exist in multiple licenses, but the way they behave can change depending on client support and evaluation timing.

That means two tenants can deploy the same DLP rule and see different behavior in Outlook.

When designing Purview controls, you’re not just designing policy logic, you’re designing around how the platform actually evaluates and enforces those policies in the environment.

Testing Purview DLP Pre-Send vs Post-Submission Enforcement

If you're designing DLP policies that depend on user awareness or justification, test the actual user experience in the client your users rely on most.

In environments licensed with G3 or E3, you may see policies enforced after message submission rather than before sending. When that happens, users won’t receive a policy tip, they’ll receive a rejected message instead.

That changes how the control behaves operationally.

If the goal is user education and decision-making, make sure the platform can support pre-send interaction. Otherwise the policy effectively becomes a hard block, even if it was designed as a warning.

Final Thought

Purview policies often behave exactly as configured.

The surprise is usually where the platform chooses to enforce them.

If the user experience looks wrong, don’t assume the policy is broken.

Check when the policy is being evaluated.

Sometimes the difference between a warning and a rejection is just where the control runs in the pipeline.