Shared Mailbox Permissions in Exchange Online: Assign and Audit Safely

Decide who needs to read and who needs to send

Most shared mailbox exposure comes from one habit: granting everything to everyone who asked. Exchange Online splits access into three separate permissions, and they do different jobs.

Full Access lets someone open the mailbox and act as its owner. They can read, change and delete messages, and create calendar items, tasks and contacts. It does not let them send. Send As lets them send mail that looks as if the mailbox itself sent it, with nothing to show who actually did, but it does not let them read anything. Send on Behalf also allows sending, but the From line reads as the person on behalf of the mailbox, so the sender stays visible to recipients. If someone holds both Send As and Send on Behalf, Send As wins.

For a normal team inbox, people need Full Access plus one of the sending permissions. The useful questions are who really needs to read everything in it, and which sending style fits. Customer-facing mailboxes usually suit Send As. Where you want recipients and colleagues to see who replied, Send on Behalf is the better fit. An automated process or a manager who only ever sends from the address needs the sending permission and no Full Access.

The NCSC's identity and access guidance frames this as least privilege: review accounts for unnecessary privileges regularly, revoke access when people move or leave, and make sure actions can be traced to a person or account. Everything below is aimed at those three outcomes.

One design choice does most of the work: grant the permissions to a mail-enabled security group per shared mailbox, not to individuals. Joiners and leavers then become a group membership change, and the audit has one place to look. The trade-off is auto-mapping. Microsoft's guidance is that auto-mapping, which adds the mailbox to Outlook automatically, only works for permissions granted to individual users, not groups. With a group, people add the mailbox themselves, which is a small price for a list you can actually read.

What you need before you start

You need an account that can manage Exchange Online recipients and permissions, such as one holding the Exchange Administrator role, and the ExchangeOnlineManagement PowerShell module. Searching the audit log in the Microsoft Purview portal needs the Audit Logs or View-Only Audit Logs role. Changing the mailbox account's sign-in status through Microsoft Graph PowerShell needs the User.ReadWrite.All permission scope, and the Microsoft Graph PowerShell SDK.

If you run a hybrid Exchange environment, Microsoft's advice is to create and manage shared mailboxes from the on-premises Exchange admin centre. The commands below are for mailboxes that live in Exchange Online.

Commands use placeholders in capitals such as YOUR_SHARED_MAILBOX_ADDRESS and YOUR_GROUP_ADDRESS. Replace them with the real primary SMTP addresses. Connect to Exchange Online PowerShell first and sign in when prompted.

Connect-ExchangeOnline

Make sure nobody can sign in as the mailbox

Every shared mailbox is backed by a user account. Microsoft says it is created with a system-generated password nobody knows, and that new shared mailboxes have sign-in blocked by default. Check rather than assume, particularly for older mailboxes. A shared mailbox that can be signed into directly defeats the whole exercise, because activity then points at the mailbox rather than a person.

This changes only the sign-in status of the mailbox's own account. Delegates reach the mailbox through their own accounts, so blocking it does not stop them. To undo it, run the same update with accountEnabled set to true.

1. Connect to Microsoft Graph with the scope needed to read and change users.
   powershellCopy

   Connect-MgGraph -Scopes User.ReadWrite.All

2. Check the account status. The accountEnabled column should read False.
   powershellCopy

   Get-MgUser -UserId "YOUR_SHARED_MAILBOX_ADDRESS" -Property "displayName,accountEnabled" | Select-Object displayName, accountEnabled

3. If it reads True, block sign-in, then run the check again to confirm False.
   powershellCopy

   $params = @{ accountEnabled = $false }
   Update-MgUser -UserId "YOUR_SHARED_MAILBOX_ADDRESS" -BodyParameter $params

Grant access through a group

This sequence gives a group read-and-act access and sending rights on one shared mailbox. It assumes the mail-enabled security group already exists and contains only the people who should have access. It changes who can open the mailbox and send as it, so confirm the membership with the mailbox's business owner first. Rollback is the matching Remove command shown in the removal section.

Permission changes are not always instant. If a test user cannot see the change straight away, give it a few minutes before assuming something failed.

1. Grant Full Access to the group. Because the target is a group, the mailbox will not auto-map into members' Outlook.
   powershellCopy

   Add-MailboxPermission -Identity "YOUR_SHARED_MAILBOX_ADDRESS" -User "YOUR_GROUP_ADDRESS" -AccessRights FullAccess -InheritanceType All

2. Grant Send As to the group. Skip this step if you prefer recipients to see who sent the message, and use the Send on Behalf step instead. Do not use both unless you want Send As to win.
   powershellCopy

   Add-RecipientPermission -Identity "YOUR_SHARED_MAILBOX_ADDRESS" -Trustee "YOUR_GROUP_ADDRESS" -AccessRights SendAs

3. For Send on Behalf, add the group to the mailbox's delegate list. The Add syntax leaves any existing delegates in place.
   powershellCopy

   Set-Mailbox -Identity "YOUR_SHARED_MAILBOX_ADDRESS" -GrantSendOnBehalfTo @{Add="YOUR_GROUP_ADDRESS"}

