Handling Encryption, Signing, and Permission Controlled Email
A recent question in the Microsoft Technical Community about Data Loss Prevention (DLP) policies covered the difference between encrypted, permission controlled, and signed messages. In this instance, the DLP policy rule included an exception to allow a message containing some sensitive data to pass if encrypted. However, the exception wasn’t triggered for messages protected by Office 365 message encryption (OME) or sensitivity labels. The documentation covering email exceptions didn’t add much insight.
Email encryption has been around for years. S/MIME and PGP are two examples of commonly used email encryption technologies. First supported by Exchange Server 2003, S/MIME support for message encryption and signing is still available in Exchange Online, with the caveat that tenants must take charge of the details of deploying and managing S/MIME to users.
Microsoft acknowledges that its OME and sensitivity labels technologies are direct competitors to S/MIME. These products are based on Azure Rights Management rather than public key technology. For Office 365 tenants, Microsoft protection is easier to deploy and manage, and it can encrypt email sent to other Microsoft 365 tenants and external domains without the need for the receiving organizations to take any action.
It’s even possible to configure sensitivity labels to use S/MIME instead of rights management protection. This is a custom configuration for sensitivity labels that requires the unified labeling client (and Azure Information Protection licenses). I have never used this facility and do not know how well it works in practice.
Email Exceptions for DLP
All of which brings me to the set of email message type exceptions available for a DLP rule (Figure 1). When Microsoft started to develop service-wide Data Loss Prevention capabilities, the set of actions, exceptions, and conditions available for Microsoft 365 DLP policies was more limited for email than Exchange Online DLP. Over time, Microsoft 365 DLP processing capabilities became better and better. Building out the exceptions available in rule processing is an example of where improvements have occurred. A year or so ago, tenants could move their Data Loss Prevention focus away from Exchange Online transport rules (ETRs) to Microsoft 365 DLP without losing functionality.
Apart from wanting to maintain the same DLP processing for both on-premises and cloud email workloads, I don’t know of any obvious reason to continue using ETRs within Microsoft 365. That being said, some organizations have enormously complex DLP rules which require substantial effort to move to Microsoft 365 DLP policies. In some cases, these tenants will stay using ETRs until they’re forced to move.
What we learn from Figure 1 is that the available message types for DLP exceptions are:
- Signed messages (digital signature applied by S/MIME).
- Encrypted messages (S/MIME). See this Exchange 2010 documentation.
- Permission controlled (rights management).
Permission controlled is an odd term. I can understand why it’s used because rights management is all about granting permissions to users or groups to interact with content, but the term doesn’t tell the administrator that it means rights management. But it does, and despite the fact that rights management can encrypt email, using Encrypted as an exception won’t work for messages protected by OME or sensitivity labels.
Permission Controlled the Way to Go
For most organizations, the Signed and Encrypted message types are now firmly in the legacy category, and they’ll never need to deploy Data Loss Prevention rules to deal with these types. The majority will use OME and/or sensitivity labels and should therefore use the permission-controlled message type in DLP policy rule exceptions. I never knew this detail until now. Discovering new things about how Microsoft 365 works daily is one of the unique joys (or pains) of coping with the cloud. At least, I think it does…
Learn more about how the Office 365 applications really work on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.
Thank you very much Tony. I was perplexed why the exception for encrypted message type would not work for my DLP rules.
Thank you so much Toni! this has gave me a hope to solve my issue which has been long time causing me a headache. I have been trying so stop DLP tips on my encrypted items, as it doesn’t make since to show this tips while I’m sending encrypted messages. However, for some season I can’t see the same list of exceptions. when I click (add exception), it pop up only 2 options (Content contains and Except if content is shared from Microsoft 365). I’d appreciate your help on how to get the same list in Figure 1.
I just checked and see the full list of message types as shown in Figure 1. Maybe you should have Microsoft Support check out your tenant? You pay for support, so you should ask for it.
@Mhammed Hisham Mohammed
i learned that based on the location to apply policy, it changes the options in dropdown. For example, if you have sharepoint, exchange, and onedrive, you do not even get the exception list.