Site icon Joanne C Klein

Restricting Confidential emails for Delegated Users

Joanne Klein
Laptop and coffee cup on a desk with title "How to Restrict Confidential emails for delegated users"
Reading Time: 7 minutes

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:

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:

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:

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:

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:

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):

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

Exit mobile version