Microsoft has begun rolling out a new Data Loss Prevention action that lets organizations block individual external users or entire domains from accessing sensitive files in SharePoint Online and OneDrive for Business. The general availability deployment started in mid-July 2026 and should reach all tenants by the end of the month, giving administrators a scalpel rather than a sledgehammer for controlling guest access to corporate data.

A More Precise Blocking Action Arrives

The new capability, called Block access for specific external domains or users, appears inside Microsoft Purview DLP policies. Until now, SharePoint and OneDrive DLP policies could broadly block all external users from seeing content that matches sensitive information types or sensitivity labels. The updated action lets admins blacklist particular partner domains or specific guest email addresses while keeping other external collaboration paths wide open.

Configuration happens in a DLP policy under Restrict access or encrypt the content in Microsoft 365 locations. After scoping the rule to SharePoint Online or OneDrive for Business, administrators specify the domains (e.g., competitor.com) or SMTP addresses (e.g., [email protected]) that should be denied access. The policy can react to any standard DLP signal—credit card numbers, project code names, or a “Highly Confidential” label, for example—and then apply the block to only those designated external entities.

A blocked guest who tries to open or download the file sees an access-denied message. Critically, the restriction applies retroactively to files that were already shared, not just to new shares created after the policy takes effect.

The feature is tied to Microsoft 365 Roadmap ID 557191 and was previously available in public preview. Microsoft announced the general availability timeline in an updated Message Center notice on July 14, 2026.

What This Means for IT Administrators

This is a direct response to the messy reality of modern business collaboration. A company might work with fifty trusted suppliers but have one known-bad actor attempting to siphon data. Previously, a DLP rule that blocked all external access would break every legitimate partner workflow. Now, the security team can isolate a single risky domain without phoning fifty project managers.

Key Behaviors and Constraints to Understand

Before turning this on in production, admins should internalize a few critical rules drawn from Microsoft’s documentation:

  • Block trumps allow: If the same domain or user appears on both an allow list and the block list within a single rule, access is denied. There is no “except for” escape hatch at the user level—plan list membership carefully.
  • Internal users are out of scope: This action only targets guests. If you need to restrict an employee from a file, use a broader block action inside a separate DLP rule.
  • No user notifications or self-service overrides: Unlike some other DLP actions, end users cannot explain a business justification to bypass the block. Alerts and incident reports are still generated, but the decision is final.
  • Image files may still slip through: The preview documentation noted that image files were not protected by this sub-option. While Microsoft may have addressed this for GA, treat images as a potential gap until confirmed otherwise.
  • Multiple audit records: Certain blocked attempts can generate more than one audit log entry, so plan for a few extra events in your SIEM.

For End Users: A Clearer ‘Why’ Behind the Denied Access

Front-line employees and external collaborators won’t see policy tips or override buttons. If a guest gets blocked, they receive a straightforward access-denied message. While that’s less flexible than some might like, it also eliminates ambiguous “you might be violating policy” warnings that often confuse users. The downside is that helpdesks should brace for calls from partners suddenly locked out of a spreadsheet they accessed yesterday, especially if policies are rolled out aggressively.

The Evolution of External Sharing Controls

Granular external blocking in DLP is the latest chapter in Microsoft’s long effort to balance open collaboration with data security. SharePoint Online and OneDrive for Business have had tenant-level external sharing settings for years, allowing admins to restrict sharing by domain at the organizational level. However, those controls are blunt: a domain blocked at the tenant level cannot receive any sharing invitations anywhere in the tenant, regardless of content sensitivity. This works for known malicious domains but is impractical for partners who need access to non-sensitive resources.

Purview DLP, which started in Exchange Online and then expanded to SharePoint, OneDrive, and Teams, introduced content-aware protection. Early DLP rules could block all external sharing when sensitive content was detected, but they lacked the ability to distinguish between a trusted auditor and an unknown third party.

The public preview of Block access for specific external domains or users, which appeared in early 2026, gave admins the missing piece: content-aware, identity-aware blocking. The July 2026 GA release makes that preview capability production-ready and signals Microsoft’s commitment to letting organizations fine-tune their data protection without walling off the garden entirely.

How to Prepare and Configure the New DLP Action

Since the feature requires explicit administrator action, tenants will see no change unless someone edits or creates a DLP policy. Here’s a step-by-step checklist for rolling this out safely:

  1. Inventory your current DLP rules: Look for policies that use the generic “Block access” action for external users in SharePoint or OneDrive. Identify which ones could be refined with domain-specific blocking.
  2. Map your external relationships: Build a list of external domains you actively collaborate with, plus a separate list of domains or guest addresses that pose a risk (e.g., terminated partners, competitors, or individual users flagged by your security team).
  3. Start in simulation mode: Before enforcing blocks, create or modify a DLP ruled and enable simulation. Run it for at least a week while monitoring the audit logs and alerts to see which guests would be impacted.
  4. Communicate internally and externally: Inform your helpdesk about the new error messages. If blocking a domain that includes a still-valuable partner, coordinate with the relationship owner to transition them to a different email domain or a managed guest account before the policy goes live.
  5. Update your operational documentation: Add the new action to your DLP playbook, including the behavior around block/allow precedence and the lack of user overrides. This ensures consistent administration over time.

Remember: this control is not a substitute for tenant-wide external sharing restrictions in the SharePoint admin center or Azure AD/Entra ID guest settings. It’s a targeted, content-driven supplement. Use it for high-value secrets, regulated data, or trade secrets where you need to be absolutely certain a specific outsider cannot touch the file.

Looking Ahead: More Granularity on the Horizon

Microsoft’s roadmap for Purview DLP continues to emphasize context-aware controls. The company has already previewed policy tips for SharePoint and OneDrive that warn users before they share sensitive content; combined with domain blocking, the experience becomes more of a safety net than an abrupt wall. Future iterations might close the image-file gap, allow per-rule customization of the block message, or integrate with Entra ID’s risk-based conditional access so that a guest user’s risk level could dynamically influence DLP actions.

For now, the July 2026 rollout delivers a precise, operational tool that closes a glaring gap. Organizations that move deliberately—testing in simulation, communicating changes, and layering the new action with existing controls—will strengthen their data protection without stepping on collaboration.