Microsoft Purview DLP Preview Blocks External Email From Copilot Grounding

The feature isn't new to people who track the Purview roadmap. It's still labeled preview, though, and the details matter. Here's what it does, what it doesn't do, and how to set it up.

What Microsoft actually shipped​

Microsoft's Purview documentation says administrators can prevent Microsoft 365 Copilot and Copilot Chat from using emails sent from external domains as grounding data for responses. With the control on, Copilot excludes external emails received by users from being referenced or summarized during prompt processing, while continuing to use internal Microsoft 365 data sources where permitted.

Microsoft's stated reason is that it helps organizations reduce the risk of prompt injection and untrusted data influence.

The timeline is longer than the latest headlines suggest:

• June 2026: Microsoft's "What's new in Microsoft Purview" page listed the condition as being in preview: New Email is received from > External users condition for the Microsoft 365 Copilot and Copilot Chat policy location lets DLP policies prevent Copilot from using external email as grounding data.
• July 2026: Tony Redmond at Office 365 for IT Pros reported that the new action is now available in public preview. General availability is slated for late January 2027. The extended preview period is unusual.
• Early October 2026: Microsoft's DLP-for-Copilot documentation was last updated on October 5. It still calls the external-email block a preview and gives no general availability date.
• October 9, 2026: Windows Report covered the control as a new safeguard against email-based prompt injection.

Bottom line: this is a preview control you can test now. Microsoft's own documentation doesn't confirm a general availability date. The January 2027 target comes from Office 365 for IT Pros, and preview timelines can slip.

Why the inbox is a problem for AI​

The attack is simple. Someone outside your company sends an email containing text meant for the AI rather than the human, such as an instruction to ignore earlier guidance. Later, an employee asks Copilot to summarize the week's mail. If Copilot uses that message as grounding, the attacker's text becomes part of the material the model works from.

Microsoft's defense-in-depth guidance calls this an indirect prompt injection. The user's prompt points Copilot at content holding malicious instructions, and those instructions can sit in files, images, code or encoded text rather than in the prompt itself.

An earlier WindowsForum analysis described the problem well: the inbox is both the richest workplace data source and the least trustworthy one. It also noted that an externally originated message is no longer just something a user might read; it can become a hidden ingredient in a generated answer, a meeting brief, a draft response, or an agentic workflow.

That's a real change to Copilot's security model. Until now, Microsoft's main reassurance was permissions: Copilot only sees what the user can see. This control filters on where the content came from. An email can be fully readable by the user and still be off-limits to the assistant.

How it works: the sender is checked, the body isn't​

The most important technical detail, and the easiest to misread:

• Matching is based on sender metadata. When the policy detects that an email was received from a sender outside your organization's accepted domains, Copilot excludes that email from grounding, summarization, and citation.
• The message body is never scanned. Microsoft says the policy looks only at the sender's domain and compares it with the tenant's accepted domains.
• Users keep full access to the mail. Per Microsoft, the user's access to the email itself isn't affected. Windows Report adds that users can still read, reply to, forward and manage external messages normally.
• Mail flow doesn't change. This isn't an Exchange transport rule, a quarantine action or a retention setting. It works only at the Copilot grounding layer.
• Users see a notice. In Microsoft's example, Copilot answers from internal mail and other permitted sources, and the user sees a message that some content was excluded by an organizational policy.

Coverage, per Microsoft: the preview applies to Microsoft 365 Copilot and Copilot Chat, including email summarization and reasoning experiences that use email data.

Because the check is domain-based, it doesn't judge each message. A harmless invoice from a long-time supplier and a carefully built injection payload from a fake domain are treated the same way: both are excluded. That's the trade-off.

Step by step: turning it on​

Prerequisites​

