Restricting Confidential emails for Delegated Users

When users are granted delegated access to another user’s Exchange mailbox—such as an executive assistant managing a CEO’s inbox—it may be necessary to restrict the delegate’s visibility of confidential messages to maintain privacy and compliance. This was a recent request from a customer.

Use-case scenario: a corporate merger project is underway. All email correspondence among the executive team is on a “need to know” basis and should not be viewed by anyone outside of the team, including any mailbox delegates.

Check out this link from Microsoft to learn how to assign a delegated user to a mailbox as well as this link to understand the different permission levels allowed. In this post, I’m assuming the delegated user has been assigned the Full Access permission level to another user’s mailbox. 

Terminology

For the remainder of this post I’ll use the term delegate user to mean the person that is assigned as a delegate with Full Access permission to a principal user’s mailbox. I’ll use the term principal user to mean the mailbox owner that has assigned a delegate user to help manage their mailbox. For example:

• • Delegate user is the executive assistant
  • Principal user is the executive

Note: the process I’m about to share is a “sledgehammer”. It will prevent the delegate user from accessing ANY encrypted email in the principal user’s mailbox which may have other undesirable consequences.

The problem

Since the delegate user has Full Access permission to the principal user’s mailbox, the delegate user can open all emails, including any that have been encrypted for the principal user. The Full Access permission level allows the delegate user to do everything that their principal user can do, including viewing all confidential and encrypted email.

Can we stop this from happening? Yes we can!

There are 2 steps required to block a delegate user from reading emails encrypted for the principal user:

• Step 1: Business users must apply encryption when sending confidential emails to principal users 
• Step 2: Run PowerShell to ensure delegate users are blocked from viewing their principal users’ encrypted emails

Let’s dig in.

Step 1: Business users must apply encryption when sending confidential emails to principal users

Nothing new here for business users sending confidential emails. Applying encryption is a critical step to ensure the right access restrictions are given to all email recipients whether they have a delegate user or not. With delegate users in the mix, it’s even more important than ever!

Ensuring that any user who sends confidential emails understands both how to apply encryption and the different encryption options is important. This should be part of an organization’s holistic security awareness training.

Encryption options

If a confidential email is to be sent, the sender will need to remember to apply the appropriate encryption option before sending (yes, this can be automatically applied, but for this post I’m assuming the encryption will be applied manually by the sender).

To protect confidential emails in Exchange, there are several options for the sender in Microsoft today:

• Select one of the built-in Outlook encryption options (Encrypt, Do No Forward)
• Select an encrypting sensitivity label
• Apply S/MIME to the email and assign a confidentiality level (requires valid certificates for recipients)

I’ll be focusing on the first 2 options above for this post because those are the options used by my customers. Both options use the Azure Rights Management service in Microsoft 365 to rights protect an email (makes it encrypted) defining who has access and what they can do with it once received.

Microsoft reference: What is Azure Rights Management?

Built-in Outlook encryption options: The email composer could select one of the built-in Outlook encryption templates, Encrypt or Do Not Forward, to restrict email access to the users explicitly specified on the To, CC, or BCC fields of the email.

Logic dictates that the Do Not Forward encryption option may be best in this scenario to restrict the distribution of the email by the principal user.

Encrypting sensitivity label option: The email composer could select a sensitivity label in Outlook from the list of sensitivity labels published to them. Whether sensitivity labels have already been published in your organization or not will determine if this is even an option. Sensitivity labels are part of a much larger data protection initiative in an organization and outside the scope of this post. In short, if you have them, you should consider using them to protect confidential/sensitive emails. There are a few different sensitivity label configurations that would work for encrypting confidential emails:

• • An admin-defined permission sensitivity label that defines who can access it (E.g., ONLY executives) and what they can do with it (E.g., can view, cannot print). These permissions are “baked” into the label definition and the email composer cannot change that. This may be a good option if you have a sensitivity label scoped to a group of users in your org (Executives for example) and any emails with this label applied would allow Executive users to view it and prevent anyone else from viewing it. (including a delegated user if the PowerShell step is done). 
  • A user-defined permission sensitivity label that is configured with either the Do Not Forward or Encrypt-Only permission level for emails. Whomever you put in the To, CC, or BCC fields of the email will be granted that permission level. The Do Not Forward option may be best in this scenario to restrict the distribution of the email by the principal user.