4. Make replies land in the shared mailbox's Sent Items. Without this, a sent message is stored in the sender's own Sent Items, which pulls shared correspondence into personal mailboxes. Use the first command for Send As and the second for Send on Behalf. Microsoft notes these settings are not supported when the user mailbox and shared mailbox sit in different environments, such as cloud and on-premises.
   powershellCopy

   Set-Mailbox -Identity "YOUR_SHARED_MAILBOX_ALIAS" -MessageCopyForSentAsEnabled $true
   Set-Mailbox -Identity "YOUR_SHARED_MAILBOX_ALIAS" -MessageCopyForSendOnBehalfEnabled $true

5. Check the result. The first command should list the group with FullAccess, the second should list the group as a Send As trustee and the third should show the group among the Send on Behalf delegates, depending on which you chose.
   powershellCopy

   Get-MailboxPermission -Identity "YOUR_SHARED_MAILBOX_ADDRESS" | Where-Object { $_.AccessRights -like 'Full*' } | Format-Table User, Deny, IsInherited, AccessRights -AutoSize
   Get-RecipientPermission -Identity "YOUR_SHARED_MAILBOX_ADDRESS" -Trustee "YOUR_GROUP_ADDRESS"
   Get-Mailbox -Identity "YOUR_SHARED_MAILBOX_ADDRESS" | Format-List GrantSendOnBehalfTo

6. Test with real people: a group member should be able to open the mailbox in Outlook on the web and send from it, and someone outside the group should not be able to open it.

Audit who has access right now

This is the read-only part, and it is the one worth putting in the diary. The script below walks every shared mailbox and lists each Full Access holder, each Send As trustee and each Send on Behalf delegate. It skips inherited and default entries such as the mailbox's own SELF entry, so what remains is what someone deliberately granted. It makes several calls per mailbox, so a tenant with a lot of shared mailboxes will take a while. It changes nothing.

The output names real staff, so treat the file as sensitive: save it somewhere access-restricted and delete it when the review is done.

Folder-level sharing is a separate permission layer and is not in this list. Someone with enough rights in a mailbox can share individual folders, so the audit log search in the next section also looks for folder permission changes.

1. Run the inventory and review the table on screen.
   powershellCopy

   $report = foreach ($mbx in Get-EXOMailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited -Properties GrantSendOnBehalfTo) {
       $id = $mbx.PrimarySmtpAddress
       Get-EXOMailboxPermission -Identity $id |
           Where-Object { $_.AccessRights -like '*FullAccess*' -and -not $_.IsInherited -and -not $_.Deny -and $_.User -ne 'NT AUTHORITY\SELF' } |
           ForEach-Object { [pscustomobject]@{ Mailbox = $id; Permission = 'FullAccess'; Holder = $_.User } }
       Get-EXORecipientPermission -Identity $id |
           Where-Object { $_.Trustee -ne 'NT AUTHORITY\SELF' } |
           ForEach-Object { [pscustomobject]@{ Mailbox = $id; Permission = 'SendAs'; Holder = $_.Trustee } }
       foreach ($delegate in $mbx.GrantSendOnBehalfTo) {
           [pscustomobject]@{ Mailbox = $id; Permission = 'SendOnBehalf'; Holder = $delegate }
       }
   }
   $report | Sort-Object Mailbox, Permission | Format-Table -AutoSize

2. Export it if you want to mark it up or send it to mailbox owners.
   powershellCopy

   $report | Sort-Object Mailbox, Permission | Export-Csv -Path "YOUR_REPORT_PATH.csv" -NoTypeInformation

3. Expand each group row to the people inside it.
   powershellCopy

   Get-DistributionGroupMember -Identity "YOUR_GROUP_ADDRESS" | Format-Table DisplayName, PrimarySmtpAddress

4. Go through every row and ask four things: who is this, do they still work here or in that role, do they need to read the mailbox or only send from it, and has the owner agreed. Remove anything that fails (see the removal section). You are finished when every row maps to a named person or a group whose members you have checked, and each one has a current reason to be there.

Check what people have actually done in the mailbox

A permission list tells you who could do something. The audit log tells you what happened. Mailbox auditing is on by default and covers shared mailboxes, and for delegates (anyone with Full Access, Send As or Send on Behalf) Microsoft lists the following as logged by default: SendAs, SendOnBehalf, Update, Create, MoveToDeletedItems, SoftDelete, HardDelete, UpdateInboxRules and UpdateFolderPermissions.

Two limits matter. First, opening the mailbox or a folder (FolderBind) is not logged by default for delegates. Second, reads are the awkward case. The MailItemsAccessed action, which records mail being accessed by clients and protocols, is listed as audited by default, but Microsoft's cmdlet reference limits it to users on an E5 or E5 Compliance add-on subscription. Do not assume you can prove who read a particular message. Be ready to prove who sent, moved, deleted or changed things.

Retention is also licence-dependent. Audit records are kept for 180 days for most licences and for one year by default for users on E5-level licences. Anything older is not there to search.

