Read this to:
Automatically Encrypt Outbound email containing sensitive info.
Automatically Decrypt messages sent between Tenant users.
Automatically Decrypt messages for storage in a 3rd party Journaling service.
This article outlines some settings for Mail Transport Rules that encrypt and decrypt messages using Microsoft Purview Message Encryption. It also has guidance for admins using third party Journaling services as there are special considerations in order to ensure encrypted messages are able to be read once Journaled. It’s not exhaustive, so refer to official documentation if you get stuck.
There’s a good chance your security posture requires encryption when sending emails to third parties which contains sensitive data like: Personally Identifiable Information (PII), Personal Health Information (PHI), Payment Card Information (PCI), SSN, Bank Account/Routing, Taxpayer ID, Passport ID, Driver License.
At the extreme, this means setting some users’ Outlook to encrypt every message. A step below that would be a best practice of automatically encrypting what you know is sensitive. Simultaneously, you don’t want your internal users to need to authenticate or require entry of a One-time Password in order to view messages and documents sent between colleagues. AND, any solution you put in place must ensure that the messages, encrypted or not, are able to be stored in your third-party Journaling system. Let’s get started.
- Transport Rule: Encrypt Sensitive Data
- Apply rule if Recipient is Outside the Organization (external)
- AND Sender is Inside the Organization (internal)
- The Message contains any of the sensitive data types. They give you a big list. US-based admins can scroll to that section and add what they need (don’t forget about Credit Card Number and ABA Routing Number as those are not grouped with the other US data types).
- Do the following: Modify the message security: Apply Office365 Message Encryption and Rights Protection (Rights Protect message with ‘Encrypt‘)Note: The ‘Encrypt’ RMS (Azure Rights Mangement) Template is okay to use when getting started. I would strongly consider using Do Not Forward for more control (prevent Forward, Print and Copy) over how the data is used by those on the other end. In addition, you’ll see two tenant-specific RMS templates you can assign (Confidential and Confidential View Only) but keep in mind those designations will limit use of such email to authenticated users of your Tenant only.
Note about OME Templates / custom branding: When you set your transport rule to Encrypt emails you may notice there is another option in the dropdown to apply an Outlook Message Encryption (OME) Template which is used to specify certain security options as well as to add custom branding (logo, bg color etc) to the email wrapper and secure portal.
If your particular 365 licensing allows it, you can create multiple templates through PowerShell which you then apply with your transport rule. However, don’t add ANY template until you have read the Important Note in the Journaling section below.
OME Templates are beyond the scope of this article, but just know Business Premium with no addons only supports the default template* ‘OME Configuration‘. Additionally, if you are only using the default template, DO NOT specify the default template in your mail rule. It will be applied to encrypted messages implicitly.
*You can and should customize the default template. Please note branding will affect secure emails for ALL your accepted domains. Use the guide here to see what’s possible: Manage Office 365 Message Encryption – Microsoft Purview (compliance) | Microsoft Learn
- Transport Rule: Decrypt for Tenant
- Apply rule if Sender is Inside the Organization AND Recipient is Inside the Organization
- Do the following: Modify the message security: Message Encryption and rights protection. Strangely it doesn’t have ‘remove’ in its description, but when you add it, you’ll see “Remove Office 365 Encryption and rights protection” appear below the rule condition.
- AND Modify the message security: Remove attachment rights protection applied by the Organization.Note: This rule reduces friction for internal users when other internal users send them encrypted documents. Some users might have Encryption on for all sent emails. Others might encrypt a document to send to external party, with a CC to an internal address. Or maybe the user sent sensitive info without realizing and the message was automatically encrypted by the other transport rule. Regardless of source, after applying this rule, internal users will get a decrypted copy they can use.
Journaling Encrypted Messages
Let’s assume you want to use Journaling with third party compliance or retention software. You have decided to allow and even enforce encryption for your users, but now you have identified a business need to see the content of those protected messages that were sent (third-party encrypted messages received are not decrypted by Journaling). To save those messages in clear text you will add:
- A Journaling Rule
- If you don’t already have one, see Journaling in Exchange Online | Microsoft Learn
- Now might be a good time to review the scope and settings of the Journaling Rule. One thing to consider is whether your Alternate Journaling Mailbox has the security and configuration to handle any sensitive documents which are sent to it if your main mailbox is unavailable.
- A setting change in PowerShell
- Connect to your Exchange tenant: Connect to Exchange Online PowerShell | Microsoft Learn
- Run Get-IRMConfiguration to see current settings.
- Run Set-IRMConfiguration -JournalReportDecryptionEnabled $true
- Check the settings again using Get-IRMConfiguration
Important Note: Microsoft says Journal report decryption doesn’t currently support the explicit use of OME branding templates. In order to have the Journaling Rule send a decrypted copy of each email, you cannot reference ANY branding template in your Mail Flow transport rules. This applies no matter what 365 licensing you use. The good news is you can still customize the default “OME Configuration” template using PowerShell. Keep in mind default template changes will apply to all accepted domains in your tenant, so brand accordingly.
For security options and branding, see this link: Manage Office 365 Message Encryption – Microsoft Purview (compliance) | Microsoft Learn
Lastly, test everything:
- Proactive Encryption of email tenant-to-tenant and tenant-to-external.
- Automatic Encryption based on sensitive data detected tenant-to-tenant and tenant-to-external.
- Decryption of tenant-to-tenant proactively encrypted email.
- Decryption of tenant-to-tenant automatic encrypted email.
- External-to-tenant email containing sensitive data detected.
- Storage of all those encrypted and unencrypted test emails in your third-party Journaling system.
- **Use Message Trace to see which rules are applied**
- **Be patient with rule changes as MS gives no guarantee that they take effect immediately, though that’s been my experience**
- **Be patient with your Journaling archive. It may take more than a moment to store and index new messages**
A Note about Guests in your Tenant:
Guest users in your Tenant are treated the same way as users in your accepted domains unless otherwise segregated. When you configure the condition “The Recipient is internal”, Guests count as internal. If you need to treat Guests different, you can add them to a Group and exclude them on the rule. Or modify the rule entirely so it only applies to specific Tenant domains. You get the idea.
Might I suggest: Sensitive Data Notification Transport Rule:
This would be a transport rule similar to the Encrypt Sensitive Data rule but under Do the Following look for Generate Incident Report. Select the recipient and the data to send in the emailed report. While it won’t capture all leaked data, it is useful as a heads-up to the admin in the case of a data leak (intentional or unintentional) or serve as the basis for educating the user or perhaps developing better IT systems or procedures for handling sensitive data. You can either add this condition to your existing Encrypt Sensitive Data rule or setup as a standalone. Note: DLP Policies are preferred over transport rules as they provide a more flexible way of handling the sensitive data that is headed out of the network.
Pro Tip: Make it simpler for a user to Encrypt an email:
Suggest to users that they may modify their Ribbon to move the Encrypt button from the Options page to the Message page. I can’t say if this is possible automatically through Group Policy templates (although I did see someone who used GPO to overwrite each user’s ribbon config file…which works but nukes any user customizations. Maybe that’s what you want? Just an idea).
Lesson Learned: How to identify MS encrypted email via a Mail Flow Transport Rule:
While messing with encrypt/decrypt rules I was struck with the thought that I might want to add additional handling for encrypted messages but wasn’t sure how to identify them. I wasted time looking at using a header like Content-Class: rpmsg.message. Forget about it. Just apply the rule where Message properties include the message type: PermissionControlled. That will pick up email that is encrypted through Microsoft. There is another type called Encrypted; I’m not entirely sure but this may pick up received messages encrypted by third parties. More testing needed.
This article assumes you have licensing for Business Premium or higher and you’ve activated Azure Rights Management to use Microsoft Purview. Also, transport rules are fine and all, but the real magic is in DLP Policies. While DLP can work hand in hand with Mail Flow, on their own they provide for support for things like trainable classifiers, sensitive information types, AI-based recognition and more. I’ll be tackling those in a future article.