As of July 2025, the encryption options available for the sender depends on the Outlook version used. This will determine which Outlook version the email sender should use for composing confidential emails:

Now that the email has been encrypted, how can we prevent the delegate user from opening the email? Remember, by default the delegate user will be able to open these encrypted emails because they have full access to the principal user’s mailbox.

This brings us to Step 2…

Step 2: Run PowerShell to ensure delegate users are blocked from opening principal users’ encrypted emails

To block delegates to emails that have been encrypted with either a sensitivity label or one of the built-in templates in the owner’s mailbox, run the Set-MailboxIRMAccess cmdlet from Exchange Online PowerShell for each principal user/delegate user combination.

Set-MailboxIRMAccess -Identity “JoanneExecutive@contoso.com” -User “BobDelegate@contoso.com” -AccessLevel Block

Parameters:

• Identity: The target mailbox. You can use any value that uniquely identifies the mailbox.
• User: Specifies the delegate or shared mailbox member who is blocked from reading IRM-protected messages in the mailbox or shared mailbox. The user’s login ID must be used.
• AccessLevel: Specifies what delegates can do with IRM-protected messages in the specified mailbox. Currently, only  “Block” is supported.

It is important to understand that this will block access for the delegate to any email that has been encrypted with the Rights Management service in the principal user’s mailbox. It doesn’t discern between different encrypting sensitivity labels or which built-in encryption option has been used – it blocks them all.

Important maintenance task! You must keep this up-to-date as mailbox owners and their delegated users change over time.

What does this look like for the email sender and recipient’s delegated user?

Assume we have a sender named Joanne, a recipient named John (a principal user), and a delegate user named Susan. What do the 2 encryption options above look like when sending/receiving an email if we’ve run the PowerShell to block access for Susan in John’s mailbox?

For the built-in encryption option… When the sender composes an email for a recipient, John Brown, with the Do Not Forward option in the (New) Outlook client, this is what the sender will need to do before sending:

This is what Susan, the delegated user, sees when she previews/opens the above email when it’s received in John Brown’s mailbox (note that the delegate user can still see the email subject, who sent it, the recipients, and when it was sent):

Both John (principal user) and Susan (delegated user) will be prevented from forwarding the message due to the Do Not Forward protection option applied.

For the sensitivity label option… When the sender composes an email for a recipient, John Brown, with a Highly Confidential sensitivity label  in the (New) Outlook client, this is what they will see:

Note: in this tenant, the Highly Confidential sensitivity label is configured with admin-defined permissions with co-owner for everyone on the Project Team (Project team does not include the delegate user).

This is what Susan, the delegated user, sees when she previews/opens the above email when it’s received in John Brown’s mailbox (note that the delegate user can still see the email subject, who sent it, the recipients, and when it was sent):

Observations

Testing has shown that although this addresses the main issue of preventing the delegate user from viewing encrypted emails in the principal user’s mailbox, there are a few details to be aware of (some good, some not so good):

• the PowerShell cmdlet has a broad blocking effect and will block any email encrypted by either of the 2 options for the delegated user; something that may not be desired. For example, there may be some confidential emails that the principal user wants the delegate user to be able to open.
• even if the delegate user is blocked from viewing the email, they will still see the email subject, who sent it, the recipients, and when it was sent
• in my testing, if the sender has a delegate user as well, their delegate user can go into the Sent items of the principal user’s mailbox and open up any emails sent with either of the above 2 encryption options! (I would appreciate if someone else can confirm this behavior)
• if the PowerShell has been run for a delegate user and the sensitivity label encryption also includes the delegate user as part of its label configuration (all domain users for example), the delegate user will still be blocked from opening the email in the principal user’s inbox. This is because the PowerShell blocks the delegate from all RMS-protected emails in the principal user’s mailbox
• if the Do Not Forward option is chosen, it will automatically disable the Forward option for the principal user; however, the delegate user will still see the option to forward and will receive an error only after they hit Send. This makes sense because the delegate user is blocked from opening the email to read the access restriction of Do Not Forward.

I hope you found this post helpful to show how the business requirement of blocking delegates from accessing confidential emails can be met with encryption and a bit of PowerShell.

Thanks for reading. 🙂

-JCK