Microsoft Purview Message Encryption: What Actually Works in Production

Three months into a financial-services engagement, we got a P1 ticket: encrypted emails sent to a partner's Proofpoint gateway were arriving as blank HTML wrappers. The partner could see a "Read the message" button, but the one-time passcode never reached their inbox. The root cause was a transport rule collision between the client's legacy Office 365 Message Encryption config and a new sensitivity label policy we had pushed the week before. Both fired on the same messages, and the newer Purview stack won, but the portal settings for external recipient experience had not been updated to match.

That situation is common. Microsoft Purview Message Encryption is the current name for what started as OME (Office 365 Message Encryption), itself built on Azure Rights Management. The rebrand brought tighter label integration, revocation, and expiry controls. It also introduced several new ways for things to go wrong when an org is mid-migration from the older stack.

What Purview Message Encryption Actually Is

At its core, Purview Message Encryption is a wrapper around Azure RMS that lets Exchange Online encrypt outbound messages and decrypt inbound ones, with no certificate infrastructure required on the sender side. Recipients outside Microsoft 365 get one of two experiences: a Microsoft Account login, or a one-time passcode (OTP) delivered to the same address. Which one fires depends on the OME configuration object attached to the transport rule.

The key shift with Purview is that protection can now originate from a sensitivity label rather than only from a transport rule. A label with encryption defined (using the "Let me assign permissions" or pre-assigned rights options) calls into the same RMS pipeline. This means you can have label-applied encryption from Outlook desktop, OWA, or the Purview auto-labeling engine, all with consistent policy.

There are two template types in play: the default OME Configuration object and any custom configurations you create. The custom config controls branding, the portal URL, OTP behavior, and whether external recipients can use social identity providers. Most orgs never touch the defaults, which is where the trouble starts.

Setting Up a Custom OME Configuration

Every production tenant should have at least one named OME configuration. The default object does not give you per-partner control, and you cannot A/B the recipient experience without named configs.

# Connect to Exchange Online PowerShell first
Connect-ExchangeOnline -UserPrincipalName [email protected]

# Create a named config for partner-facing encrypted mail
New-OMEConfiguration `
  -Identity "PartnerEncrypted" `
  -OTPEnabled $true `
  -SocialIdSignIn $false `
  -ExternalMailExpiryInDays 14 `
  -IntroductionText "This message is protected by Contoso security policy." `
  -EmailText "You have received an encrypted message from Contoso." `
  -PortalText "Contoso Secure Message Portal"

# Attach it to a transport rule scoped to partner domain
New-TransportRule `
  -Name "Encrypt to partner.com" `
  -RecipientDomainIs "partner.com" `
  -ApplyOMEConfiguration "PartnerEncrypted" `
  -SentToScope NotInOrganization

# Verify the config rendered correctly
Get-OMEConfiguration -Identity "PartnerEncrypted" | Select-Object *

The -SocialIdSignIn $false matters for regulated industries. Google and Facebook auth satisfy the "authenticated recipient" check on paper, but most compliance officers want OTP-only for financial or health data. Set it explicitly rather than relying on defaults.

External expiry is a feature people overlook. Setting -ExternalMailExpiryInDays 14 means the message portal link stops resolving after two weeks. That is useful for time-sensitive notifications. It is not the same as rights revocation, which requires Azure AD P1 and a separate cmdlet against the RMS protection applied to the message.

Sensitivity Labels and the Encryption Hand-Off

When a sensitivity label applies encryption, the label policy specifies the rights template or custom permissions. The label fires before Exchange transport rules in the pipeline. This creates a sequencing issue: if your label already marks a message with "Encrypt-Only," and a transport rule then tries to apply a different OME configuration, the behavior depends on whether the rule is set to override label encryption or skip already-protected content.

Check the rule's SetHeaderName/SetHeaderValue and confirm the rule uses -ApplyOMEConfiguration rather than trying to apply a separate rights template. Two protection actions on the same message often result in the second one silently losing, and the recipient gets whichever wrapper the first action set, which may have different branding and OTP settings than intended.

For auto-labeling scenarios, test with the Purview simulation mode before going live. Auto-labeling policies for Exchange run on the service side, and the volume can be surprising if the classifier matches broad patterns.

Auditing Who Is Decrypting What

Purview writes protection and access events to the Unified Audit Log. The event schema under ProtectionCenter captures both SensitivityLabelApplied and the RMS-side RMSDecryptAttempt actions. Pull these in Microsoft Sentinel with KQL:

OfficeActivity
| where TimeGenerated > ago(7d)
| where RecordType == "AipSensitivityLabelAction"
    or RecordType == "AipProtectionAction"
| extend LabelName = tostring(parse_json(tostring(parse_json(ExtendedProperties)["SensitivityLabelEventData"]))["SensitivityLabelName"])
| extend ActionType = tostring(parse_json(tostring(parse_json(ExtendedProperties)["SensitivityLabelEventData"]))["ActionSource"])
| summarize count() by UserId, LabelName, Operation, bin(TimeGenerated, 1h)
| order by count_ desc

For the RMS access events specifically, look at the MicrosoftGraphActivityLogs table if you have that connector, or the AzureDiagnostics table under AIPAuditLogs_CL if you built a custom Log Analytics workspace sink. The native Purview Activity Explorer in the compliance portal is useful for ad-hoc queries, but it caps export at 10,000 rows and has a 30-day retention window. For anything longer, the Sentinel pipeline is the durable path. We have a detection engineering pattern for this at /services/detection.

Troubleshooting the Blank-Wrapper Problem

The blank HTML wrapper is almost always one of three things: a relay hop stripping the x-ms-exchange-organization-* headers that tell the receiving gateway the message is OME-wrapped, a Proofpoint or Mimecast policy decrypting and re-encrypting the message before final delivery (which breaks the portal link), or a misconfigured SPF/DKIM chain that causes the OTP email to land in spam before the recipient sees it.

For relay-strip issues: check the message trace in Exchange Admin Center and look for the X-MS-Exchange-OME-Sender header at each hop. If it disappears between the client's outbound connector and the partner gateway, the connector is stripping non-standard headers. Set the outbound connector to preserve headers or whitelist the OME headers explicitly.

For gateway re-encryption: the partner needs to configure a bypass for your sending IPs or domains before the protection unwrap/rewrap happens. This is a partner-side change, but you need to document what to ask for. The correct ask is "exclude our domain from content inspection and re-signing before final delivery to end users."

For OTP in spam: add the [email protected] sender address to the partner's safe-sender list. Microsoft sends the OTP from that address and it triggers aggressive spam filters because it sends at high volume across all tenants.

Revocation and Expiry in Practice

Revoking a sent message requires the message to have been encrypted using a label that calls the RMS service with an online key, not an offline key. Offline keys cache the decryption material in the email client, and revocation has no effect on already-cached messages. For regulated data, configure labels to use online-only key mode, which forces a RMS service check on every open. The trade-off is that offline access breaks entirely, which matters for users who work on aircraft.

Expiry is simpler and does not require online keys. The OME portal link stops resolving after the configured window. The message body in the email itself becomes unreadable. For internal recipients inside the org, the behavior depends on the rights template attached to the label; the OME portal expiry only applies to the external recipient experience.

Next Steps

If you are mid-migration from classic OME, building a sensitivity label taxonomy, or seeing delivery failures on encrypted mail to external partners, contact us and we will scope a remediation or greenfield design.