The files Endpoint DLP never looks at

Endpoint DLP does not scan every file. It scans a fixed Monitored files list - Office documents, PDFs, CSVs, archives, text and a handful of others. Anything outside that list is never opened: .mp3, .wav, .dat, .mp4, CAD drawings, database dumps, password-manager exports, your own proprietary formats.

Because those files are never scanned, your sensitive info type and sensitivity label rules can never match them. A user can rename or export sensitive data into an unsupported type and copy it to a USB stick, and a content-based DLP policy will not say a word. Most teams never notice, because the policy works perfectly on the file types they tested it with.

It is a deliberate trade-off, not a bug. Parsing and scanning the contents of every possible file format would hammer CPU and memory on every device. Microsoft draws the line at known, parseable types. The cost of that decision is a real blind spot for everything else - which is fine until someone uses it to walk data out.

There is a preview feature for exactly this gap: Apply restrictions to only unsupported file extensions. It does not scan content - it applies controls based purely on the fact that the file could not be scanned. You will not see any sensitive info type in the resulting alerts, because nothing was inspected.

You configure it through the Document could not be scanned condition together with the Audit or restrict activities on devices action, then tick Apply restrictions to only unsupported file extensions. Two limits to plan around:

• Only four activities are supported: upload to a restricted cloud service domain, copy to a USB device, copy to a network share, and print. Clipboard, Bluetooth, RDP and restricted-app coverage are not included.
• It cannot be scoped by device or device group, and the Document could not be scanned condition cannot be combined with any other condition.

Everything unsupported. Apply a blanket control to every file type that is not on the Monitored files list, then exclude the ones you trust. Add known-safe extensions to Unsupported file extension exclusions under Endpoint DLP settings - for example an internal format you know carries no risk.

A defined set. Control only specific unsupported types by building a File extension group under Endpoint DLP settings (say a Non-classified file extensions group for .mp3, .mp4 and .dat) and attaching it to the policy. Everything outside the group is left alone.

There is a similar-looking condition called File extension is, and the difference matters. File extension is *does* scan the file's content, so you get sensitive info type values in your alerts, but it costs more CPU and memory. Apply restrictions to only unsupported file extensions does *not* scan, so it is lighter but gives you no content visibility.

Use File extension is when you want to inspect a supported type. Use unsupported-extension restrictions when you just want a checkpoint on the file types DLP cannot read. Either way, start in audit, confirm you are catching the right files, then move to block.