• Roles: Windows Report mentions Compliance Administrator or DLP administrator. Microsoft's list for this policy location is longer and should be treated as authoritative. It includes Microsoft Entra AI Admin, Purview Data Security AI Admin (and the matching role group), Purview Compliance Administrator, Purview Compliance Data Administrator, Purview Information Protection, Purview Information Protection Admin, Purview Security Administrator and Microsoft Entra Global Admin. Microsoft advises using the least-privileged role that works and keeping Global Admin assignments to a minimum.
• Accepted domains: "External" means "not in your tenant's accepted domains." Review that list in Exchange before you begin. A missing subsidiary domain will cause that subsidiary's mail to be excluded.
• Licensing: For licensing, Microsoft's DLP-for-Copilot page points to its Enterprise plan and service descriptions. It doesn't name a specific SKU for this preview, so check with your licensing contact before you promise it to anyone.

Configuration​

1. Sign in to the Microsoft Purview portal.
2. Go to Data Loss Prevention > Policies and create a new policy.
3. Choose the Custom template and then Custom policy. Microsoft says the Copilot location is only available in the Custom template.
4. On the Locations page, turn on Microsoft 365 Copilot and Copilot Chat. All other locations for this policy are then disabled, so it has to be a separate, Copilot-only policy.
5. Add a rule with the condition Email is received from > External users.
6. Set the action to Prevent Copilot from processing content.
7. Optionally, turn on policy tips and add a compliance URL. The "Learn about access restrictions" link in Copilot's block message will then open your own internal policy page instead of Microsoft Learn.
8. Start in simulation mode, review the results, then turn the policy on.

What success looks like​

When a user asks Copilot to summarize their inbox, the answer should draw only on internal mail and other permitted Microsoft 365 content, along with a notice that some content was excluded by policy. Don't panic if nothing changes right away. Microsoft says DLP policy updates can take up to four hours to show up in Copilot and Copilot Chat.

Common problems​

• Internal partner mail is disappearing: check the accepted domains list first.
• The policy can't be scoped to one department through admin units: Microsoft says this policy location doesn't support admin units.
• You expected content scanning: this control doesn't do that. See the next section.
• Rule conflicts: Microsoft notes that sensitive information type (SIT) conditions and sensitivity label conditions can't share a rule. Keep the external-email rule tidy and separate from your label-based rules.

What this control doesn't do​

There's a risk of overselling this. It's a useful setting, but it doesn't stop prompt injection on its own.

• It doesn't detect malicious instructions. It removes a whole category of content. An injection that arrives by another route, such as a shared document, a Teams message or a compromised internal mailbox, isn't covered.
• Compromised internal accounts get through. If an attacker takes over a colleague's mailbox, their mail comes from an accepted domain and counts as trusted.
• It doesn't protect people. A user can still read a phishing email and act on it without Copilot.
• It costs productivity. Sales, procurement and support teams live on external mail. If the policy applies to them, Copilot can no longer summarize customer threads, which may be the main reason they use it.

Microsoft treats this as one layer among several. Its defense-in-depth guidance lists Microsoft Defender for Office 365 Plan 2 prompt-injection protection, which detects injection content in inbound email before it reaches a user or an AI assistant. It also lists Copilot's own exclusion of spam mail from grounding, jailbreak classifiers that send signals to Defender and Purview audit logs, and Safe Links for URLs in responses. The two email controls work differently. Defender inspects content in the mail pipeline, while the Purview rule excludes by sender domain at grounding time. They complement each other, and neither replaces the other.

The WindowsForum take​

The control is simple, and that's both its strength and its weakness. A sender-domain check is predictable and easy to audit, and it can't be talked out of its decision by clever wording in a message. It's also a blunt tool that will block legitimate business mail along with attacks.

Here's a sensible rollout for most tenants:

1. Clean up accepted domains.
2. Run the policy in simulation and measure how much external mail Copilot currently uses.
3. Enforce it first for high-risk groups, such as executives, finance and anyone whose Copilot use feeds agentic workflows.
4. Pair it with Defender for Office 365 content inspection where you have the license.
5. Use a custom policy-tip URL to explain the policy, so users aren't left wondering why Copilot stopped mentioning their biggest customer.

The bigger story is direction. Purview is becoming the policy layer for Copilot: it already gates sensitive prompts, labeled files and web search, and now it can gate email by where it came from. If you're preparing for a broader Copilot rollout, add this to your DLP plan alongside label-based exclusions and web-search restrictions.