How to Keep External Emails Out of Copilot Answers with Microsoft Purview

An email arriving in your mailbox does not make its contents trustworthy. That becomes an important distinction when Copilot uses your inbox to prepare answers, summaries or decisions.

Microsoft's June Copilot update highlights a Purview DLP control that excludes externally received email from Copilot processing. It was in public preview in June.

This is not an email-delivery rule

The distinction is worth making before you involve the messaging team. The control concerns the email Copilot uses for grounding, summarization and citations. It does not stop the user receiving or opening that email.

Microsoft's DLP documentation describes identifying external email through sender metadata relative to the tenant's accepted domains. This is not a verdict on whether the message body contains a malicious instruction.

In other words, a genuine supplier quotation can be excluded alongside an unwanted external message. That is why I would discuss the intended outcome with the business before enabling the policy broadly.

Define the scenario you are protecting

My example would be a team preparing internal operational briefings. Their agreed requirement is that Copilot should use approved internal information, not instructions or claims arriving directly from external senders.

That is a narrower requirement than “Copilot should never see unsafe content.” Internal messages can also contain inaccurate or copied information. I would describe this control as one boundary around a particular source, not complete protection against prompt injection.

Configure the relevant DLP policy

Use an account with suitable Purview DLP permissions and confirm the required licensing and feature availability. In Purview, create a custom DLP policy for the Microsoft 365 Copilot and Copilot Chat location.

For the rule, select the supported external-email condition and the action that prevents Copilot from processing the content. Review the available scope and deployment options before enabling enforcement. Do not copy an Exchange transport rule or select the Exchange email location and assume it produces the same result.

Test with information you can identify

I would send a test user two harmless messages: one from an internal sender and one from a genuinely external test domain. Give them different, unmistakable synthetic project details.

First, confirm that the user can access both messages normally. Then establish whether the relevant Copilot experience can retrieve or summarize the test messages before enforcement. After applying the policy and allowing for propagation, repeat the same questions in a fresh conversation. Check the answer, sources and policy feedback.

Keep a separate test for ordinary internal content. You need to understand both what stops working and what continues to work.

Final thoughts

This complements restricting Copilot processing of labeled files, but it solves a different problem. Start with the source you intend to exclude, test the actual experience, and make the productivity trade-off explicit.