DLP Controls Not Enforced for Outlook Attachments Opened in Protected View

Hi!

I’ve seen similar before because opening attachments directly from Outlook extracts the file into a temporary caching directory (such as %LocalAppData%\Microsoft\Windows\INetCache\Content.Outlook) and launches Office under a Protected View process context. When "Enable Editing" is selected, the transition of the file handle from Protected View back to active editing can sometimes bypass Endpoint DLP hooks if specific conditions exist in your tenant setup.

Here are a few steps to investigate and resolve this:

Option 1. Verify Endpoint DLP Unmonitored Locations & Apps:

 Go to Microsoft Purview > Settings > Endpoint DLP settings.

 Check Unmonitored locations and ensure temporary system paths or INetCache subdirectories are not excluded.

 Check Unmonitored applications to verify that OUTLOOK.EXE and WINWORD.EXE/EXCEL.EXE are not listed.

Option 2. Enforce File-Level Protection via Sensitivity Labels (IRM):

 If your policy relies solely on Endpoint DLP rules to block copy/print, consider configuring the Sensitivity Label itself with Rights Management Service (RMS) access permissions (e.g., restricting Copy/Print directly in the label encryption settings).

 When restrictions are embedded in the label's Rights Management protection, they travel with the file regardless of temporarey folder locations or Protected View transitions.

Option 3. Check Client Channel & Build Updates:

 Ensure Microsoft 365 Apps and the Defender for Endpoint (Sense) service are updated to the latest builds on the test machines, as Microsoft regularly releases updates to fix DLP filter driver process transitions from Protected View.

Hope this helps narrow it down!