Introduction
When I first heard about mark files as sensitive by default, I was immediately intrigued by its promise: any new file in SharePoint or OneDrive would be blocked from external sharing until it’s fully scanned against Data Loss Prevention (DLP) policies. As someone who builds and tests Microsoft 365 governance and protection solutions every day, I knew this feature could close a big gap which is preventing guests from grabbing sensitive data before DLP rules even have a chance to run.
Ever faced the issue where you uploaded a sensitive information in a site covered by a Data Loss Prevention Policy and expected the DLP action to be immediately applied but then it took a couple of minutes before DLP could scan the content and enforce the action? Leaving the file in an unprotected state and open for exfiltration if the actor is quick to share the file outside the organisation. “Mark files as sensitive by default“ is the answer to this issue.
In this post, I’ll explain:
How “mark files as sensitive by default” works under the hood
Why it’s useful for data protection
What I discovered in my testing—and why it didn’t behave exactly as the docs describe (read on for the full story)
1. How It Works: The Scanning and Sharing Pipeline
At a high level, here’s the sequence when a user uploads a file:
Immediate block: The tenant setting (
Set-SPOTenant –MarkNewFilesSensitiveByDefault BlockExternalSharing) kicks in, tagging the file as “unscanned sensitive.” Guests attempting to open it see a scanning-in-progress error.Automatic crawl: Microsoft’s backend indexing engine ingests the file for search and compliance.
DLP scan: After the crawl completes, the file is evaluated by each enabled Office 365 DLP policy with a “Content contains…” condition—but only if that policy’s location scope includes the file’s SharePoint site or OneDrive account.
Release or enforcement:
No hits: Clean files have their temporary block lifted—guests can access them (typically within 1–2 minutes).
Hits detected: The enforcement actions (block, restrict, notify) of the matching policy apply.
- SharePoint / OneDrive Locations not covered by any DLP Policy: Read till the end to understand what the documentation says vs what my testing revealed.
Key point: mark files as sensitive by default ensures that no file is ever shared externally until it completes at least one content scan.
2. Why It Matters: Benefits of Marking Files Sensitive by Default
Protects unknown data: Users can’t accidentally leak new files before DLP has analyzed the content.
Consistent security: Shifts from “allow then block” to “block then allow,” giving IT teams more predictable controls.
Guest transparency: External users see a clear “scanning in progress” message, reducing support tickets.
In my experience, this setting is a no-brainer for organizations handling regulated or high-value information. It layers seamlessly on top of your existing DLP policies to catch leaks at the earliest point of file creation.
3. My Testing: Uncovering an Unexpected Behavior
Setup
Enabled mark files as sensitive by default on my tenant with external sharing blocked.
Created a brand-new SharePoint site with no cloud-scoped DLP policy targeting it.
Uploaded a simple Word document.
As a guest, attempted to open the file immediately and saw the expected “Scanning in progress” block.
Waited ~1–2 minutes—and then… the file opened successfully.
What I Expected
Based on Microsoft’s documentation, a file in a location not covered by any DLP policy should remain blocked indefinitely. That’s what “content that isn’t explicitly checked in a DLP policy is blocked from being externally accessed” means, right?
What Actually Happened
Even without any cloud DLP policy covering that site, my test file was released after the search engine crawl completed and no content hits were found. This suggests that the feature currently releases clean files after the indexing step, regardless of explicit policy coverage.
4. Implications and Next Steps
Potential product gap: The behavior doesn’t fully align with the documented “block forever if not covered” model. If you rely on policy scope for eternal blocks, you may see unexpected releases.
Workaround: If your goal is to let sites not covered by any DLP policy be shareable, then you must create a “dummy” DLP rule with “Content Contains…” condition, scoped to All SharePoint sites + All OneDrive accounts, move it to the highest priority (with Stop processing more rules turned off), so it runs first and lifts the temporary block on those locations—assuming the feature worked as documented, which my testing showed it does not.
Conclusion
The mark files as sensitive by default setting is a powerful tool for shifting from reactive to proactive data protection in Microsoft 365. It blocks new files at the door and only lets them go once they’ve passed DLP scrutiny. However, my testing shows it currently relies on the indexing crawl rather than explicit policy scope, which can lead to unintended releases in truly “uncovered” sites.
If you’re implementing this feature, be sure to:
Understand the index-driven release behavior
Cover every critical location with at least one cloud-scoped DLP policy
Monitor guest-access workflows and open a support ticket if you see discrepancies
I hope this deep dive helps you confidently deploy mark files as sensitive by default in your environment.
Feel free to leave a comment if you’ve seen similar behavior or have questions about the setup.
