DLP in Teams: messages are not files

An administrator posts a link to a test document in Teams. An external recipient cannot open it, so the pilot is declared successful. A colleague then types the same sensitive information directly into a chat, and the message goes through. The first test checked file protection in SharePoint or OneDrive, rather than DLP for Teams message text.

DLP for emails and files differs from Teams message DLP in both licensing and technical scope. Office 365 or Microsoft 365 E3 can cover the relevant DLP for SharePoint, OneDrive and Exchange. That does not establish rights to protect chat and channel message content too. Even the correct licence cannot fix a policy targeting the wrong conversation type or population.

This article draws on Teams DLP documentation and the current Purview service description, checked on 20 October 2026. Examples concern an internal corporate pilot; the numerical model is neither a quotation for a particular SKU nor a licensing calculation for external organisations.

Start with the object you need to protect

Users see one Teams window, but the underlying data is not a single service. Message text passes through a different DLP check from a linked document. Microsoft's Teams DLP guide explicitly distinguishes these scenarios.

Do not include endpoint protection or rules for every browser in the pilot's conclusions merely because one Teams message was blocked. Map the data's exit route first. A precisely defined test action tells you more than a general statement that “DLP works”.

Count licences for the feature's beneficiaries

The current Purview service description identifies the beneficiaries of Teams DLP as senders whose outgoing messages are inspected. A feature can be technically available at tenant level; an administrator's licence does not therefore cover all inspected employees.

Listed options include Office 365 E5, Microsoft 365 E5 and the applicable higher-tier Purview offers. Check the exact add-on and prerequisites in the DLP for Teams row, rather than relying on a similar name to another DLP product. These are examples, not an exhaustive list of commercial, education or government variants.

Business Premium alone is not evidence of Teams message DLP rights. The service description lists it for email and file DLP, a different part of the table. Rights to use Teams itself are a separate question: a Microsoft 365 variant without Teams needs the relevant service access separately.

Hypothetical example: 100 internal employees have Microsoft 365 E3 and appropriate Teams rights. Twelve will pilot DLP for outgoing messages. We assume that the selected higher-tier licences or add-ons actually cover their scenario.

This model does not calculate every other Purview feature or automatically require a licence for each external recipient. The basic question is whose messages this particular feature inspects and what establishes that person's entitlement.

Selecting users does not verify channels

Teams DLP documentation makes an important distinction in targeting. Its table supports individual user accounts for individual and group chats, but not for standard, private or shared channel messages. Supported groups have broader scope.

For a twelve-person pilot, selecting twelve accounts and testing chat does not establish channel coverage. Choose supported group targeting, verify actual membership and test the required channel scenario separately. A group named “DLP pilot” does not demonstrate who belongs to it.

Later changes to group membership or policy locations can also change licensing scope. Operational handover should identify the owners of the group, policy and licensing inventory. This relationship matters more than a one-off screenshot of apparently correct settings.

Shared channels differ from external chats

For a shared channel using B2B direct connect, current documentation describes evaluation according to the sender's home organisation. Company A's messages are subject to A's policies; company B's messages to B's policies, regardless of channel ownership. Company A does not thereby gain enforcement over company B's senders.

For a federated external chat, the documentation instead distinguishes the hosting tenant that initiated the chat or thread. In the documented scenario, A's policies apply to its people's messages when A is hosting; B's policies are not automatically applied to B's users' messages in that chat. Do not assume that a home-tenant DLP policy follows a user into every conversation.

Create test conversations from both sides and record who initiated them. Do not classify a shared channel, an ordinary external chat and a guest account as the same scenario. They are different identity and communication models. The access side is covered in our guide to shared channels with external partners.

Attached-file protection remains a separate check based on actual storage and SharePoint or OneDrive rules. A correct result for an external participant's message does not establish an identical result for every document in the channel.

Simulation does not prove blocking

Simulation mode evaluates a policy without enforcement and provides separate results. For Teams, this mode evaluates new items created during the simulation. A message going through can therefore be the expected outcome in testing mode. Old content without a new test action is insufficient to verify a rule.

Use synthetic content that meets the documented requirements of the selected sensitive information type. Do not test protection with real personal data. Also record thresholds, exceptions and user overrides: a policy permitting override has a different expected result from unconditional blocking.

Follow simulation with a limited enforcement test. Distinguish a user notification from actual denial of the recipient's access to a message or file. Teams DLP also does not use the same user email notifications as Exchange, SharePoint and OneDrive. No email, by itself, does not show that the rule failed to run.

A test matrix for operational handover

Write each row's expected result in advance based on the specific policy. If another policy caused the block, the test has not yet verified the new design.

1. Define protected data and transfer routes, rather than only listing applications.
2. Separate file, message and any endpoint DLP; check rights for each feature.
3. Align licensing with the policy's actual population. Check the Microsoft Communications DLP service in the relevant plan against the service description.
4. Choose supported targeting for chats and required channels, and verify membership.
5. Run a simulation with new test messages, followed by a limited enforcement test.
6. Document recipient results and external directions, rather than only the administrator's portal view.

For a broader security package decision, see the comparison of Microsoft 365 E3, E5 and add-ons. Package selection should follow verified features and population, rather than replace their definition.