Table of Contents:
Microsoft Purview Message Encryption
In this article, we will explore how to send encrypted messages using our organizational email through Microsoft Purview Message Encryption. We will also take a deep dive into Azure Rights Management Service (RMS) and its role in this process. Additionally, we will examine publicly accessible landing pages related to external email authentication that are used within Purview Message Encryption messages.
The article includes details that aren’t directly supported by official Microsoft sources or other verified publications, due to the limited availability of public information. Some parts are derived from the relationships between Microsoft’s services and my general knowledge, with AI-generated reasoning included. Therefore, while the information may not be 100% accurate, it still provides a reasonably logical and close to accurate explanation.
Key Terminology Overview
First, we need to explain some key terms in a simple way, as we will be using them throughout the article. These terms are based on services within the Microsoft Azure stack.
Microsoft Purview is Microsoft’s unified platform for data governance, compliance, and risk management. It helps organizations discover, classify, and manage data across Microsoft 365, on-premises, and multi-cloud environments.
Microsoft Purview Message Encryption allows users to send secure, encrypted emails both inside and outside their organization. It ensures that only intended recipients can read the email content and attachments.
Azure Information Protection (AIP) is now known as Microsoft Purview Information Protection which helps classify, label, and safeguard sensitive organizational data. It can automatically or manually apply labels such as Confidential or Highly Confidential to emails and documents.
Azure Rights Management Service RMS is a cloud-based service that provides encryption and rights management for files and emails. It protects data by controlling who can access, edit, copy, or forward content.
The Microsoft Purview Information Protection labels integrate with Azure RMS to enforce encryption and access restrictions. This ensures compliance with data protection regulations like GDPR or HIPAA. So in short, Purview handles the policies and labeling, and RMS enforces the encryption and permissions.
Microsoft 365 Message Encryption (OME) was the legacy email‑encryption solution that allowed sending protected emails but had limited rights‑management features and a less seamless experience for external recipients.
Microsoft Purview Message Encryption is the modern evolution, fully integrated into the Purview compliance ecosystem, offering enhanced templates, flexible policies, and stronger rights controls. Purview supports both internal and external recipients with a smoother, more consistent experience. OME has been deprecated, and organizations are encouraged to use Purview Message Encryption for current and future email protection.
Microsoft Purview Message Encryption Architecture Overview
What are we protecting and why
Organizations often exchange sensitive information via email (financial data, contracts, personal info, etc.). Purview Message Encryption lets you send encrypted email messages inside and outside your organization, so only the intended recipient(s) can view the content, Under the hood, the service uses Azure RMS technology (encryption engine, rights management, policy enforcement) to protect the message.
Activation and prerequisites
Before you can use Purview Message Encryption, your organization’s tenant must have the Azure RMS functionality activated (often automatically with eligible Microsoft 365 plans).
As an administrator you can check via PowerShell whether the parameter AzureRMSLicensingEnabled is set to true, then Mail flow rules can be defined so that certain conditions (e.g., external recipient, keywords detected) trigger encryption automatically.
encryption process works, detailing the steps involved from both the sender side and the receiver side.Sender to encryption
The sender (let’s call her Alice) composes an email in Outlook or Outlook on the web and chooses to encrypt it (either manually via Encrypt or via a policy/sensitivity label).
Behind the scenes, when Alice sends the message, Purview/Azure RMS generates a symmetric content key (using AES) that will encrypt the message body. This content key is unique for that message.
At the same time, a policy is defined indicating who can open the message, what they can do (read, copy, forward, print or not), and possibly an expiration date.
The content key must be protected so that only authorized recipients can use it. Thus, the content key is encrypted (wrapped) using the organization’s RSA tenant root key (the tenant key) in Azure RMS. That tenant key may be Microsoft‑managed or customer‑managed (BYOK).
The encrypted content key along with the policy metadata are embedded into the email. The message body is encrypted with the content key and that encrypted content + policy travel together. This ensures that wherever the message goes, the access controls are tied to it.
The compound message (encrypted content + wrapped key + policy) is sent via normal email channels (Outlook, Gmail, etc.). Because of the encryption, even if intercepted, the content cannot be read.
Authentication & key release
The recipient (let’s call him Bob) receives the encrypted message. His email client (Outlook desktop, web or other) recognizes it is protected by Purview Message Encryption.
Depending on whether Bob is internal (same tenant) or external (another organization or consumer account), authentication differs, For the Internal recipient, Bob authenticates via Microsoft Entra ID (Azure AD) using his corporate credentials, and for the External recipient, Bob may be prompted to use a one‑time passcode (OTP) or sign in with a Microsoft account or other supported identity to access the encrypted message portal.
Once authenticated, Bob’s client sends the encrypted content key + policy + his identity to the Azure RMS service. The service checks the policy, Is Bob allowed to access this message? What are his rights?
If Bob is authorized, the Azure RMS service uses the tenant RSA key (in the cloud) to decrypt the wrapped content key. The tenant key never leaves Azure’s secure service.
After decryption, a usable version of the content key is sent temporarily to Bob’s client in memory. With that key, Bob’s client decrypts the message body.
Bob reads the message. The client enforces the rights defined in the policy e.g., read only, no forward, cannot copy etc. The message remains protected at rest and in transit even after opening.
No agent need on the device
Because Purview Message Encryption is cloud‑based, the heavy lifting (key generation, wrapping, policy enforcement, decryption) is handled by Microsoft’s service rather than a local agent, Users simply click Encrypt in Outlook or the system triggers encryption via mail flow rules. They don’t need to install an agent. Recipients open encrypted messages via Outlook or other messaging portal.
Microsoft Outlook Encrypted Message Links Appear in Search Engines
The recipient receives a unique link, usually labeled View your encrypted message, pointing to a Microsoft-hosted portal such as https://outlook.office365.com/encryption/retrieve?itemID=.... This link contains a message ID identifying the encrypted content and is intended for a specific recipient. Sometimes, the encrypted message is delivered as an .rpmsg file (Restricted Permission Message), which can only be opened using Microsoft credentials or a one-time passcode.
Despite this security, links to Microsoft’s encrypted message portal sometimes appear in search engine results. This occurs not because the Microsoft pages are intentionally public, but because external websites or public portals have posted the unique links. When search engine crawlers visit these public pages, they encounter the Microsoft URL and follow it to the portal. The portal contains readable HTML text, such as the sender’s email and instructions to sign in, which search engines index. However, the indexing only captures metadata and portal text, the encrypted content of the email remains inaccessible without proper authentication.
Understanding Microsoft Outlook Encrypted Message URLs and Their Metadata
https://outlook.office365.com/encryption/Login?itemID=E4E_M_6847b5a7-8d30-494c-be08-21d02b90f811&recipientemailaddress=xxxx@gmail.co&senderemailaddress=NoReply_xxxx@xxxx.com&st=Google&anchorMailbox=SystemMailbox{xxxx-xxxx-xxxx-xxxx-xxxx}@xxxx.onmicrosoft.com&cfmRecipient=SystemMailbox{xxxx-xxxx-xxxx-xxxx-xxxx}@xxxx.onmicrosoft.com&e4e_sdata=LQv9dMkfhfRg+r3/WsCgN67cdeHCsmRZdUOViDWcOMj5J14nBobGO7eF2Tr8nzy97S02W5q1vMt6+OoKfsF0cOvndGVhtLIRsilWkfb/tt8pOEtMer6MRDihINhtClmvhLvaWEF5WUP7xJciU+njzFjL/UwK9QaIlGeYR0oZuAUmSS6AlprcpmZTHuW7522nOP6tsLBTi5wuQ99UbBJq4TJCQEghxPFMzGXgIM9FhwIXuyYELe7KQqiEMhZt1mCBLBnuwNmmZ+0IAdm7Y8D0bjYYu9Q7He9HI66+et3hCrvr5BKQ/54kQpa+U/KWqN6yDJTchtRpWwjBay99lcLfTA==&omeVersion=V2&otpSSI=FalseThis Outlook encryption URL contains parameters that identify the specific encrypted message (itemID=E4E_M_6847b5a7-8d30-494c-xxxx-xxxxxxxxxx), specify the sender (senderemailaddress=NoReply_xxxx@xxxx.com) and recipient (recipientemailaddress=xxxx@gmail.com), and indicate the authentication method (st=Google).
It also references internal mailboxes used to process the message securely (anchorMailbox=SystemMailbox{xxxx-xxxx-xxxx-xxxx-xxxx}@xxxx.onmicrosoft.com and cfmRecipient=SystemMailbox{xxxx-xxxx-xxxx-xxxx-xxxx}@xxxx.onmicrosoft.com), includes the encrypted session data (e4e_sdata=LQv9dMkfhfRg+r3/WsCgN67cdeHCsmRZdUOViDWcOMj5J14nBobGO7eF2Tr8nzy97S02W5q1vMt6+OoKfsF0cOvndGVhtLIRsilWkfb/tt8pOEtMer6MRDihINhtClmvhLvaWEF5WUP7xJciU+njzFjL/UwK9QaIlGeYR0oZuAUmSS6AlprcpmZTHuW7522nOP6tsLBTi5wuQ99UbBJq4TJCQEghxPFMzGXgIM9FhwIXuyYELe7KQqiEMhZt1mCBLBnuwNmmZ+0IAdm7Y8D0bjYYu9Q7He9HI66+et3hCrvr5BKQ/54kQpa+U/KWqN6yDJTchtRpWwjBay99lcLfTA==), specifies the version of Message Encryption in use (omeVersion=V2), and indicates that no one-time passcode is required (otpSSI=False).
URL: https://outlook.office365.com/encryption/Login?
ID: itemID=E4E_M_6847b5a7-8d30-494c-xxxx-xxxxxxxxxx&
Recipient: recipientemailaddress=xxxx@gmail.co&
Sender: senderemailaddress=NoReply_xxxx@xxxx.com&
Login Type: st=Google&
Mailboxes: anchorMailbox=SystemMailbox{xxxx-xxxx-xxxx-xxxx-xxxx}@xxxx.onmicrosoft.com&
Mailboxes: cfmRecipient=SystemMailbox{xxxx-xxxx-xxxx-xxxx-xxxx}@xxxx.onmicrosoft.com&
Session Data: e4e_sdata=LQv9dMkfhfRg+r3/WsCgN67cdeHCsmRZdUOViDWcOMj5J14nBobGO7eF2Tr8nzy97S02W5q1vMt6+OoKfsF0cOvndGVhtLIRsilWkfb/tt8pOEtMer6MRDihINhtClmvhLvaWEF5WUP7xJciU+njzFjL/UwK9QaIlGeYR0oZuAUmSS6AlprcpmZTHuW7522nOP6tsLBTi5wuQ99UbBJq4TJCQEghxPFMzGXgIM9FhwIXuyYELe7KQqiEMhZt1mCBLBnuwNmmZ+0IAdm7Y8D0bjYYu9Q7He9HI66+et3hCrvr5BKQ/54kQpa+U/KWqN6yDJTchtRpWwjBay99lcLfTA==&
Version: omeVersion=V2&
Passcode: otpSSI=FalseHow Metadata in Microsoft Outlook Encrypted Message Links Can Reveal Sensitive Information
Using a Google dork such as site:outlook.office365.com https://outlook.office365.com/Encryption/retrieve.ashx? allows users to find Microsoft Outlook encrypted message landing pages that have been exposed publicly. Accessing one of these pages for example, a URL like https://outlook.office365.com/encryption/Login?itemID=E4E_M_b0cdba9b-c89d-4719-ba10-fa80480c11f3&recipientemailaddress=...&senderemailaddress=Rxxxx.Rxxxx@sxxxx.com&st=OTP... reveals metadata embedded within the link. While the message content itself remains encrypted and inaccessible without authentication, information such as the sender’s name, email address, and associated domain can be inferred directly from the URL.
For instance, one of the links exposes the name Rxxxx Rxxxx and the domain sxxxx.com. By performing a simple web search for this combination, it is possible to locate public profiles, such as https://www.cience.com/profile/rxxxx-rxxxx/872xxxx, which provide additional details including the individual’s full name and the organization they are associated with.
Security Implications of Metadata in Encrypted Message URLs
This connection demonstrates that metadata in encrypted message URLs can inadvertently reveal relationships between senders and recipients, as well as the companies or organizations involved. In a broader context, repeated exposure of such links on public websites could unintentionally disclose company relationships, internal hierarchies, or other sensitive organizational connections, even though the encrypted content itself remains secure.
Using the information we have and by accessing the website, we can view details about where the person works, the overall company structure and working relationships, as well as the LinkedIn profile.
Let’s Connect and Keep Learning!
So, that wraps up our article for today! I hope you learned something valuable. Don’t hesitate to connect with me on LinkedIn, and if you have any other questions, feel free to send me a DM, Don’t forget to check out the underlined resources for more information!
https://www.youtube.com/watch?v=jnMPBa-7OOQ
https://www.codetwo.com/admins-blog/encrypt-external-emails-microsoft-365/
https://learn.microsoft.com/en-us/purview/ome