RPMSG File Documentation

Summary

An .rpmsg file (almost always message.rpmsg) is a Restricted Permission Message: the encrypted, rights-protected payload Microsoft Outlook attaches to an e-mail when the sender applies Information Rights Management. Its MIME type is application/x-microsoft-rpmsg-message. You cannot open the attachment with a normal program — it decrypts only for the intended recipient. Open the e-mail in Outlook signed in as that recipient, or use the “Read the message” portal link for Gmail and Yahoo accounts.

Technical details

FeatureValue
Full nameRestricted Permission Message
File extension.rpmsg (usually message.rpmsg)
MIME typeapplication/x-microsoft-rpmsg-message
Format typeEncrypted, compressed e-mail container (binary)
DeveloperMicrosoft
Introduced2003 (Windows RMS / Outlook 2003 IRM)
Now part ofMicrosoft Purview Message Encryption (ex Azure RMS)
Open standardNo — proprietary, not publicly documented
Byte order marker76 E8 04 60 at offset 0 (observed, not official)
Compressionzlib / DEFLATE chunks
Decompressed payloadOLE Compound File (D0 CF 11 E0)
Body format insideRTF / HTML message body plus attachments
Key managementPer-recipient use-license from Microsoft RMS service
Enforced rightsReply, forward, print, copy (per policy)
Opens inOutlook (desktop/web/mobile), Purview portal
ConvertibleNo — content is per-recipient encrypted
Related extensions.msg, .eml, .pfile
Specificationlearn.microsoft.com/purview/email-encryption
File signature (magic bytes)
76 E8 04 60

Offset 0, 4 bytes. This proprietary marker begins the rpmsg stream; it is not documented by Microsoft and is known only from open-source parsers, so treat it as observed rather than official. After the marker come zlib/DEFLATE-compressed chunks. Decompressing them yields an OLE Compound File — the same D0 CF 11 E0 A1 B1 1A E1 container used by legacy MSG files — whose storages hold the protected RTF/HTML body, any attachments, and the publishing license (the encrypted recipient list and granted rights). None of that inner content is readable without a use-license issued per recipient by Microsoft’s rights-management service, so the signature identifies the container but the payload stays encrypted.

What is an rpmsg file?

An .rpmsg file, almost always named message.rpmsg, is the encrypted container Microsoft Outlook attaches to an e-mail when the sender applies Information Rights Management (IRM) — options such as “Do Not Forward”, “Encrypt-Only” or a confidential sensitivity label. The name stands for Restricted Permission Message. The technology began as Windows Rights Management Services with Outlook 2003 and is now operated by Microsoft Purview Message Encryption (formerly Azure Information Protection / Azure RMS). Its MIME type is application/x-microsoft-rpmsg-message.

The file holds the real message body and attachments, compressed and encrypted; the visible e-mail around it is just a plain-text wrapper announcing that the content is protected. What makes rpmsg different from an ordinary attachment is that possessing the file is not enough to read it. Decryption keys are issued per recipient by Microsoft’s rights-management service, which checks that the signed-in account is on the sender’s recipient list before releasing a license. The format is proprietary and not publicly documented, so its internals below are drawn from observed structure and open-source parsers rather than a Microsoft specification.

The container: marker, zlib chunks and a Compound File

An rpmsg file is a small binary container built in three layers. It opens with a fixed 4-byte marker, 76 E8 04 60, that identifies the stream. Immediately after come zlib/DEFLATE-compressed chunks. Decompressing and concatenating those chunks produces an OLE Compound File — the classic Microsoft structured-storage format whose own signature is D0 CF 11 E0 A1 B1 1A E1, the same container that legacy MSG files use.

rpmsg layers:
  [ 76 E8 04 60 ]              4-byte marker
  [ zlib/DEFLATE chunks ]      compressed protected payload
        │  decompress
        ▼
  [ OLE Compound File ]        D0 CF 11 E0 ...
     ├─ message body (RTF/HTML), encrypted
     ├─ attachments, encrypted
     └─ publishing license (recipient list + rights)

Inside the Compound File, the storages hold the encrypted RTF or HTML body and any file attachments, alongside a publishing license: the encrypted description of who may open the message and what they may do with it. Reaching this layer does not reveal the message, because the body and the license are still encrypted with keys the file does not contain. The marker bytes are consistently observed by community tools but are not confirmed by Microsoft documentation, so a parser that relies on them should do so cautiously.

The publishing license and per-recipient decryption

The reason no offline tool can open an rpmsg is the rights-management key model. When the sender protects a message, Outlook contacts the RMS service and obtains a publishing license that lists the authorised recipients and the rights each is granted — reply, reply-all, forward, print, copy, and an expiry. The message body is encrypted with a content key, and that content key is itself wrapped so that only the RMS service can unwrap it.

To read the message, the recipient’s Outlook (or the web portal) sends the publishing license back to the RMS service together with proof of the signed-in identity. The service verifies that the account appears on the recipient list, then issues a use-license containing the content key and the granted rights. Only at that point can the client decrypt the body. This is why the same message.rpmsg opens instantly for the intended recipient and is inert for everyone else: the bytes are identical, but only one account can obtain the use-license. It is also why forwarding, printing or copying can be blocked — the use-license carries those permission flags and the client enforces them.

Why the attachment cannot be opened directly

Recipients using Outlook with a Microsoft 365 work or school account never interact with the .rpmsg file at all: Outlook detects the protection, fetches the use-license transparently, and shows the message as normal text. The raw attachment only becomes visible when the receiving mail client does not speak Microsoft IRM — Gmail, Yahoo or Apple Mail — which cannot request a license and so just displays the encrypted blob.

For those recipients, current Purview setups include a “Read the message” link in the e-mail body. Clicking it opens the content in a browser portal (Outlook on the web or the Purview encrypted-message portal) after verifying identity with a one-time passcode sent to the address or a Google/Microsoft sign-in. That portal is the only route for non-Microsoft recipients; the attachment itself remains undecryptable. Older tenants that sent raw rpmsg without the portal link are the main source of “I received message.rpmsg and can’t open it” complaints, and the fix there is to ask the sender to re-send using Purview Message Encryption or without restricted permissions.

Why rpmsg cannot be converted

Tools advertising rpmsg-to-PDF, rpmsg-to-EML or rpmsg-to-PST conversion cannot deliver what they imply, because the content is encrypted per recipient. There is no key inside the file to convert away from; a converter can only repackage the undecryptable blob or demand the recipient’s own credentials to do what Outlook would have done anyway. If you are the legitimate recipient and the sender’s policy permits printing, the supported path to a PDF is to open the message in Outlook and print to PDF — and if the policy is “Do Not Forward”, printing and copying are disabled by design, with no supported workaround. Recovery-vendor listings pairing rpmsg with PST or CSV are effectively meaningless for the same reason: the protected message stays encrypted no matter which mailbox store it sits in.

References