DLP in Teams works differently to every other workload

In Exchange, DLP can evaluate a message in the transport pipeline before it reaches the recipient. The sender hits send, DLP checks the content, and if it matches a policy the message is held or rejected. The recipient never sees it.

Teams does not work this way. When a user sends a message in Teams, it is delivered first and then evaluated. If DLP detects a match, the message content is blocked within seconds - but there is a brief window where the message exists in the conversation.

For the sender, the message is replaced with a notification explaining it was blocked. They get a "What can I do?" link with options to override (if you have allowed it) or notify an admin.

For the recipient, the message shows as "Preview Unavailable" in their activity feed. They cannot see the content. But they may have seen a notification or typing indicator before the block kicked in.

This is not a design flaw - it is how Teams architecture works. Messages are delivered through a real-time messaging pipeline, not a store-and-forward system like email. The DLP evaluation happens as close to real-time as possible, but it is not instantaneous.

In Exchange, SharePoint, and OneDrive, DLP can send email notifications to the user, their manager, or a compliance team when a policy matches. These emails provide context, explain what triggered, and link to the content.

Teams DLP does not send email notifications at all. The only feedback a user gets is the in-app policy tip that replaces their blocked message. If you are relying on email alerts to track DLP incidents across the organisation, Teams events will not show up in that workflow.

This means your incident response process needs to account for Teams separately. DLP alerts in the Purview portal will still capture Teams matches, but the user-facing experience is limited to what they see in the Teams client.

You can customise the policy tip text, which helps. Use it to explain why the message was blocked and what the user should do instead. A generic "This message was blocked by DLP" is not helpful. Something like "This message contained financial data that cannot be shared in this channel. Contact the compliance team if you need to share this information" gives the user a path forward.

When you scope a DLP policy to specific users or groups for Teams, the coverage depends on what type of group you use:

Individual user accounts or security groups cover 1:1 chats and group chats only. They do not cover standard channels, shared channels, or private channels.

Microsoft 365 groups cover 1:1 chats, group chats, and all channel types including private and shared channels.

If you scope your DLP policy to a security group containing all your users but do not include the corresponding Microsoft 365 groups, your Teams channels are completely unprotected. The policy will show as active and will catch sensitive data in chat, but anything posted in a channel will pass through unchecked.

The safest approach is to scope the policy to all locations if you want full Teams coverage. If you need granular scoping, make sure every team's underlying Microsoft 365 group is included.

When a shared channel involves users from multiple organisations, the DLP policy of the host team applies to everyone in that channel. It does not matter what DLP policies the guest organisation has configured.

This has real implications. If your organisation has strict DLP policies and you join a shared channel hosted by a partner with no DLP, your policies do not protect that channel. The host controls enforcement.

Conversely, if you host a shared channel, your DLP policies apply to external participants. They will see your policy tips and be subject to your blocking rules, even though they are not part of your tenant.

For federated 1:1 chat (external access), the rules are different. Each user is subject to their own organisation's DLP policies. If both organisations have DLP, both sets of policies are evaluated independently.

This catches people out regularly. DLP for Teams chat and channel messages requires Microsoft 365 E5, A5, or the Information Protection and Governance add-on. E3 licences do not include it.

What E3 does cover is DLP for files shared in Teams, because those files live in SharePoint and OneDrive. So if someone uploads a spreadsheet containing sensitive data to a Teams channel, the SharePoint DLP policy will catch it. But if someone types that same data directly into a Teams message, E3 will not detect it.

This means you can have a DLP policy that blocks a file share but allows the exact same information to be typed into the chat. Users will find this inconsistency quickly, and some will use it as a workaround.

Before enabling Teams DLP, check your licensing. If you are on E3 and cannot move to E5, focus your Teams protection on file-sharing policies through SharePoint and OneDrive instead.