Shared mailbox permissions: who may read, and who may send on behalf of the team?

Adding a permission is usually quick. What matters more is that you also know how to remove it again later.

1. 1Open the Exchange admin center and go to Recipients > Mailboxes.
2. 2Choose the shared mailbox and then Manage mailbox delegation.
3. 3Choose Edit next to Read and manage (Full Access) or next to Send as, add the users and save.
4. 4Send on Behalf is not here. You grant that with PowerShell.

Connect-ExchangeOnline

# Full Access, with automapping (default)
Add-MailboxPermission -Identity "planning@bedrijf.nl" -User "jan.jansen@bedrijf.nl" -AccessRights FullAccess -InheritanceType All

# Send As
Add-RecipientPermission -Identity "planning@bedrijf.nl" -Trustee "jan.jansen@bedrijf.nl" -AccessRights SendAs -Confirm:$false

# Send on Behalf, without overwriting existing names
Set-Mailbox -Identity "planning@bedrijf.nl" -GrantSendOnBehalfTo @{ Add = "jan.jansen@bedrijf.nl" }

Remove-MailboxPermission -Identity "planning@bedrijf.nl" -User "jan.jansen@bedrijf.nl" -AccessRights FullAccess -InheritanceType All -Confirm:$false
Remove-RecipientPermission -Identity "planning@bedrijf.nl" -Trustee "jan.jansen@bedrijf.nl" -AccessRights SendAs -Confirm:$false
Set-Mailbox -Identity "planning@bedrijf.nl" -GrantSendOnBehalfTo @{ Remove = "jan.jansen@bedrijf.nl" }

If someone cannot send after the permission is granted and gets "You do not have the permission to send the message on behalf of the specified user", wait. According to Microsoft that is a replication delay that clears after about an hour.

An employee has the right permissions, yet cannot see the mailbox. That does not have to be a fault in the permission.

When you give a user Full Access, Outlook adds the shared mailbox to their profile by itself. That is called automapping and it is on by default. Outlook uses Autodiscover for this, and Autodiscover only looks at users who have Full Access themselves. It does not see members of a group with Full Access. If you give Full Access through a group, the members do have access, but they have to add the mailbox in Outlook themselves, or open it in Outlook on the web.

If you actually want to switch automapping off, for example for someone with access to twenty mailboxes that slow Outlook down, you can only do that when granting the permission. For someone who already has Full Access, remove the permission first and grant it again:

Remove-MailboxPermission -Identity "planning@bedrijf.nl" -User "jan.jansen@bedrijf.nl" -AccessRights FullAccess -InheritanceType All -Confirm:$false

Add-MailboxPermission -Identity "planning@bedrijf.nl" -User "jan.jansen@bedrijf.nl" -AccessRights FullAccess -InheritanceType All -AutoMapping $false

When several colleagues use the same mailbox, it makes sense to manage permissions through a group. That does come with a practical limitation.

Granting permissions per person stays manageable until you have ten mailboxes and fifty colleagues. A group saves work: you change one membership instead of three permissions on every mailbox. For this you use a mail-enabled security group. You can pick an ordinary security group in the list, but according to Microsoft the permission then does not work.

$groep = "MB-Planning"

Add-MailboxPermission -Identity "planning@bedrijf.nl" -User $groep -AccessRights FullAccess -InheritanceType All
Add-RecipientPermission -Identity "planning@bedrijf.nl" -Trustee $groep -AccessRights SendAs -Confirm:$false
Set-Mailbox -Identity "planning@bedrijf.nl" -GrantSendOnBehalfTo @{ Add = $groep }

That last point is the real limitation. A dynamic group based on department or job title, as in dynamic groups based on HR attributes, can be made in Entra ID from an ordinary security group or a Microsoft 365 group. A mail-enabled security group is managed in Exchange or the Microsoft 365 admin center, by hand. How the group types differ further is covered in the difference between security groups and Microsoft 365 groups.

With shared mailboxes in particular, the list of people who were once given access quietly keeps growing.

That question comes up in every audit, and the answer is in three places: Full Access and Send As are permissions with their own cmdlet, Send on Behalf is a property of the mailbox. This script lists them per shared mailbox, without the system entries (NT AUTHORITY\SELF) and inherited permissions.

Connect-ExchangeOnline

Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited | ForEach-Object {
  $mb = $_.PrimarySmtpAddress

  Get-MailboxPermission -Identity $mb |
    Where-Object { -not $_.IsInherited -and $_.User -notlike "NT AUTHORITY\*" } |
    ForEach-Object { [pscustomobject]@{ Mailbox = $mb; Wie = $_.User; Recht = "FullAccess" } }

  Get-RecipientPermission -Identity $mb -AccessRights SendAs |
    Where-Object { $_.Trustee -notlike "NT AUTHORITY\*" } |
    ForEach-Object { [pscustomobject]@{ Mailbox = $mb; Wie = $_.Trustee; Recht = "SendAs" } }

  $_.GrantSendOnBehalfTo |
    ForEach-Object { [pscustomobject]@{ Mailbox = $mb; Wie = $_; Recht = "SendOnBehalf" } }
} | Export-Csv ".\gedeelde-mailboxen.csv" -NoTypeInformation -Encoding UTF8

If a group is among them, you see the group name rather than the people; you look those up with Get-DistributionGroupMember. Put the result next to your staff list. What you usually find: former employees still on a mailbox because their account was only disabled, people who changed team and still have their old team's mailbox, and groups whose members nobody knows.

• No licence needed up to 50 GB. Anyone who opens the mailbox does need an Exchange Online licence of their own.
• Block sign-in on the shared mailbox's account, and keep it blocked. Microsoft does not intend the mailbox for direct sign-in.
• Up to 25 users. If more people work in it at the same time, they may see connection errors or duplicate messages. For a larger group Microsoft recommends a Microsoft 365 group.
• Internal users only. You cannot give external people access.
• You cannot prevent deletion. Anyone with Full Access can throw messages away.
• Encrypting from the shared mailbox is not possible, because the mailbox has no sign-in credentials of its own.
• Moves. With a new role, the new team's mailbox usually does get added. A permission on the old mailbox does not disappear by itself.

If a leaver's mailbox is converted to a shared mailbox, a few extra conditions apply. They are in removing licences when employees leave.