New IRM Option to Control Decryption of Attachments of Encrypted Messages


Encrypt Only

In March 2018, Microsoft introduced the ability for Office 365 users to use the Encrypt Only feature to encrypt email sent from Outlook 2016 and OWA. Part of Office 365 Message Encryption and included in the Office 365 E3 and E5 plans (also available as an add-on), the idea behind the Encrypt Only feature is to avoid the need for people to use S/MIME to protect their outbound email. Messages encrypted by Office 365 can be read by recipients in any email service.

Introducing DecryptAttachmentForEncryptOnly

On August 23, Microsoft updated the Information Rights Management (IRM) configuration for tenants with a new setting called DecryptAttachmentForEncryptOnly. The new setting controls if Exchange Online decrypts attachments of messages protected with Encrypt Only when opened by authenticated users.

The default is False, meaning that attachments remain protected when downloaded (Figure 1). In other words, the sender exerts control over the file.

Encrypted Word Attachment
Figure 1: Attachments remain encrypted

Change the setting to True if you want recipients to be able to do whatever they want after they download attachments. To update, connect to Exchange Online with PowerShell and run the command:

Set-IRMConfiguration -DecryptAttachmentForEncryptOnly $True

Changes made to the IRM configuration are effective tenant-wide immediately.

No Online Edits for OWA

If you opt for unrestricted access, be aware that users cannot perform an online edit of an Office attachment protected by Encrypt Only with OWA. You’d expect that this would be the case, but OWA preserves encryption unless an attachment is downloaded. So if you click Preview for an Office attachment and then click Edit and reply, you’ll see:


The workaround is to download any attachment you want to edit as this forces Exchange Online to decrypt the file.

The DecryptAttachmentFromPortal Setting

The DecryptAttachmentFromPortal setting was introduced some time ago to allow recipients who don’t have an Azure Active Directory account (services such as Gmail, Yahoo!, and Yandex) to access encrypted message attachments. This setting is now deprecated in favor of DecryptAttachmentForEncryptOnly.

No Other IRM Templates Affected

The DecryptAttachmentForEncryptOnly setting only applies to attachments for messages sent using the Encrypt Only feature. They don’t apply to attachments protected with any other rights management template.

One Configuration

The new setting allows tenants to control how recipients interact with attachments protected by the Encrypt Only feature. It’s worth emphasizing that the IRM configuration applies tenant-wide and you cannot change a setting for one message, one sender, or a recipient. Once you change a setting, it applies for all messages.

For more information about protecting email and documents, see Chapter 24 of Office 365 for IT Pros.

5 Replies to “New IRM Option to Control Decryption of Attachments of Encrypted Messages”

  1. Hi,

    I am sorry to post it here but am desperate to know the answer. If we migrated data from one tenant to another tenant, is it possible to recover the files that are protected using rights management ? Please let me know if this is possible to restore the data/decrypt/remove the protection.

    Note – Data migrated in 2022. Users were able to access the files in the new tenant as well after 9 months of migration and now the tenant almost has no data or licenses. MS support isn’t helping as they are going in wrong direction.

    1. You haven’t given enough information to make an intelligent comment about the situation. Is the affected set files only or files and email? Are the items protected by sensitivity labels? What rights are defined in the labels (presumably enough to allow continued access for users in the new tenant)?

      Sensitivity labels can be removed by:

      Owners (and co-owners).
      From files by Administrators using the SharePoint Online Unlock-SPOSensitivityLabelEncryptedFile cmdlet
      From files by administrators using the Set-AIPFileLabel cmdlet
      From email by exporting protected messages using a content search

      I don’t know what you have tried or investigated, nor do I know what advice Microsoft Support has given. This is a complex situation that needs full understanding of the complete situation to make intelligent observations, and I hesitate to say much more here.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.