Shared mailbox permissions not working — Exchange and M365 fix guide

Shared mailbox permissions are deceptively simple in the admin portal and deceptively broken in practice. Full Access is granted, the user clicks Add Account in Outlook, and nothing appears — or worse, they get a prompt for credentials that never works. Send As shows in the portal but the recipient sees the actual sender's address anyway. This runbook covers every common failure mode with the exact PowerShell to verify and fix each one.

Full Access granted but mailbox won't open

The most common scenario: IT grants Full Access in the Microsoft 365 admin center, the user tries to open the mailbox in Outlook, and it either doesn't appear in the folder list or prompts for a password that never works.

Verify the permission was actually applied

The M365 admin center has a known lag — permissions granted via the UI can take 30–60 minutes to propagate. Always verify with PowerShell before troubleshooting further.

# Connect to Exchange Online
Connect-ExchangeOnline -UserPrincipalName admin@domain.com

# Check Full Access permissions on the shared mailbox
Get-MailboxPermission -Identity "helpdesk@domain.com" |
    Where-Object {$_.AccessRights -eq "FullAccess" -and $_.IsInherited -eq $false} |
    Select-Object User,AccessRights,Deny

If the user's account doesn't appear in the output, the permission wasn't saved. Grant it via PowerShell:

Add-MailboxPermission -Identity "helpdesk@domain.com" `
    -User "jsmith@domain.com" `
    -AccessRights FullAccess `
    -InheritanceType All `
    -AutoMapping $true

AutoMapping — when it helps and when it breaks things

The -AutoMapping $true flag tells Outlook to automatically add the shared mailbox to the user's folder list. This works well for most users but fails in specific situations:

• The user is on Outlook for Mac — AutoMapping is not supported
• The shared mailbox is very large (5GB+) — AutoMapping can slow Outlook startup significantly
• The user already manually added the mailbox — double entries appear

To grant Full Access without AutoMapping:

Add-MailboxPermission -Identity "helpdesk@domain.com" `
    -User "jsmith@domain.com" `
    -AccessRights FullAccess `
    -InheritanceType All `
    -AutoMapping $false

Send As granted but emails show the actual sender

Send As permission is different from Full Access and lives in a different cmdlet. The admin center sometimes grants these together but they fail independently.

Verify Send As is set correctly

# Note: Send As uses Get-RecipientPermission, NOT Get-MailboxPermission
Get-RecipientPermission -Identity "helpdesk@domain.com" |
    Where-Object {$_.AccessRights -eq "SendAs"} |
    Select-Object Trustee,AccessRights

Grant Send As via PowerShell

Add-RecipientPermission -Identity "helpdesk@domain.com" `
    -Trustee "jsmith@domain.com" `
    -AccessRights SendAs `
    -Confirm:$false

Send on Behalf — the third permission type

Send on Behalf is different from Send As. With Send As, the recipient sees helpdesk@domain.com as the sender. With Send on Behalf, they see "jsmith on behalf of helpdesk". Send on Behalf is configured on the mailbox object, not via recipient permissions:

# Grant Send on Behalf
Set-Mailbox -Identity "helpdesk@domain.com" `
    -GrantSendOnBehalfTo @{Add="jsmith@domain.com"}

# View current Send on Behalf delegates
Get-Mailbox -Identity "helpdesk@domain.com" |
    Select-Object -ExpandProperty GrantSendOnBehalfTo

Propagation delays and Outlook cache

Even with permissions correctly set, users report it's "not working" when the actual problem is propagation lag or a stale Outlook cache.

• Exchange Online propagation: Full Access can take up to 60 minutes. Send As typically propagates in under 15 minutes.
• Outlook cache: Even after propagation, Outlook's local cache may not reflect the change until restarted.

Force Outlook to pick up changes without waiting: close Outlook completely, then reopen it. If it still doesn't appear, run Outlook in safe mode (outlook.exe /safe) to rule out add-in interference, then clear the Outlook profile and re-add the account.

Shared mailbox license requirements

Shared mailboxes in Exchange Online don't require a license as long as they're under 50GB. Above 50GB, or if you enable features like litigation hold or In-Place Archive, a license is required. A common failure pattern: a shared mailbox was converted from a regular user mailbox and inherited a license, which was later removed, causing intermittent access failures.

# Check if the shared mailbox has a license
Get-MsolUser -UserPrincipalName "helpdesk@domain.com" |
    Select-Object DisplayName,IsLicensed,Licenses

# Verify the mailbox type is actually Shared
Get-Mailbox -Identity "helpdesk@domain.com" |
    Select-Object DisplayName,RecipientTypeDetails

Hybrid environment considerations

In hybrid deployments, shared mailbox permissions set on-premises don't automatically sync to Exchange Online and vice versa. The mailbox location determines where permissions must be set.

# Check where the mailbox lives
Get-Mailbox -Identity "helpdesk@domain.com" |
    Select-Object DisplayName,Database,ExchangeVersion,RecipientTypeDetails

# For cloud-hosted mailboxes, check in Exchange Online PowerShell
# For on-premises mailboxes, check via on-premises Exchange Management Shell

If the shared mailbox is cloud-hosted but the user delegates are on-premises, you must grant permissions in Exchange Online. The Active Directory sync does not replicate Exchange Online mailbox permissions back to on-premises Exchange.

Summary

Shared mailbox permission failures almost always come down to four things: the permission wasn't actually applied (verify with PowerShell, not the portal), AutoMapping behavior doesn't match the client setup, Send As and Full Access are separate permissions that need separate grants, or there's a propagation delay that patience and an Outlook restart will fix. Run through the verification steps in order and you'll isolate the actual problem in under 10 minutes.