Fix Shared Mailbox Permissions in Microsoft 365 for Small Business IT

Fix Shared Mailbox Permissions in Microsoft 365 for Small Business IT

Full Access controls who can open a shared mailbox and work with its content; Send As and Send on Behalf control how outgoing mail identifies its sender. For most shared mailboxes, the right baseline is Full Access paired with Send As, so replies look like they came from the shared address itself. Send on Behalf works better when you want recipients to see exactly who answered.

---

TL;DR:

• Granting Full Access allows viewing and managing mailbox content but does not include sending rights, so separate permissions like Send As or Send on Behalf are necessary for outgoing emails.
• Send As makes messages appear to originate from the shared mailbox directly, while Send on Behalf shows the sender's name alongside the mailbox, affecting transparency and accountability.
• Permission changes take effect within minutes but may be delayed by propagation issues, requiring testing on Outlook Web and desktop clients to confirm proper setup.
• Automapping automatically adds mailboxes for users with direct Full Access, but it does not include group-based delegation, which needs manual management and documentation.
• Most shared mailboxes do not require licenses unless they exceed storage limits, are under retention or hold policies, or need advanced compliance features.

---

Table of Contents

• Shared Mailbox Permissions 365: Full Access, Send As, and Send on Behalf Explained
• How Do You Assign and Remove Shared Mailbox Permissions?
• Does Automapping Work With Security-Group Delegation?
• When Does a Shared Mailbox Need Its Own License?
• Why Do Send As Permissions Fail to Propagate?
• What Governance Keeps Shared Mailbox Access Under Control?
• How Great Plains Networking Applies This Guidance
• Get a Microsoft 365 Permission Audit for Your Business
• Authoritative Microsoft Documentation and Admin Links
• Sources
• FAQ

Shared Mailbox Permissions 365: Full Access, Send As, and Send on Behalf Explained

Full Access lets a delegate open the mailbox and read, create, modify, or delete its items, but it grants no sending rights at all. That distinction trips up more admins than any other part of shared mailboxes in Exchange Online, and it's the source of most "why can't my staff send from the shared inbox" tickets.

Send As and Send on Behalf both control sender identity, but they behave differently in the recipient's inbox:

• Full Access — opens the mailbox in Outlook or Outlook on the web; no sending capability by itself.
• Send As — messages appear to come directly from the shared mailbox, with no indication of who actually sent them.
• Send on Behalf — the From line shows something like "Jane Smith on behalf of Billing," exposing the actual sender.

Full Access carries real privacy weight. Anyone granted it can see every private item in that mailbox, including anything a colleague marked confidential before you added them. Choose Send As when a law office wants every outgoing message to read as one unified voice from intake@firm.com. Choose Send on Behalf when a dental practice wants patients to know which staff member replied, useful for accountability during billing disputes.

Pro Tip: Grant Full Access and Send As two separate actions, even when the same person needs both. Treating them as one bundled step is exactly how audits later turn up delegates with content access nobody remembers approving.

How Do You Assign and Remove Shared Mailbox Permissions?

In the Exchange admin center, go to Recipients > Mailboxes, select the shared mailbox, and open "Manage mailbox delegation" to add or remove Full Access and Send As entries. You need Exchange Administrator or Global Administrator rights to make these changes; Helpdesk Administrator roles typically can't touch delegation settings.

PowerShell gives you more control and is faster for bulk changes. The core commands, per Microsoft's permissions guide for Exchange Online, are:

1. Add-MailboxPermission -Identity "SharedMailbox" -User "user@domain.com" -AccessRights FullAccess -AutoMapping $true grants Full Access.
2. Add-RecipientPermission -Identity "SharedMailbox" -Trustee "user@domain.com" -AccessRights SendAs grants Send As.
3. Set-Mailbox -Identity "SharedMailbox" -GrantSendOnBehalfTo "user@domain.com" grants Send on Behalf.

Verify with Get-MailboxPermission -Identity "SharedMailbox" and Get-RecipientPermission -Identity "SharedMailbox". Changes usually apply within minutes, but plan for occasional delays before you assume something's broken.

Does Automapping Work With Security-Group Delegation?

Automapping adds a shared mailbox to Outlook automatically when a user gets direct Full Access, according to Microsoft's automapping documentation. It does not enumerate security-group membership, so if you delegate access through a group, members won't see the mailbox appear on their own.

That gap matters for scale. A few practical rules:

• Use Add-MailboxPermission -AutoMapping $false when a delegate needs access but shouldn't have it cluttering their Outlook profile automatically.
• Prefer group-based delegation for teams of five or more, since it's far easier to manage than individual permission entries.
• Document every group-based grant and give affected users manual "add shared mailbox" instructions, since Outlook won't do it for them.

When Does a Shared Mailbox Need Its Own License?

Shared mailboxes typically don't require a license at all. The exceptions, per Microsoft's shared mailbox overview, are what catch small IT teams off guard:

• The mailbox exceeds the standard 50 GB storage limit and needs a license for expanded storage.
• It's placed on litigation hold or in-place hold, which requires licensing for retention features.
• It needs advanced compliance or security capabilities, like certain eDiscovery or data-loss-prevention policies.

