Table of Contents
Be Careful Because Different Data Loss Prevention Engines Don’t Perform the Same Checks
Message center notification MC1315220 (18 May 2026) is a great example of what seems to be a perfectly reasonable Microsoft 365 update that could bite tenants in the rear. MC1315220 describes an optional update to the Exchange organization configuration to force OWA clients to stop using Exchange-based DLP policy evaluation and use Data Classification Services (DCS) instead.
Generally, I am all for moving from workload-based processing like the DLP checks performed by Exchange Online to a service that delivers the same kind of processing to all Microsoft 365 services. However, workload processing is often tailored to take advantage of specific features that are available only in the workload and cannot be leveraged elsewhere. Another example is Microsoft 365 retention labels which cannot move email items into archive mailboxes while Exchange Online retention tags can. There are workload-specific considerations in this switch, and that’s why you need to pause and check before updating the Exchange configuration.
The History of Data Loss Prevention in Exchange
/Exchange Server 2013 introduced DLP checks implemented via rules processed as messages pass through the transport pipeline. The same implementation exists today for Exchange 2019 and Exchange SE.
Exchange Online took its server-based DLP implementation to Office 365 and then Microsoft 365. Over time, Microsoft Purview DLP migrated Exchange Online away from depending on transport rules to its policy processing engine. However, Purview DLP still uses the Exchange Online transport pipeline to evaluate Purview DLP policy rules today as a backstop for client-side DLP checks. In effect, because all messages pass through the transport pipeline, it is the chokepoint to ensure the enforcement of DLP policies.
Client-Side DLP
Outlook clients like OWA, the new Outlook, and Outlook classic also perform DLP checks as users compose emails. By checking content to detect possible DLP policy violations, the clients can flag issues to users through DLP policy tips. Users then have a chance to adjust the email content before they send email. If an email still contains a violation, it will be detected and rejected by the checks performed in the transport pipeline. Today’s DLP supports many different rule conditions to check email for policy violations (Figure 1).
The change described in MC1315220 allows tenants to move the responsibility for performing the client-side DLP checks away from Exchange Online to Data Classification Services (DCS), the same service that’s used by the new Outlook (but not Outlook classic). In effect, it’s another small step to standardize components before making the new Outlook the predominant client for Exchange Online on or before the planned retirement of Outlook classic sometime in 2029.
Microsoft says that using DCS will allow OWA to support features like custom oversharing policy tips. DCS also supports the use of wait to send, a feature that ensures that the content of an email has been evaluated against DLP policies before the user can send it.
This all sounds harmless but moving from an Exchange transport-based checking mechanism to a general-purpose workload-neutral checking mechanism has some risks. Given the history of Exchange DLP, it’s possible that any tenant that started to use DLP with Exchange Server or when DLP first appeared in Office 365 might have some DLP rules that contain predicates which depend on transport pipeline processing. A workload-neutral engine that also deals with Teams, SharePoint Online, and OneDrive for Business has no knowledge of x-headers or routing logic. For example, DCS cannot handle a rule that looks for outbound messages that contain an X-confidential header. Switching to DCS processing will cause OWA to fail to detect the possible violation during email composition.
What to Do
If you operate a tenant with some old DLP rules, it’s time to check the rules to identify if any conditions are not on the supported list for policy tips. If none of the rules depend on Exchange-specific predicates and you’ve checked that the conditions are supported by DCS, then it’s safe to switch to DCS by running the Set-OrganizationConfig cmdlet:
Set-OrganizationConfig -DlpViaDcsEnabled $True
The change only affects client-side detection and policy tips by changing how DLP violations are detected before users send messages. Exchange Online will continue to enforce all DLP rules, including the older variety, in the transport pipeline to reject any message that violates a DLP policy.
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.