Let’s take a high-level look at the prerequisites for using Microsoft Purview Message Encryption before diving into the detail.  The service relies on or rather is built on, the Azure Rights Management service, so the first thing we need to do is make sure that is enabled. Next, we need to verify that Microsoft Purview Message Encryption is enabled. I’m only including this step for completeness, as the service is offered with most subscription types.

As you can see, most of the enterprise-level subscriptions come with message encryption support as standard, and those that don’t, can have the service added. The bottom line is that this is a universal offering available to all Microsoft Office 365 subscriptions in one way or another.

From a user’s point of view, message encryption can happen in several ways. Message encryption can be triggered by rights management templates, which are part of Azure Information Protection. However, we’re more interested in the “Do Not Forward” and “encrypt-only” options, as well as mail flow rules. Mail flow rules are set up within the Exchange admin center and are a way to perform message-related actions based on sender, receiver, and message properties.

When the “Do Not Forward” option is applied to an email, the message is encrypted along with any attachments. Attachments is starred as not all attachment types will be encrypted, but I’ll get to that shortly. Do not forward require all recipients to be authenticated. As you’d expect, the forward button in the recipients’ Outlook mail client is disabled. They are unable to print or save the message and cannot add or change recipients to the To, Cc, or Bcc fields. Under Azure Information Protection, there is a forward usage rights template. The critical difference between the two from a usage perspective is the recipient list. The forward template recipients are defined in advance as part of the template, while the Do Not Forward option recipients are specified as, well, the message recipients.

The encrypt-only option has similar functionality to Do Not Forward as far as the message content, attachments, and recipient authentication are concerned. Recipients can forward the message but are unable to Save As, Export, and don’t have Full Control usage rights. Oh, and they can’t remove protection, either.

When it comes to attachments, not all documents are treated equally. As you’d expect, current office document types automatically inherit the message’s protection settings. Apart from the usual suspects, we have XPS documents. Total message size, including attachments exceeding 25 MB, will not be encrypted.

Older office files, that is, 97-2003 office versions shown in white here, aren’t automatically encrypted by Microsoft Purview Message Encryption. However, they are covered by information rights management policies. Non-office files or documents that require a different level of protection than that of the message can be protected prior to attachment.

 

I guess a reasonably sized elephant in the room is how recipients’ email clients work with encrypted and protected messages. Naturally, those within the Microsoft 365 ecosystem using Outlook will have a first-class, unified, and seamless experience regardless of whether they belong to the same organization as the sender. The native experience extends to Outlook 2016 and Outlook web users, where no special action is required to view protected messages. Other email clients sent an encrypted or rights-protected message will receive a notification email directing them to a portal to view the message. Gmail users will be able to sign into the portal with their Google credentials, while Yahoo and other ISP recipients will need to use a single-use code to authenticate.