Microsoft is gearing up to release a long-awaited refinement to its Data Loss Prevention (DLP) engine in Exchange Online: the ability to craft distinct policies for different types of content-scan failures. According to a July 13 update to the Microsoft 365 Roadmap, the feature—called Granular Protections for Exchange Online—will enter public preview this month and is slated for general availability in August 2026.
Until now, if a DLP policy couldn’t scan an email attachment because of a timeout, a throttling event, or an unreadable file format, administrators had only one lever to pull: a blanket rule that treated every failure identically. That blunt instrument often forced security teams to choose between blocking messages that might be perfectly safe or letting potentially sensitive data slip through uninspected. The new controls promise to change that.
What Administrators Will Actually Get
The upcoming feature breaks out failure modes into discrete categories that can each be tied to a separate policy action. Microsoft specifically cites timeouts, throttling, and other scan errors as classification targets. In practice, that means a DLP rule could be configured to:
- Audit only when a classification service times out, logging the event for review without affecting mail flow.
- Block or redirect messages when an attachment is entirely unscannable because of corruption, password protection, or an unsupported file format.
- Escalate for manual approval when throttling indicates the tenant may be hitting service limits, offering a middle path that doesn’t grind business communication to a halt.
The distinction is more than cosmetic. A financial services firm that routinely processes encrypted PDFs from clients, for example, might accept a handful of scan timeouts after verifying they’re low-risk. That same organization would likely want to quarantine an unreadable .zip file from an unknown sender. With the existing catch-all model, both scenarios fall under the same rule, and adjusting the response means adjusting it for everything.
Nothing about the feature changes where DLP policy is evaluated. It remains an Exchange Online and Purview administrative function, not a client-side Outlook add-in. End users won’t see new dialogs or policy tips directly because of this update; the intelligence lives in the cloud service that inspects messages in transit.
Why This Matters for Your Organization
Exchange DLP is a frontline defense against accidental or intentional data leaks. It scans email bodies and attachments for patterns like credit card numbers, national ID numbers, or custom sensitive information types, then enforces actions such as encryption, blocking, or requiring manager approval. But the scan itself can fail for reasons entirely outside the content’s sensitivity.
Currently, administrators work around the all-or-nothing limitation by either:
- Taking an aggressive stance: Setting policies to block any message that couldn’t be scanned. This can silently drop legitimate business communications—imagine an urgent contract stuck in quarantine because the PDF’s scan timed out during a peak traffic hour.
- Taking a permissive stance: Allowing unscannable messages through and accepting the risk that some might contain unprotected sensitive data. For regulated industries, this creates a compliance blind spot.
The granular controls let security teams choose a third option: a nuanced, failure-aware posture that matches the response to the cause. That’s likely to reduce false positives without widening the inspection gap.
For global enterprises with high message volumes, the benefit is especially pronounced. Throttling events can spike during periods of heavy mail flow, and forcing every such event through a “block” action would be disruptive. An audit-first approach keeps the mail flowing while giving SOC analysts the telemetry they need to investigate patterns.
Smaller organizations, too, stand to gain. Many have relied on third-party email security services precisely because Exchange DLP’s failure handling was too coarse. A more precise built-in tool could simplify the security stack.
The Road to Granularity: DLP’s All-or-Nothing Past
Exchange DLP has always had some awareness of scan failures. Microsoft’s current Purview documentation already exposes conditions for “document could not be scanned” or “scanning did not complete,” and Activity Explorer can surface matched-condition details, including whether an attachment scanning condition triggered a policy. But those conditions are binary: either scanning worked, or it didn’t. There’s no built-in way to ask why it didn’t work within the policy logic itself.
That limitation dates back to the early days of Exchange Online Protection and the gradual integration of Purview’s classification engine. As the service expanded to support more file types, larger attachment sizes, and more complex sensitive information types, the number of possible failure points grew. Timeouts became more common with 50 MB attachments. Throttling surfaced as tenants pushed classification limits. Encrypted or password-protected files—once rare—are now everyday business objects.
The roadmap entry for Granular Protections (ID 561916) is therefore less a brand-new capability than the maturation of an existing feature set. It gives administrators the missing knob they’ve needed to fine-tune DLP behavior since the failure categories first appeared in monitoring tools.
It’s worth noting that the public preview applies to Microsoft’s standard multi-tenant cloud. GCC, GCC High, and DoD tenants should expect the usual lag behind commercial release, though Microsoft hasn’t yet published separate timelines for those clouds.
Getting Ready: Steps for Admins Before the Preview Arrives
Even though the toggle isn’t live yet, there’s groundwork teams can lay now so they’re not caught flat-footed when the preview hits their tenant.
- Audit your current DLP rules that reference unscannable or incomplete scan conditions. Identify which ones would benefit from being split by failure type. For example, a rule that currently blocks all unscannable messages might be a candidate for a two-tier approach: audit timeouts, but block truly unreadable attachments.
- Review Activity Explorer logs to understand your failure profile. Over the last 30–90 days, how many DLP incidents were triggered by scan failures? What percentage were timeouts vs. throttling vs. actual unscannable files? Knowing the baseline helps you decide which categories deserve the most restrictive actions.
- Test in audit mode first. When the preview appears, resist the temptation to immediately attach “block” or “reject” actions to the new failure-specific conditions. Start with an audit-only policy and observe which messages would have been affected. Run that simulation for at least one full business cycle.
- Coordinate with compliance and messaging teams. Document the intended treatment for each failure class. Legal might insist that messages with unscannable attachments always go to quarantine, while the email admin team argues that timeouts should be allowed through during business hours. Settle these debates before you build the policies.
- Check service health when throttling events spike. Sometimes the problem isn’t your policies at all—it’s a Microsoft service issue. The new granular controls will generate more specific alerts, so having a playbook for correlating them with Service Health Dashboard incidents will prevent unnecessary fire drills.
Remember, the feature remains in preview until August. Expect some rough edges, potential latency in rule propagation, and possible changes to the final condition names or actions between now and general availability. Microsoft’s previews are production-ready in many ways, but they’re still test beds.
What to Watch Next
The preview release this month will be the first real-world test of an idea that could reshape how Exchange DLP is configured. Look for early adopter feedback in community forums and on the Microsoft Tech Community, especially around how the failure categories map to actual tenant incidents. If the preview is well-received, it wouldn’t be surprising to see similar granularity come to DLP in other workloads—SharePoint Online, OneDrive, and Teams all have their own DLP scanning pipelines with the same fundamental limitations.
Microsoft hasn’t indicated whether the feature will eventually appear in the classic Exchange admin center or only in the modern Purview portal. Given the company’s push toward a unified Purview experience, admins should start familiarizing themselves with the Purview portal’s DLP blade if they haven’t already.
For now, the message is clear: Exchange DLP is about to get a lot smarter about failure, and that’s a win for security teams that have long walked the tightrope between too much enforcement and too little.