Start by confirming auditing is healthy. Then search. The unified audit log is the supported route: Microsoft states that the older Search-MailboxAuditLog cmdlet will be deprecated in the cloud service and points to Search-UnifiedAuditLog instead.

• Opening the Microsoft Purview portal, choose the Audit solution and use Search. Set the date and time range (UTC) and put the shared mailbox's primary SMTP address in the Keyword Search box, not the Users box. Microsoft states that shared mailbox searches work this way. Results for core Exchange activity typically appear 60 to 90 minutes after the event.
• Keyword matches are made only against indexed audit content, so treat an empty result as not found rather than proof that nothing happened, and cross-check with the PowerShell search.
• Operations worth looking for: SendAs, SendOnBehalf, HardDelete, SoftDelete, MoveToDeletedItems, UpdateInboxRules (rules that forward or hide mail) and UpdateFolderPermissions (someone widening access). Changes an administrator makes to the mailbox with cmdlets such as Set-Mailbox are recorded as Exchange admin activity.
• Check that nobody is exempt from logging. Mailbox audit bypass stops all of a user's mailbox actions being logged, including delegate actions on shared mailboxes. The final command should return nothing.

1. Confirm mailbox auditing is on for the organisation: AuditDisabled should be False and UnifiedAuditLogIngestionEnabled should be True. Run both in Exchange Online PowerShell.
   powershellCopy

   Get-OrganizationConfig | Format-List AuditDisabled
   Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled

2. Confirm the shared mailbox is on Microsoft's default audited actions: DefaultAuditSet should read Admin, Delegate, Owner. If someone customised the audited actions, the value differs and new default actions are no longer picked up automatically. Restoring the defaults is a single Set-Mailbox command with the DefaultAuditSet parameter.
   powershellCopy

   Get-Mailbox -Identity "YOUR_SHARED_MAILBOX_ADDRESS" | Format-List DefaultAuditSet

3. Search the last 30 days for activity that mentions the mailbox. Without a UserIds filter, this finds delegate activity in the shared mailbox. Default output is capped at 100 records, so ResultSize is set explicitly. If you hit the cap, narrow the date range or use the portal.
   powershellCopy

   $start = (Get-Date).AddDays(-30).ToUniversalTime()
   $end = (Get-Date).ToUniversalTime()
   Search-UnifiedAuditLog -StartDate $start -EndDate $end -FreeText "YOUR_SHARED_MAILBOX_ADDRESS" -ResultSize 1000 | Select-Object CreationDate, UserIds, Operations | Sort-Object CreationDate

4. Check for audit bypass.
   powershellCopy

   Get-MailboxAuditBypassAssociation -ResultSize Unlimited | Where-Object { $_.AuditByPassEnabled } | Format-Table Name, AuditByPassEnabled

Remove access, and fix the usual snags

With the group model, removing someone from the shared mailbox means removing them from the group. That takes their access away from that mailbox and nothing else, apart from any other mailbox the same group guards, so use one group per mailbox. To restore it, add them back. Check with the person's manager or the mailbox owner before removing access mid-task, because the person loses the ability to read and send from the mailbox.

If you inherited individual grants, remove them with the matching Remove commands. Re-adding with the Add commands from the grant section is your rollback. Run the inventory again afterwards and confirm the row has gone.

• The mailbox does not appear in Outlook: auto-mapping only works for permissions granted to individual users, and not for groups. Members can add the mailbox themselves in Outlook, or you can grant Full Access to that person directly if automatic appearance matters more than a tidy list.
• They can open it but not send: Full Access does not include sending. Check Send As or Send on Behalf for them or their group.
• Send As or Send on Behalf fails in the Outlook desktop app: Microsoft states these permissions do not work there when the mailbox has HiddenFromAddressListsEnabled set to True, because they depend on the mailbox being visible in the Global Address List. Hiding a mailbox from the address list is not an access control, so unhide it and rely on the permissions instead.
• Sent messages appear in the sender's Sent Items: apply the MessageCopyForSentAsEnabled or MessageCopyForSendOnBehalfEnabled setting from the grant section. With new Outlook, Microsoft says only that mailbox-side setting applies, and the Outlook registry workaround does not.

1. Remove a person from the group that holds the permissions.
   powershellCopy

   Remove-DistributionGroupMember -Identity "YOUR_GROUP_ADDRESS" -Member "YOUR_USER_ADDRESS"

2. If you need to remove a direct grant instead, remove Full Access, Send As or Send on Behalf as appropriate.
   powershellCopy

   Remove-MailboxPermission -Identity "YOUR_SHARED_MAILBOX_ADDRESS" -User "YOUR_USER_ADDRESS" -AccessRights FullAccess -InheritanceType All
   Remove-RecipientPermission -Identity "YOUR_SHARED_MAILBOX_ADDRESS" -Trustee "YOUR_USER_ADDRESS" -AccessRights SendAs
   Set-Mailbox -Identity "YOUR_SHARED_MAILBOX_ADDRESS" -GrantSendOnBehalfTo @{Remove="YOUR_USER_ADDRESS"}

3. Run the inventory again and confirm the removed person no longer appears for that mailbox.