Exchange Online Mailbox Permissions: Full Access vs Send As vs Send on Behalf [2026]

In day-to-day Microsoft 365 administration, configuring mailbox delegation is one of the most frequent requests submitted to IT helpdesks. Whether provisioning access to a department shared mailbox (e.g., finance@company.com), granting an executive assistant rights to a CEO’s calendar, or configuring an automated ERP notification sender, assigning the correct permission tier is critical for both security and operational stability.

Yet mailbox delegation in Exchange Online is notorious for subtle architectural traps: Outlook desktop clients freezing due to AutoMapping overload, sent items disappearing into delegates’ personal folders instead of the shared mailbox, and baffling 550 5.7.60 Send As Denied errors caused by cloud directory token latency.

This enterprise runbook provides an architectural breakdown of Full Access vs Send As vs Send on Behalf, details how to prevent Outlook client crashes by disabling AutoMapping, and delivers production-tested PowerShell automation scripts for modern Exchange Online environments.

The Exchange Online Permission Hierarchy: Quick Matrix

Deep Dive: The AutoMapping Trap in Outlook Desktop

How AutoMapping Works Internally

When an administrator grants a user Full Access via the Microsoft 365 Admin Center or the Exchange Admin Center (EAC), Exchange Online automatically sets the parameter -AutoMapping $true behind the scenes.

