Shared mailbox permissions in M365: the MSP guide
Shared mailbox permissions in Microsoft 365 come in three types. Full Access lets a user open the mailbox and read, create and change items. Send As lets them send mail that appears to come from the mailbox itself. Send on Behalf lets them send for the mailbox with their own name still shown. You grant all three in the Exchange admin center or PowerShell.
For an MSP, the permission is the easy part. I have watched a simple "add me to finance@" eat 10 to 15 minutes once you add up identity matching, approval pings, the permission change, PSA notes and the message back to the user. One or two a day feels fine. Forty a week across tenants is where the hours go, and it is the same pattern behind most multi-system user provisioning mistakes.
The three shared mailbox permissions in M365
| Permission | What the user can do | Where it is set |
|---|---|---|
| Full Access (Read and manage) | Open the mailbox, read mail, create and change items | Exchange admin center delegation, or Add-MailboxPermission |
| Send As | Send mail that looks like it came from the shared mailbox | Exchange admin center delegation, or Add-RecipientPermission |
| Send on Behalf | Send for the mailbox, with their own name shown as the sender | Mailbox delegation, stored in the mailbox's GrantSendOnBehalfTo property |
Microsoft's Exchange Online documentation says Full Access and Send As are both needed for a shared mailbox to work the way most teams expect, so a typical "give Sam access to sales@" ticket means two grants. Full Access alone lets Sam read and file mail, but Sam cannot send as sales@ without the second permission.
Pick the permission from what the request actually asks for. A user covering a colleague's leave who needs to reply as support@ needs Full Access plus Send As. An assistant who should read the mailbox but sign replies with their own name needs Full Access plus Send on Behalf. A rushed tech who grants Full Access when the ticket asked only for Send As has handed out more access than anyone approved, and that tends to surface at the client's next access review.
Two hard limits apply to all three. Permissions only work inside the same Microsoft 365 organization, and they take time to land: Microsoft says changes can take up to 60 minutes to propagate.
How to grant shared mailbox permissions in the Exchange admin center
- Open the Exchange admin center and go to Recipients > Mailboxes.
- Select the shared mailbox, then choose Manage mailbox delegation.
- Click Edit next to Read and manage (Full Access), Send As or Send on Behalf.
- Click Add permissions, pick the users and save.
The same mailboxes are listed in the Microsoft 365 admin center under Teams & groups > Shared mailboxes, where you can see and change who holds each permission. AdminDroid lists Global Admin or Exchange Online Admin as the role you need for either route.
Put the 60-minute propagation window in the note you send the user. Without it, a good share of these tickets reopen with "I still can't see it" ten minutes after you close them. Microsoft's overview of shared mailboxes in Microsoft 365 covers creating the mailbox itself if the request is for a new one.
Granting shared mailbox permissions with PowerShell
Once you are doing more than a couple of grants, or working the same request across several tenants, PowerShell is faster than clicking through the admin center. Install the module and connect first:
Install-Module -Name ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline
Grant Full Access:
Add-MailboxPermission -Identity "finance" -User "[email protected]" -AccessRights FullAccess
Grant Send As:
Add-RecipientPermission -Identity "finance" -Trustee "[email protected]" -AccessRights SendAs
When you grant Full Access to a user directly, Outlook automaps the mailbox, so it shows up in the user's folder list without them adding it. In Outlook on the web or the new Outlook, a user can also right-click Folders, choose Add shared folder or mailbox and enter the address.
Shared mailbox permissions through security groups
Granting access to a group instead of named users means access follows group membership, which makes leavers easier to clean up during Microsoft 365 user offboarding. PowerShell Center notes that Full Access can be granted to a user mailbox or a mail-enabled security group, while Microsoft 365 groups and distribution groups are not supported.
The trade-off is automapping. It works when the user is added directly to the permission list, and grants made through a group lose it, so group members have to add the mailbox in Outlook themselves. Decide per client which matters more and write it into their runbook, because a tech guessing between the two on each ticket is how one client ends up with half its mailboxes granted one way and half the other. If you are setting this up as part of new accounts, the Office 365 user provisioning guide covers where group membership fits.
Licensing and limits that catch MSPs out
Shared mailboxes look free, and mostly they are, but the edges cost money or break mail:
- A shared mailbox holds up to 50 GB without a license. Going to 100 GB needs an Exchange Online Plan 2 license on the mailbox.
- When a shared mailbox hits its limit it stops sending first, then stops receiving, and senders get a non-delivery receipt.
- In-place archiving and litigation hold need Exchange Online Plan 2, or Plan 1 with the Exchange Online Archiving add-on.
- Every person who opens the shared mailbox needs their own licensed Exchange Online mailbox, even though the shared mailbox itself does not.
- You cannot give people outside the organization access. Microsoft points to a Microsoft 365 group for that case.
Each shared mailbox also has a user account behind it with a system-generated password. Microsoft's guidance is to block sign-in on that account and keep it blocked, which is worth checking on any tenant you inherit.
Read-only access to a shared mailbox
Full Access has no read-only version. A common workaround from r/sysadmin is to set folder-level permissions instead: list the mailbox's folders with Get-MailboxFolderStatistics and loop through them applying a Reviewer-style permission to each. It works, but new folders created later will not carry the permission, so treat it as a grant you revisit.
One related change to know about: michev.info reported that Microsoft has started blocking Add-MailboxFolderPermission when a shared mailbox is itself the delegate on another mailbox's folders. Send As, Send on Behalf and Full Access can still be granted to a shared mailbox principal, and the post says the block may turn out to be a bug or the first of more restrictions. If a script that used to work starts throwing a "not found" error on that cmdlet, this is a likely cause.
Auditing shared mailbox permissions across tenants
Temporary grants for leave cover or a project are the ones that never get removed. AdminDroid publishes three one-liners that pull every delegate across all shared mailboxes in a tenant:
# Full Access
Get-Mailbox |?{$_.RecipientTypeDetails -eq "SharedMailbox"} | Get-MailboxPermission|?{$_.User -ne 'nt authority./self'} |Select-Object Identity,User,AccessRights
# Send As
Get-Mailbox |?{$_.RecipientTypeDetails -eq "SharedMailbox"} | Get-RecipientPermission | where {($_.Trustee -ne 'nt authority./self') -and ($_.Trustee -ne 'Null sid')} | select Identity,Trustee,AccessRights
# Send on Behalf
Get-Mailbox |?{$_.RecipientTypeDetails -eq "SharedMailbox" -and $_.GrantSendOnBehalfTo -ne $null }| Select PrimarySmtpAddress,GrantSendOnBehalfTo,RecipientTypeDetails
Run them per tenant before each quarterly access review and send the output to the client's approver to confirm. If you manage many tenants, a multi-tenant tool such as CIPP for Microsoft 365 saves connecting to each one by hand.
Why a two-minute mailbox grant takes 15 minutes in an MSP
Your techs already know every step above. The minutes vanish around the change: finding the right user in Entra ID, confirming which mailbox "finance" means at this client, working out who approves, waiting for them, making the change, then going back to the PSA to write notes and message the user. That is five to seven touches for a one-line outcome, often with your RMM, the admin center and the PSA all open at once.
Approvals cause most of the waiting. If you guess the wrong approver you wait twice, and at 5 pm two of the three managers you need are offline. Look at who actually signed off on past mailbox tickets for each client and department, use that as the default, and add explicit rules where the history is thin. A risk-based autonomy matrix is a good place to write down which grants need a named approver and which can go through on the request alone.
The cost adds up quickly. A tech spending 10 minutes per grant, 30 times a week, loses five hours. At a loaded cost of $45 an hour, that is over $200 a week for one ticket category, before resets and the rest of the L1 tickets that eat MSP margin. For how that compares with other MSPs, see the MSP cost per ticket benchmarks.
A minimal process that holds up across tenants:
- Map approvers per client and per mailbox.
- Capture the approval on the ticket where the request started.
- Grant the exact permissions asked for, directly or by group per the client's runbook.
- Note the approver, the permission set and the 60-minute window in the PSA and the user reply, then resolve.
Running shared mailbox grants from the ticket with Rallied
Rallied is an AI agent that closes MSP tickets in your PSA. It works in ConnectWise, HaloPSA and Autotask, runs the fix in Microsoft 365, and writes the notes and time entry back to the ticket. Shared mailbox access is one of the Microsoft 365 actions Rallied runs from the ticket. Everything else it can do in a customer tenant is on the Microsoft 365 automation page.
During triage it pulls the client's documentation from IT Glue or Hudu, which is where most MSPs keep the per-client details this ticket depends on, such as who approves and how mailboxes are named. You set the policies for what it is allowed to act on. It cannot shorten Microsoft's propagation window, so the user still waits up to an hour for the mailbox to appear.
Pricing is $300 a month with 2,000 credits. A ticket where Rallied looks up the user and changes the permission is a Standard ticket at 3 credits, and one that works across three or more systems with six or more actions is 8. Triage and diagnosis are free, and a ticket it could not finish or was not allowed to act on is never charged. See how Rallied AI works
Mailbox access usually arrives as part of a new starter. For the wider flow, read How MSPs automate user onboarding in 2026.
Frequently Asked Questions
What is the difference between Full Access and Send As on a shared mailbox?
Full Access lets a user open the shared mailbox and read, create and change items in it. Send As lets them send mail that appears to come from the shared mailbox itself. Microsoft says both are needed for a shared mailbox to work the way most teams expect, so most requests mean granting both.
How long do shared mailbox permissions take to apply in Microsoft 365?
Microsoft says permission changes can take up to 60 minutes to propagate. Tell the user this in the closing note so the ticket doesn't reopen when the mailbox doesn't appear right away.
Does a shared mailbox need a license?
A shared mailbox can hold up to 50 GB without a license. It needs an Exchange Online Plan 2 license to go to 100 GB, and archiving or litigation hold also need extra licensing. Every user who opens the shared mailbox needs their own licensed Exchange Online mailbox.
Can I grant shared mailbox permissions to a group?
Full Access can be granted to a mail-enabled security group, but Microsoft 365 groups and distribution groups are not supported. Grants made through a group do not automap in Outlook, so members add the mailbox themselves.
Can external users access a Microsoft 365 shared mailbox?
No. Mailbox permissions only work inside the same organization, so people with outside accounts such as Gmail cannot be given access. Microsoft suggests a Microsoft 365 group for that case.
How do I give someone read-only access to a shared mailbox?
Full Access has no read-only version. A common workaround is to set folder-level permissions on each folder, using Get-MailboxFolderStatistics to list the folders and a loop to apply the permission. New folders created later won't inherit it, so revisit the grant.
How do I export a report of shared mailbox permissions?
Connect to Exchange Online PowerShell and run Get-MailboxPermission for Full Access, Get-RecipientPermission for Send As, and check the GrantSendOnBehalfTo property for Send on Behalf, filtered to shared mailboxes. Run it per tenant before access reviews to catch temporary grants that were never removed.