Table of Contents
New DLP Rule to Block Sharing for Domains and Users to SharePoint Online and OneDrive Files
Message center notification MC1338823 (6 June 2026, Microsoft 365 Roadmap Item 557191) describes a new preview capability for Data Loss Prevention (DLP) policies where files shared outside a tenant from SharePoint Online or OneDrive for Business can be blocked for specific external domains and/or individual users (via SMTP email addresses). Figure 1 shows an example of the rule inside a DLP policy.

Before the rule can fire, it must:
- Include the “content is shared with people outside the organization” condition.
- Include a condition to identify the information covered by the rule.
- The condition must include a “sensitivity type” (that’s what the UX says). What it means is that the condition must include a sensitivity label, sensitive information type (SIT), or trainable classifier.
The rule can contain other conditions, such as the file having a specific retention label.
Configuring Allow and Deny Lists for External Domains
The external domains and users covered by the rule are defined as properties of the action configured as an allow list (IS NOT) and a deny list (IS). An external domain is one that is not an accepted domain for the tenant.
In Figure 2, I’ve defined three domains to block along with a specific SMTP address that isn’t part of the three domains. The same operator (IS or IS NOT) must be used for both domains and individual addresses, meaning that a single DLP rule cannot include both an allow and a deny list. If you want to have separate allow and deny lists, you must create separate DLP rules for each list (alternatively, you can create another DLP policy with an appropriate rule).

When DLP detects that a file matches the condition which invokes the rule, it combines the deny and allow lists from the different rules and gives precedence to the deny list, meaning that if a domain or user is included in both lists, the most restrictive option (deny) wins.
Microsoft explains how the rule decides to block or allow access as follows: “If a file matches both an allow rule and a block rule, evaluation is across all matching rules — allowed users and domains are permitted, blocked users and domains are denied, and users in neither list are blocked by default.” The last point is important. If you build an allow list containing several user SMTP addresses, only those users will have access to files. For example, if you want to block all Gmail.com addresses except JoeThePlumber20417@gmail.com, insert that address into an allow list and don’t put Gmail.com into a deny list. All other Gmail.com users will be denied access. In effect, this means an allow list behaves as an explicit authorization list rather than an exception list.
Internal domains and user SMTP addresses cannot be configured in the allow or deny lists. See the documentation for more details.
When a blocked user attempts to access a shared file, SharePoint Online or OneDrive for Business prevents access and displays an error (Figure 3).

I can’t help feeling that there isn’t an easier way to create and view the allow and deny lists than the somewhat spartan UX used by DLP. The phrases IS or IS NOT could be replaced by “Deny” and “Allow,” for instance. A unified view of who has access and who is blocked could be shown after configuring the rule to include restrictions from all rules and policies. Perhaps easier configuration and better visibility will come in a future revision. For now, expect some confusion.
Consumer Domains are the Target
Although Microsoft isn’t saying it directly, it seems likely that the new capability is to allow Microsoft 365 tenants to block sharing with consumer email domains like Gmail.com and Yahoo.com. It’s a reasonable capability to introduce for a data loss prevention solution because organizations want to control where their most important information goes. Other examples of potential uses include:
- Blocking access from former partners.
- Restricting access to domains associated with acquisitions or divestitures.
- Limiting sensitive content to a small set of approved supplier domains.
- Allowing only named external users involved in regulated projects.
The new capability depends on the DLP rule identifying content through a sensitivity type condition, such as a sensitivity label, sensitive information type (SIT), or trainable classifier. One way to satisfy this requirement is through a sensitivity label. Sensitivity labels with encryption can also block access by not granting rights to the protected content. Confidential information is likely to be protected by sensitivity labels with encryption to block unauthorized access, and the rights specified in the label might not allow access to external users. In that respect, restricting access via DLP is a block built upon another block.
An Array of Blocks
Purview Data Loss Prevention is currently on a roll in terms of extending how to protect against poor sharing practices. Simply blocking access is less dramatic than putting a shared file into quarantine, and the allow and deny lists give flexibility in how these rules work over the action to block access for everyone outside the organization. It’s nice to be flexible and it will be interesting to see how Microsoft 365 tenants use this capability in practice.
Support the work of the Microsoft 365 for IT Pros team by subscribing to the Microsoft 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365. Only humans contribute to our work!