When the delegate’s Outlook desktop client launches, it connects to the Autodiscover v2 endpoint (https://outlook.office365.com/autodiscover/autodiscover.json). Exchange Online injects an <AlternativeMailbox> XML node into the Autodiscover payload containing the GUID of every mailbox where the user has Full Access.

Outlook immediately discovers these GUIDs and mounts the additional mailboxes beneath the user’s primary OST file.

Why AutoMapping Cripples Outlook in Enterprise Environments

While convenient for a single shared mailbox, AutoMapping causes severe operational failure when users (such as executive assistants, dispatchers, or billing coordinators) belong to multiple mailboxes:

• OST Cache File Bloat: By default, Outlook attempts to download and cache local copies of automapped mailboxes. A 50 GB OST file threshold is quickly breached, causing Outlook to crawl or crash on startup.
• Search Indexing Lockups: Windows Desktop Search becomes overwhelmed indexing thousands of concurrent items across multiple shared folders.
• Ghost Mailbox Removal Lag: When an admin removes Full Access in the cloud, Outlook often continues trying to authenticate against the automapped mailbox for days, popping persistent credential prompts.

The Remediation: Disabling AutoMapping with PowerShell

In enterprise best practice, always grant Full Access with AutoMapping disabled, and have users manually add the shared mailbox via Account Settings or access it via Outlook on the Web (OWA) using “Open another mailbox”.

# Connect to Exchange Online
Connect-ExchangeOnline

# Grant Full Access with AutoMapping explicitly disabled
Add-MailboxPermission -Identity "finance@yourdomain.com" `
    -User "sarah.admin@yourdomain.com" `
    -AccessRights FullAccess `
    -InheritanceType All `
    -AutoMapping $false

How to Remove AutoMapping from an Existing Mailbox Permission

Exchange Online does not allow toggling AutoMapping on an existing permission entry. You must remove the permission and re-apply it with -AutoMapping $false:

$SharedMailbox = "finance@yourdomain.com"
$DelegateUser  = "sarah.admin@yourdomain.com"

# 1. Strip the existing permission (which had AutoMapping enabled)
Remove-MailboxPermission -Identity $SharedMailbox `
    -User $DelegateUser `
    -AccessRights FullAccess `
    -Confirm:$false

# 2. Re-grant Full Access with AutoMapping disabled
Add-MailboxPermission -Identity $SharedMailbox `
    -User $DelegateUser `
    -AccessRights FullAccess `
    -InheritanceType All `
    -AutoMapping $false

Configuring Send As Permissions (and Solving the 60-Minute Replication Delay)

Granting Send As

Notice that Send As uses Add-RecipientPermission, not Add-MailboxPermission. This is because Send As is evaluated by the Exchange transport pipeline across all recipient object types (shared mailboxes, distribution groups, and mail-enabled security groups):

# Grant Send As permission to a delegate
Add-RecipientPermission -Identity "finance@yourdomain.com" `
    -Trustee "sarah.admin@yourdomain.com" `
    -AccessRights SendAs `
    -Confirm:$false

The 60-Minute Replication Delay & Latency Gotcha

One of the most common helpdesk escalations occurs when an admin grants Send As, calls the user to test, and the user immediately receives:

Remote Server returned:
550 5.7.60 Send As denied; Failed to send on behalf of the specified identity.

The Root Cause: Exchange Online runs on a distributed cloud directory architecture. While Add-RecipientPermission commits to the regional Exchange Online Directory Service (EXODS) within seconds, the front-end Client Access servers (CAS) and the user’s active Kerberos / OAuth access tokens cache the previous permission matrix.

Token TTL (Time-To-Live) in Exchange Online is typically 15 to 60 minutes. To verify whether the permission is working without waiting for Outlook desktop client cache replication:

1. Have the user sign in to Outlook on the Web (OWA) at outlook.office.com in an InPrivate / Incognito window.
2. Compose a new email, click Options > Show From.
3. Select the shared mailbox address in the From field and send a test message. OWA bypasses the local MAPI cache and queries the cloud transport layer directly.

Configuring Send on Behalf

Send on Behalf is ideal for administrative assistants managing executive mailboxes where transparency is legally or procedurally required. The recipient sees: “Sarah Admin on behalf of John Executive”.

Unlike Send As, Send on Behalf is stored as a multi-valued attribute (GrantSendOnBehalfTo) directly on the mailbox object:

# Grant Send on Behalf without overwriting existing delegates
Set-Mailbox -Identity "john.ceo@yourdomain.com" `
    -GrantSendOnBehalfTo @{Add = "sarah.admin@yourdomain.com"}

# Verify existing delegates with Send on Behalf
(Get-Mailbox -Identity "john.ceo@yourdomain.com").GrantSendOnBehalfTo

The “Missing Sent Items” Problem: Fixing Sent Items Retention

By default in Exchange Online, when Sarah sends an email using Send As from finance@yourdomain.com, a copy of that sent email is saved only in Sarah’s personal Sent Items folder. Other delegates sharing the finance mailbox have no visibility into what was sent.

To ensure full team auditability and compliance, configure Exchange Online to automatically place a copy of sent messages into the shared mailbox’s Sent Items folder:

# Retain a copy in the shared mailbox for both Send As and Send on Behalf
Set-Mailbox -Identity "finance@yourdomain.com" `
    -MessageCopyForSentAsEnabled $true `
    -MessageCopyForSendOnBehalfEnabled $true

# Verify configuration
Get-Mailbox -Identity "finance@yourdomain.com" | `
    Select-Object Name, MessageCopyForSentAsEnabled, MessageCopyForSendOnBehalfEnabled

Enterprise PowerShell Script: Complete Mailbox Delegation Audit

Run this production script to audit all delegates across your tenant, identify non-standard permissions, and flag mailboxes with AutoMapping enabled:

<#
.SYNOPSIS
    Audits Exchange Online Shared Mailbox Delegation & AutoMapping Status
.DESCRIPTION
    Scans all shared mailboxes, exports Full Access and Send As permissions,
    and flags accounts with AutoMapping active.
#>

$Report = [System.Collections.Generic.List[PSCustomObject]]::new()
$SharedMailboxes = Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited

foreach ($MB in $SharedMailboxes) {
    # Audit Full Access Permissions (exclude NT AUTHORITY and self)
    $FullAccess = Get-MailboxPermission -Identity $MB.UserPrincipalName | 
        Where-Object { 
            $_.User -notlike "NT AUTHORITY\*" -and 
            $_.User -ne $MB.UserPrincipalName -and 
            $_.IsInherited -eq $false 
        }

    foreach ($Perm in $FullAccess) {
        $Report.Add([PSCustomObject]@{
            MailboxName    = $MB.DisplayName
            MailboxUPN     = $MB.UserPrincipalName
            Delegate       = $Perm.User
            PermissionType = "FullAccess"
            AutoMapping    = $Perm.AutoMapping
        })
    }

    # Audit Send As Permissions
    $SendAs = Get-RecipientPermission -Identity $MB.UserPrincipalName | 
        Where-Object { 
            $_.Trustee -notlike "NT AUTHORITY\*" -and 
            $_.Trustee -ne $MB.UserPrincipalName 
        }

    foreach ($Perm in $SendAs) {
        $Report.Add([PSCustomObject]@{
            MailboxName    = $MB.DisplayName
            MailboxUPN     = $MB.UserPrincipalName
            Delegate       = $Perm.Trustee
            PermissionType = "SendAs"
            AutoMapping    = "N/A"
        })
    }
}

# Export report to CSV
$Report | Export-Csv -Path "C:\Reports\Exchange_Delegation_Audit.csv" -NoTypeInformation
Write-Host "[+] Audit complete! Exported $($Report.Count) permission entries to C:\Reports\Exchange_Delegation_Audit.csv" -ForegroundColor Green

Summary & Operational Takeaways

Mastering mailbox delegation in Exchange Online comes down to three operational disciplines:

1. Never default to AutoMapping: For any user managing more than two shared mailboxes, always use -AutoMapping $false to protect Outlook desktop performance.
2. Always enable Sent Items copy: Run Set-Mailbox -MessageCopyForSentAsEnabled $true immediately whenever provisioning a new department shared mailbox.
3. Test via OWA first: When troubleshooting Send As permission latency, use Outlook on the Web in an InPrivate session to bypass client-side token caching.

For more production Exchange management runbooks, check out our guide to Exchange Online NDR Troubleshooting (550 5.1.1, 550 5.7.705 & 554 5.4.14) and our reference guide on 25 Essential Exchange Online PowerShell Commands.