Why Your Encrypted Emails Won't Open and How to Fix It

What's Actually Happening

The rpmsg file is a container. It's not the problem. What breaks is what happens when Outlook tries to unwrap it.

When a recipient's Outlook desktop opens an rpmsg, it calls the Azure Rights Management endpoint in the sender's tenant to get a decryption key. That call is authenticated, which means it is subject to the sender's Conditional Access policies.

The service being hit is Microsoft Rights Management Services, App ID 00000012-0000-0000-c000-000000000000. It is a cloud app like any other in CA policy scope. "All cloud apps" means this one too.

The Broken Flow

What Outlook Desktop Actually Does

Excluding AIP from the MFA policy does not weaken security. The external recipient authenticated to their own identity provider to reach this point. The RMS token request is a downstream call inside an already-authenticated Outlook session. A second MFA challenge on a service call the user cannot see or control is not a security control. It is a broken user experience with no compensating value.

Any client that goes through the OME portal hits this. The portal calls back to the sender's tenant to get a decryption key regardless of which browser or device the recipient uses. The rpmsg format is not the problem. The endpoint call is.

What Needs to Change in the CA Policy

Two options. Option A is the surgical fix: it leaves everything else unchanged.

# CA policy after fix
Policy Name  : CA002 - Require MFA - All Users
Users        : All users
Exclude Users: Azure-Breakglass, CA-Breakglass
Cloud Apps   : All cloud apps
Exclude Apps : Microsoft Rights Management Services
               # App ID: 00000012-0000-0000-c000-000000000000
Grant        : Require MFA

Assignments → Users → Include : All users
Assignments → Users → Exclude : Guest and external users
                                   Azure-Breakglass
                                   CA-Breakglass

Step-by-Step Walkthrough

The failure state is what makes the fix meaningful.

Phase 1: Show the Break

1

CA policy: no Rights Management exclusion

The Require MFA All Users policy targets all cloud apps with no exclusions. Microsoft Rights Management Services is in scope. Any authenticated call to the RMS endpoint from an external recipient will be evaluated against this policy.

Entra admin center → Protection → Conditional Access → Policies → CA002 - Require MFA - All Users

CA policy: only Microsoft Intune Enrollment excluded: no Rights Management entry

2

Encrypted email: external recipient

The email is sent with the Confidential - Third Parties sensitivity label applied. This label uses user-defined permissions. The sender explicitly grants the external recipient access at send time. That grant is what puts the recipient through the RMS token acquisition flow, and where the CA policy intercepts it.

Encrypted email arrives: rpmsg attachment, recipient cannot open it without the OME portal, recipient cannot open it without the OME portal

No preview available: external mail client has no way to decrypt the rpmsg directly

3

Decryption fails: CA blocks the RMS token

The recipient's client calls the sender's RMS endpoint to acquire a use license. CA evaluates that request, requires MFA, and the external recipient cannot satisfy the challenge. The token is denied. The sending tenant logs nothing. The failure is only visible to the recipient.

4

Native Outlook: message breaks there too

The message also fails when opened natively in Outlook on the Inforcer tenant. No OME portal involved. Outlook desktop on the receiving side calls back to the sender's RMS endpoint directly, hits the same CA policy, and the decryption key is denied. The failure is not limited to the OME portal path.

"Sorry, we can't display your message right now": CA blocked the RMS token

Phase 2: Explain Why

5

Microsoft Rights Management Services is a cloud app

Microsoft Rights Management Services appears in Enterprise Applications like any other cloud app. "All cloud apps" in the CA policy includes it, which is why the MFA requirement fires when an external recipient's client tries to acquire a decryption use license.

Entra admin center → Applications → Enterprise applications → Search: Microsoft Rights Management

6

Explain what Outlook desktop actually does

When Outlook desktop opens an rpmsg, it calls aadrm.com to get a decryption use license. That call is authenticated. CA evaluates it. The external recipient has no MFA registered in your tenant, so the token is denied and the key is never issued. OWA decrypts server-side; the browser never touches aadrm.com.

Phase 3: Apply the Fix and Verify

7

Add AIP to the excluded cloud apps list

Open the MFA for All Users policy. Under Cloud apps, switch to the Exclude tab. Add Microsoft Rights Management Services. Save the policy. The change takes effect within minutes.

CA policy → Cloud apps or actions → Exclude → Select apps → search "Microsoft Rights Management" → Select → Save

Microsoft Rights Management Services added to excluded cloud apps: 2 resources now excluded

8

With the exclusion in place: decryption succeeds

The same encrypted email, the same recipient, the same label. With Microsoft Rights Management Services excluded from the MFA policy, the RMS token request goes through. The encryption has not changed. The message is still protected and the rights are still enforced. MFA still applies to every other cloud app.

Email resent with exclusion in place: rpmsg arrives the same way

OME portal now prompts for one-time passcode: decryption proceeds

9

Sign-in logs confirm the fix

The sign-in logs show a successful authentication entry for the Microsoft Rights Management Services app. Before the exclusion, the same app would have shown an interrupted or failed entry at the same step, the token request blocked by the MFA requirement.

Entra admin center → Monitoring → Sign-in logs → filter App = Microsoft Rights Management Services

Message opens: encrypted email decrypted successfully after CA exclusion

The Non-Technical Version

The protection from the sensitivity label is not weakened by this change. The email is still encrypted with Azure RMS. The recipient still has to authenticate to open it. The label still controls who can read, copy, forward, or print. What changes is that the service call Outlook desktop makes to get the decryption key is no longer interrupted by a secondary MFA challenge that the recipient has no way to complete.

Add AIP Exclusion to Your Baseline CA Policy

This exclusion should be standard in any baseline that deploys both sensitivity label encryption and MFA for all users. Without it, every customer who sends a labeled email externally will hit this. Add it to your CA baseline documentation and script templates.

# PowerShell: add AIP exclusion to existing policy
# Requires: Microsoft.Graph module

$aipAppId = "00000012-0000-0000-c000-000000000000"

# Get the Rights Management service principal object ID
$aipSP = Get-MgServicePrincipal -Filter "AppId eq '$aipAppId'"

# Get your MFA policy (update -PolicyId to your actual policy GUID)
$policy = Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId "<your-policy-guid>"

# Build the updated excluded apps list
$currentExcludes = $policy.Conditions.Applications.ExcludeApplications
$updatedExcludes  = $currentExcludes + $aipSP.AppId

# Update the policy
Update-MgIdentityConditionalAccessPolicy `
  -ConditionalAccessPolicyId $policy.Id `
  -Conditions @{
    Applications = @{
      IncludeApplications = $policy.Conditions.Applications.IncludeApplications
      ExcludeApplications = $updatedExcludes
    }
  }

Key Facts