Purview DLP and sensitivity labels with Exchange Server: what works on-prem and in hybrid

"Do our Purview DLP policies and sensitivity labels cover the mailboxes that are still on Exchange Server?" The honest answer is "partly", and which part depends on where each mailbox lives and which servers a message passes through. In this post I'll map the three engines involved, show what each one sees on-premises and in hybrid, and give you the commands to build your own coverage map.

How it works: three engines, not one#

Microsoft Purview DLP#

Purview DLP protects email through its Exchange location, and that location is Exchange Online: the rules run in Exchange Online transport, and policy tips appear for Exchange Online mailboxes. Purview does have an on-premises location (-AddOnPremisesScannerDlpLocation in Set-DlpCompliancePolicy), but it covers file shares and SharePoint Server through the information protection scanner, not Exchange Server mailboxes.

Exchange Server's own DLP#

Exchange Server has a separate DLP feature, and Microsoft's documentation for it applies to Exchange 2016, 2019 and Subscription Edition (SE). An Exchange DLP policy is a package of mail flow rules (transport rules) that detect sensitive information types or Document Fingerprinting matches, show Policy Tips to users, and can run in test mode before you enforce it. It's a premium feature that needs Exchange Enterprise CALs. You manage it in the Exchange admin center under compliance management › data loss prevention or with New-DlpPolicy. Nothing is shared with Purview: separate policies, separate sensitive information type definitions, no Purview alerts or Activity explorer, and no exact data match or trainable classifiers.

What changed in Exchange 2019, SE and Exchange Online#

• On-premises: Exchange Server DLP is still documented for 2019 and SE. Microsoft's "Data loss prevention in Exchange Server" page applies to Exchange 2016, 2019 and SE, unlike Unified Messaging, which Exchange 2019 dropped.
• Exchange Online: from mid-November 2023 Microsoft removed the DLP predicates from mail flow rules (Message center MC670895, announced on the Exchange Team Blog): MessageContainsDataClassifications, the sender-override conditions and the NotifySender action. Rules that use them are no longer evaluated, so in the cloud, DLP means Purview DLP.

Sensitivity labels and encryption#

Labels are published to users rather than mailboxes, and their encryption comes from the Azure Rights Management service. Microsoft states that Exchange doesn't have to be configured for Azure Rights Management before users can apply labels in Outlook to encrypt email, but that you don't get the full functionality until it is (for example, reading encrypted mail in Outlook on the web or on phones, and search indexing). Exchange Online has that integration built in. For Exchange on-premises, Microsoft says to deploy the Microsoft Rights Management (RMS) connector and configure your Exchange servers, which lets them use their IRM features with the cloud service. Outlook also records the applied label in the message's msip_labels header as MSIP_Label_<GUID>_Enabled=true plus other values (the format is in Microsoft's MIP SDK metadata reference), and on-premises mail flow rules can match that header.

What to expect#

Hybrid routing: which engine sees which message#

• Centralized mail transport. Exchange Online sends the internet mail of cloud mailboxes out through your on-premises servers. Purview DLP evaluates those messages in Exchange Online, and your on-premises DLP policies and mail flow rules evaluate them again on the way out. Keep the two rule sets consistent, or one message can get two different verdicts (connectors: see Exchange hybrid mail flow).
• On-premises mail sent out through Exchange Online. If your on-premises internet send connector points at Exchange Online, those messages pass through Exchange Online transport, where mail flow rules run. Microsoft's hybrid note on its Exchange Server DLP page makes the reverse point: DLP policies applied in Exchange Online never see mail between on-premises users, because that mail doesn't leave the on-premises environment. Microsoft doesn't spell out how Purview DLP treats on-premises senders whose mail does pass through Exchange Online, so treat that coverage as something to prove in a pilot, not something to assume. The certain way to put a mailbox under Purview DLP is to move it.
• Cross-premises mail. Mail between on-premises and cloud mailboxes uses the hybrid connectors, whose tenant routing address space is more specific than *, so an on-premises connector to a third-party DLP gateway doesn't see it. See routing Exchange mail through DLP gateways.

Step-by-step: build your coverage map#

1. Count where mailboxes live#

(Get-Mailbox -ResultSize Unlimited).Count
(Get-RemoteMailbox -ResultSize Unlimited).Count

2. Record how mail leaves#

# Exchange Management Shell
Get-SendConnector | Format-Table Name,AddressSpaces,SmartHosts,Enabled -AutoSize
# Exchange Online PowerShell
Get-OutboundConnector | Format-List Name,ConnectorType,RouteAllMessagesViaOnPremises,SmartHosts

3. List the policies on both sides#

# Exchange Management Shell
Get-DlpPolicy | Format-Table Name,Mode,State
# Security & Compliance PowerShell
Get-DlpCompliancePolicy | Format-Table Name,Mode,ExchangeLocation

4. Cover on-premises mailboxes with Exchange DLP in test mode#

Get-DlpPolicyTemplate | Format-Table Name
New-DlpPolicy -Name "Card data - audit" -Template "<template name from the list>" -Mode Audit

To act on a sensitivity label on-premises, get the label's GUID with Get-Label | Format-Table DisplayName,Name,Guid in Security & Compliance PowerShell, then match it in a mail flow rule, in audit mode first:

New-TransportRule -Name "Highly Confidential stays internal" -SentToScope NotInOrganization `
  -HeaderMatchesMessageHeader "msip_labels" -HeaderMatchesPatterns "MSIP_Label_<label GUID>_Enabled=true" `
  -RejectMessageReasonText "Highly Confidential mail can't leave the organization" -Mode Audit

The pattern condition matches the GUID inside the longer header value, which a whole-word match may miss. Test with messages labelled in the Outlook versions your on-premises users actually run, because the client writes the header.

5. Decide whether you need server-side IRM#

If on-premises users must read encrypted mail in Outlook on the web or on mobile devices, or you need journal report decryption, deploy the RMS connector. The setup and the Test-IRMConfiguration failures you can meet are covered in IRM with the RMS connector.

Verify#

• Cloud mailbox: send test content to an external address and check the policy's simulation results or Activity explorer, as described in Purview DLP from simulation to enforcement.
• On-premises mailbox: send the same content and look for the transport rule agent's AGENTINFO entries in message tracking:

Get-TransportService | Get-MessageTrackingLog -Sender onprem.user@contoso.com -EventId AGENTINFO `
  -Start (Get-Date).AddHours(-1) | Format-List Timestamp,Source,EventData

Good looks like a match on each side for the mailboxes that side is meant to cover, and no test message that leaves without passing at least one engine. More on reading tracking output in message tracking with Get-MessageTrackingLog.

Tips and gotchas#

• Encrypted content is opaque to transport. Exchange Server DLP rules can't read an encrypted body unless IRM transport decryption is set up, and third-party DLP gateways need their own decryption support.
• Don't try to rebuild Purview DLP with Exchange Online mail flow rules; the sensitive information conditions are gone there.
• Define custom sensitive information types separately on each side. A custom type created in Purview doesn't exist on Exchange Server.
• Label design and auto-labeling are covered in rolling out sensitivity labels; inline DLP appliances in Symantec DLP Network Prevent with Exchange.

References#

• Data loss prevention in Exchange Server (Microsoft Learn)
• Restrict access to content by using sensitivity labels to apply encryption (Microsoft Learn)
• Microsoft Information Protection SDK - Metadata (Microsoft Learn)
• Exchange Online Mail Flow Rules to stop supporting DLP-related rules, conditions, and actions (Exchange Team Blog)