Configuring Microsoft Purview Message Encryption
Start course

Email Encryption Solutions in Microsoft 365 looks at how messages and attachments are protected both within the Microsoft 365 ecosystem and when they are sent to external recipients. This course outlines the various protection mechanisms at play, how they work, and how to use them. In addition to encryption and information rights management, we see how encrypted messages can be customized with an organization’s branding and what additional functionality comes with custom branding.

Learning Objectives

  • Gain an overview of Microsoft 365 email encryption
  • Learn how to implement email encryption
  • Understand advanced message encryption

Intended Audience

This course is intended for students working towards the SC-400: Microsoft Information Protection Administrator exam or those students wanting to learn about Microsoft 365 email message encryption.


There are no mandatory prerequisites required to take this course, but an understanding of how email works and previous experience with PowerShell would be beneficial.


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.

About the Author
Learning Paths

Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a  Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.