Check current size and hold status in the Microsoft 365 admin center under mailbox settings before assuming a mailbox is safely unlicensed. Practices dealing with email retention requirements hit this exception more often than most, since compliance holds quietly force a license nobody budgeted for.

Why Do Send As Permissions Fail to Propagate?

Grant Full Access and assume sending will just work, and you'll generate a support ticket within the hour. Microsoft's own troubleshooting guidance confirms Full Access and Send As are independent grants, and skipping the second one is the single most common shared-mailbox complaint.

Work through the problem in layers:

1. Confirm the permission actually exists with Get-MailboxPermission and Get-RecipientPermission before touching anything else.
2. Test sending from Outlook on the web first. If OWA sends cleanly, the issue is almost always the desktop Outlook profile, not the server-side permission.
3. Test the desktop client separately, and if it still fails, remove and re-add the Send As entry rather than layering a second grant on top of the first.

Propagation delays are real and documented in Microsoft Q&A threads on permission issues, so give a fresh grant 15 to 30 minutes before troubleshooting further. Alias changes on a shared mailbox can also quietly break existing Send As entries, so retest after any address change.

Pro Tip: If a user reports sending failures right after you added them to a delegation group instead of granting access directly, check automapping first. Group membership without a manual mailbox add in Outlook looks identical to a permissions failure but isn't one.

What Governance Keeps Shared Mailbox Access Under Control?

Least privilege means separating content access from sending rights every time, not just when it's convenient. Grant Full Access only when someone genuinely needs to see mailbox history, not as a default add-on to every role change.

Maintain a permission inventory that tracks the mailbox name, delegate, permission type, the admin who granted it, the business reason, and a review date. Without that record, permission creep becomes invisible until an audit or a security incident forces the question.

• Record every automapping decision ($true or $false) alongside the permission grant itself.
• Provide written manual-add instructions for any delegate whose access came through a group.
• Set a recurring review cadence, quarterly works well for small teams, rather than reviewing only when someone leaves.

Firms that skip this step tend to discover, months later, that a former employee's access outlived their employment by a wide margin. A documented review cadence is the cheapest insurance against that scenario.

How Great Plains Networking Applies This Guidance

Managed engagements at Great Plains Networking often begin with a permission audit: mapping every Full Access and Send As grant against current staffing, then cleaning up automapping clutter and stale delegations. That remediation work mirrors the governance checklist above, applied to similar dental offices and law firms.

— Nicholas

Get a Microsoft 365 Permission Audit for Your Business

Reading through PowerShell syntax and automapping quirks is one thing. Untangling six years of accumulated shared mailbox permissions across twenty employees is another. Permission audits can map every Full Access, Send As, and Send on Behalf grant across a tenant, flag stale or duplicate access, and provide a remediation plan without requiring a long-term contract.

That audit fits inside Microsoft 365 Support for tenants needing hands-on configuration work, or broader Managed IT Support if permissions are just one piece of a larger cleanup. If you want a lower-commitment starting point, the 10-minute readiness audit gives you a fast read on where your tenant stands before you commit to anything bigger. Book a slot and find out what's actually sitting in your shared mailboxes.

Authoritative Microsoft Documentation and Admin Links

Verify commands and licensing rules directly against Microsoft's shared mailbox documentation and the Add-MailboxPermission reference.

FAQ

How Do I Check Permissions on a Shared Mailbox?

Run Get-MailboxPermission -Identity "SharedMailbox" for Full Access entries and Get-RecipientPermission -Identity "SharedMailbox" for Send As. Both cmdlets are documented in Microsoft's recipient permissions guide.

What's the Difference Between Full Access and Send As?

Full Access lets someone open the mailbox and manage its content, but it grants no ability to send mail. Send As lets someone send mail that appears to come directly from the shared mailbox address, with no name attached, as confirmed in Microsoft's shared mailbox documentation.

How Many Users Can Access a Shared Mailbox in Microsoft 365?

Microsoft does not specify a strict maximum number of delegates for shared mailboxes, but many small businesses maintain manageable permission inventories by keeping shared mailbox access to a limited number of people.

How Do I Grant Send on Behalf Permissions?

Run Set-Mailbox -Identity "SharedMailbox" -GrantSendOnBehalfTo "user@domain.com" in Exchange Online PowerShell. Recipients will see "sender on behalf of mailbox" in the From line, unlike Send As, which hides the actual sender entirely.

Does a Shared Mailbox Need Its Own Microsoft 365 License?

Most shared mailboxes don't need a license at all. Exceptions include mailboxes over the 50 GB storage limit, mailboxes on litigation hold, or mailboxes needing advanced compliance features, per Microsoft's licensing guidance.

Recommended

• 150 Mailboxes for IT Teams: Microsoft 365 Email Migration, 300s MX TTL
• SMB Microsoft 365 Security: Crawl, Walk, Run Checklist in 30–90 Days
• Microsoft 365 Migration Guide for Small Business