How many times have you heard that email is about as secure as a postcard? That may have been true a long time ago. Technologies such as SPF, DKIM, DMARC, TLS, and MTA-STS ensure that the sender is legitimate and that communication is encrypted in transit. However, these mechanisms only protect the transport layer. They do not protect access to the actual content once the message is stored in the recipient’s inbox, forwarded, downloaded, or opened on their devices.
It is only when an email is encrypted and access-controlled using Purview Message Encryption (PME) that the content itself remains protected—regardless of where the email is stored. Obviously, this is especially important when using e-mail to send confidential content.
Purview Message Encryption is Microsoft’s modern solution for end-to-end, access-controlled email protection. It is tightly integrated with Microsoft Purview Information Protection (MIP), uses Azure Rights Management (RMS) for encryption, and supports delivery to both internal and external recipients. PME replaces the legacy Office Message Encryption (OME) technology and works across modern Outlook clients, mobile clients, and browser-based access for external users.
How PME works
To see how PME works in practice, we can create a sensitivity label and use it to send an email.
Step 1: creating a sensitivity label for protected e-mail
Let’s start by creating a label called “Protected email”. This label is only exposed to users in Outlook and instructs the client to encrypt the message using RMS.
We sign in as a Purview administrator to Microsoft Purview, open the Information Protection solution, and create a new sensitivity label:
We then select emails as the scope for the label:
Next, we configure access control for the label:
We choose “Let users assign permissions when they apply the label” and select “Encrypt only”:
Important: “Encrypt only” allows recipients to perform certain actions, such as replying to or forwarding the email, while “Do Not Forward” blocks forwarding, printing, and similar actions. Both options enable PME and ensure that the content is protected by RMS.
Finally, we publish the sensitivity label to users. We grap a cup of americano while we wait for the label to be pushed out to Outlook.
Step 2: Sender sends a protected email
When the label is visible in Outlook, we can create a new email, select the label, write the content, and send the email to an external recipient. At the moment the email is sent, it is encrypted using RMS. Behind the scenes, the following happens:
- The email is encrypted locally in Outlook
- The RMS policy is embedded in the email object
- The recipient list becomes part of the access rules
- Only identities approved by RMS can obtain a usage license for the content
- The protection follows the email wherever it goes
Step 3: Recipient opens the protected email
When the recipient does not belong to the sender’s tenant, PME handles validation through outlook.office.com. External recipients can open the email by authenticating using a Microsoft account, another email identity, or a one-time passcode (OTP).
After authentication, PME checks whether the authenticated identity is included in the RMS policy for the message. If it is not, the recipient cannot access the content—even if they have received the email itself. It is important to note that forwarding does not grant access unless the forwarded recipient is also explicitly authorized in the access rules embedded in the email.
When to use PME — and when not to
As we can see, PME adds value by enforcing access control and encryption at the content level. Unlike transport-layer security, PME ensures that the email content itself remains protected regardless of where the message is stored, forwarded, or accessed. Access is evaluated by RMS, which means that only authorized identities can read or interact with the content, and usage rights can be enforced consistently across platforms.
PME is well suited for scenarios such as:
- Sending confidential information to internal or external recipients
- Ensuring that sensitive emails remain protected even if forwarded
- Enforcing usage restrictions, such as blocking forwarding, copying, or printing
- Protecting email content accessed from unmanaged devices or external environments
- Communicating sensitive context or instructions that should not persist outside the message
In these scenarios, PME provides strong, reliable protection with minimal effort for the sender and a controlled experience for the recipient.
However, PME is not suitable for all scenarios.
PME is not designed to support collaboration or document-centric workflows. It should not be used when the primary goal is to enable recipients to edit, review, or co-author documents.
PME is not well suited for scenarios such as:
- Sending documents that recipients are expected to edit, such as contracts or draft agreements
- Collaborative review processes involving multiple revisions or contributors
- Workflows that rely on version history, co-authoring, or long-term document storage
- Scenarios where recipients must freely save, modify, and redistribute attachments
- Situations where users rely on non-Microsoft email or document clients
While attachments sent with a sensitivity label configured as “Encrypt only” may, in some cases, be opened and edited by recipients, the experience depends on client support and authentication context. Attachments opened directly in Outlook benefit from an existing RMS session. Once a protected document is saved locally and opened in an application such as Word, access must be revalidated. For external recipients, this often results in additional authentication prompts and a fragmented user experience.
In my opinion, labels configured with “Do Not Forward” are generally unsuitable for collaboration scenarios. These labels are intended for read-only communication.
For scenarios that involve collaboration, review, or document editing, best practice is to use a document platform such as SharePoint or OneDrive. These platforms are designed for collaborative workflows, version control, and fine-grained permission management, while still supporting sensitivity labels and RMS-based protection. In these cases, PME should be used to protect the email itself, providing secure context and instructions, while the document platform manages the document lifecycle.
True content-level protection is achieved when access and usage rights are enforced by RMS — not by how the email is sent, stored, or forwarded.
