Table of Contents
New DLP Rule Blocks Microsoft 365 Copilot Using External Email as a Knowledge Source
Message center notification MC1301714 (last updated 17 July 2026, Microsoft 365 Roadmap item 561552) adds to the list of actions Data Loss Prevention (DLP) policies can exercise to control how Microsoft 365 Copilot processes information. Previous actions include blocking access to items with specific sensitivity labels, blocking Copilot from running external web searches, and blocking prompts containing sensitive information types like social security numbers.
In this case, the new action allows DLP policies to block Microsoft 365 Copilot and Copilot Chat from using emails received from external domains for grounding its responses to user prompts. The new action is now available in public preview. General availability is slated for late January 2027. The extended preview period is unusual. My guess is that it’s to allow Microsoft to measure the effectiveness of the new action and to remove some of the rough edges described below.
The Problem of External Email
Lots of information flows into Microsoft 365 tenants via external email. The problem is that the information in these messages is generated by people outside the organization and may or may not contain misleading or inaccurate knowledge. The same argument can be made about the contents of internal email, but for the sake of discussion, let’s imagine that our colleagues always include accurate data in their messages. In Microsoft terms, these messages are a “trusted internal Microsoft 365 data source.”
The other problem is that external email is a potential attack path against Microsoft 365 Copilot. This attack vector has already been used several times, notably in Echoleak, where an attacker sent a message containing malicious instructions for Copilot to process. Security researchers have pointed out the risk of cross prompt injection attacks (XPIA) for AI agents like Copilot. Microsoft says that the new block “helps organizations reduce the risk of prompt injection and untrusted data influence.”
Because Copilot works as the signed-in user, it can access every piece of information stored in Microsoft 365 that’s available to the user. A successful prompt injection attack against executives could therefore have serious consequences for an organization.
Implementing the Block for External Email
Documentation is available online and the steps to create a block for external email don’t need to be repeated here. At a high level, a DLP policy for the Microsoft 365 Copilot location will include a rule governing email received from people outside the organization with an action to block Copilot from accessing these items as a knowledge source. Figure 1 shows the rule condition and action.
When enabled, the block applies to external email sent to users of Microsoft 365 Copilot and Copilot Chat. The block prevents Copilot from referencing, summarizing, or using email received from external or untrusted domains as grounding data for its responses.
In terms of what an external domain is, the documentation says that the service uses message metadata to check the sender’s domain “against your tenant’s accepted domains.” For example, a message coming into my tenant from Microsoft.com or Gmail.com is external because neither of these domains are accepted domains for my tenant.
One of the more surprising aspects of the feature is its retrospective effect. I bet some people will think that DLP will only block new email from external senders, but that’s not the case. Existing messages are excluded from Copilot grounding once the policy takes effect, which means users can suddenly receive different answers from Copilot for identical prompts.
Testing the Block
The effect of the block is easy to test. Send or choose a message to yourself from an external email address. Make sure that something distinctive is in the message title or content that makes the email easy to find. With the block in place, Microsoft 365 Copilot will not find or reuse the external email. For example, Figure 2 shows a message from Google about “Google Payments.”
With the block in place, Microsoft 365 Copilot cannot find or use the email. The message is not removed from the inbox; it’s just invisible to Copilot and cannot be used as grounding data to form the response shown in Figure 3.
Not everyone will like external email to be blocked from Copilot processing. The argument is that too much interesting and valuable information flows into an organization from trusted partners and other sources. To limit the DLP policy to block external email, consider using an administrative unit to scope the policy for specific accounts, such as the accounts of executives that might be targeted by attackers.
The Problem of Accepted Domains
Using Exchange Online accepted domains as the basis for identifying external email is an effective method with one very big downside. It means that messages originating in domains belonging to other Microsoft 365 tenants inside a multi-tenant organization (MTO) are deemed to be external. Microsoft defines MTO as “a feature in Microsoft Entra ID and Microsoft 365. Given that MTO is designed to establish trust between up to five Microsoft 365 tenants, it’s surprising that DLP still considers messages originating in those tenants to be external.
Email-Carried Threats Continue to Evolve
Threat carried in email started with the ILoveYou virus in May 2000 and hasn’t stopped transforming and evolving since. Attackers seek weaknesses in computer infrastructures that are exposed by new components. Going after AI agents is just the latest twist in this long-running and continuing story.
Blocking external email from Copilot is a sensible addition to the guiderails for Copilot adoption, even if the preview implementation has a few rough edges to iron out.
Learn how to use Purview Data Loss Prevention and to exploit the data available to Microsoft 365 tenant administrators through the Microsoft 365 for IT Pros eBook. We love figuring out how things work.