Email blocked by Purview DLP: notifications, NDRs, overrides and incident reports

"My email bounced and I don't know why" is often a data loss prevention (DLP) rule doing its job, or doing too much of it. In this post I'll map the actions a Microsoft Purview DLP rule can take on email to what the sender actually sees, show how to prove which policy and rule acted, and cover overrides with business justification, quarantine release and fixing false positives.

Symptoms#

• The sender gets a notification whose subject starts with Message Blocked, often with the original message attached.
• Internal recipients received the message but external ones didn't.
• Message trace shows the message as Failed or Quarantined, with a DLP rule event in its details.
• Before sending, Outlook showed a policy tip (if it didn't, see policy tips not showing in Outlook).

The default notification text for a blocked email is:

Your email message conflicts with a policy in your organization. The message wasn't delivered to all recipients.

Depending on the rule's notification settings, the sender may get an NDR instead. Microsoft doesn't document a DLP-specific NDR code; in a bounce sample discussed on Microsoft Q&A, the status was 550 5.7.171 with an X-MSG-IS-MS-DLP: true header. Treat those as hints and confirm with the evidence below.

Why it happens#

Each Exchange action produces a different experience:

Unexpected blocks usually trace back to a sensitive information type matching too loosely, a rule scoped wider than intended, a stricter rule winning on priority, or a simulation that was set to switch itself on (see how DLP rule priority works).

How to fix it#

1. Prove DLP acted#

Trace the message in the Exchange admin center (Mail flow › Message trace) or with the V2 cmdlets, and look for the DLP rule event:

Connect-ExchangeOnline
$t = Get-MessageTraceV2 -SenderAddress anna@contoso.com -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date)
$t | Where-Object Subject -like "*Q3 payroll*" | Get-MessageTraceDetailV2 | Format-List Date,Event,Detail

More on reading traces in using message trace in Exchange Online.

2. Find the policy, rule and match#

Open the DLP alert in the Microsoft Purview portal or Defender XDR, or filter activity explorer for DLP rule match events from the sender. Both show the policy, the rule and the matched sensitive information types (see investigating DLP alerts).

3. Decide: real leak or false positive#

If the match is real, explain the policy and offer an approved route, such as sending encrypted. If it's a false positive, tune the rule: raise the confidence level or instance count, add a narrow exception such as ExceptIfRecipientDomainIs for one partner, or downgrade the rule to block with override:

Connect-IPPSSession
Set-DlpComplianceRule -Identity "Block external customer data" -BlockAccess $true -BlockAccessScope PerUser -NotifyAllowOverride WithJustification

The rule also needs policy tips, otherwise users never see the override option.

4. Let users override properly#

In Outlook and Outlook on the web, the sender chooses Show Details › Override, enters a business justification or reports a false positive, and sends again. An override applies per rule and overrides all of that rule's actions; the justification is logged for DLP reports. Overridden messages can also be targeted with the Has sender overridden the policy tip condition, for example to add the sender's manager as Bcc; pilot such a rule before relying on it.

5. Release or resend#

Quarantined messages can be released on the Quarantine page of the Microsoft Defender portal by members of the Quarantine Administrator, Security Administrator or Organization Management role groups. A blocked message can't be released: after you fix the rule, or with an override, the sender sends it again (the notification often carries the original as an attachment).

Verify the fix#

1. Send the same dummy test data again from a pilot account. The outcome should match the rule you intended: delivered, tip with override, or blocked.
2. Message trace shows Delivered for the resent or released message.
3. Overrides and false-positive reports appear in the DLP reports with the justification text.
4. Run the policy check: Get-DlpComplianceRule -Policy "DLP - Customer data" | Format-List Name,BlockAccess,BlockAccessScope,NotifyAllowOverride.

Prevent it next time#

• Write useful notifications. Custom email notifications support tokens such as %%PolicyName%%, %%PolicyRule%%, %%MatchedConditions%% and %%BlockedMessageInfo%%. Notification emails are sent unprotected, and external senders only get a templated version.
• Route evidence. Set GenerateIncidentReport with IncidentReportContent to send incident reports to a compliance mailbox, and use ReportSeverityLevel and GenerateAlert so high-severity rules raise alerts.
• Simulate first and tier your rules; see from simulation mode to enforcement and tuning DLP false positives.
• For other DLP messages, see the Purview DLP messages quick reference.

References#

• Send email notifications and show policy tips for DLP policies (Microsoft Learn)
• Data loss prevention Exchange conditions and actions reference (Microsoft Learn)
• New-DlpComplianceRule (Microsoft Learn)