Full Access, Send As and Send on Behalf in Exchange Online with PowerShell

Exchange Online has three separate mailbox delegation permissions: Full Access opens the mailbox, Send As sends mail that appears to come from it, and Send on Behalf sends mail marked "Delegate on behalf of Mailbox". You grant Full Access with Add-MailboxPermission, Send As with Add-RecipientPermission, and Send on Behalf with Set-Mailbox -GrantSendOnBehalfTo. Each is audited with its own command, so a complete review always checks all three.

Who this is for and what you will have at the end

This guide is for Exchange Online administrators who handle requests such as "give the assistant access to the manager's mailbox", "let the support team reply as support@" or "who can send as the CEO?". It assumes you can connect to Exchange Online PowerShell.

At the end you will know exactly what each permission allows, you will have tested commands to grant and remove each one for users and groups, a way to control Outlook automapping, scripts that report every delegation in the tenant, and a troubleshooting table for the errors delegates report. If you are setting up access to a leaver's mailbox, Convert a user mailbox to a shared mailbox covers the steps before permissions.

The three permissions compared

Three rules sit on top of this table:

• If a user has both Send As and Send on Behalf, Send As is always used.
• Full Access granted on a mailbox that is hidden from address lists doesn't let the delegate open it, and Send As or Send on Behalf on a hidden mailbox doesn't let the delegate send from it.
• In Exchange Online, a user with Full Access can see all items in the mailbox, including calendar items marked as private.

The last point matters for executive mailboxes. If an assistant should manage the calendar but not see private appointments, use calendar folder permissions instead of Full Access; see Calendar permissions in Exchange Online.

Prerequisites

• The permissions listed under the "Mailbox settings" entry in Microsoft's Feature permissions in Exchange Online article.
• The Exchange Online PowerShell module.
• Delegates who are mailbox users, mail users, or mail-enabled security groups. A security group that isn't mail-enabled can be selected but doesn't work.

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com

Grant and remove Full Access

The basic grant:

Add-MailboxPermission -Identity "Terry Adams" -User raymonds@contoso.com -AccessRights FullAccess -InheritanceType All

-InheritanceType All is the default, so the permission applies to every folder in the mailbox. To remove it later, use the same parameters with Remove-MailboxPermission:

Remove-MailboxPermission -Identity "Terry Adams" -User raymonds@contoso.com -AccessRights FullAccess -InheritanceType All

Control automapping

Automapping uses Autodiscover to add a mailbox to the delegate's Outlook profile automatically. It is on by default for individual users. It doesn't work for groups, because Autodiscover doesn't expand security group membership.

To grant Full Access without automapping:

Add-MailboxPermission -Identity support@contoso.com -User ana@contoso.com -AccessRights FullAccess -InheritanceType All -AutoMapping $false

You can't turn automapping off on an existing permission. Remove the permission, then add it again with -AutoMapping $false. Users then add the mailbox manually in Outlook. When a mailbox is added through Outlook's advanced account settings, only the primary mailbox appears; if the delegate also needs the archive, add the mailbox as a second account in the same profile.

Use a group for larger teams

Add-MailboxPermission -Identity "Helpdesk Tickets" -User helpdesk-team@contoso.com -AccessRights FullAccess -InheritanceType All

A single mailbox can hold up to 500 permission entries. A mail-enabled security group counts as one entry however many members it has, so use groups when access needs to scale. The trade-off is that members don't get automapping.

Grant and remove Send As

Add-RecipientPermission -Identity support@contoso.com -Trustee ana@contoso.com -AccessRights SendAs -Confirm:$false
Remove-RecipientPermission -Identity support@contoso.com -Trustee ana@contoso.com -AccessRights SendAs -Confirm:$false

SendAs is the only valid value for -AccessRights here. Add-RecipientPermission has a built-in confirmation prompt, which is why scripts need -Confirm:$false. The target can be a mailbox, a mail user, a contact, a distribution group or a dynamic distribution group, and the trustee can be a group:

Add-RecipientPermission -Identity "Contoso Printer Support" -Trustee "Printer Support" -AccessRights SendAs -Confirm:$false

Grant and remove Send on Behalf

Send on Behalf isn't a separate cmdlet; it is the GrantSendOnBehalfTo property on the recipient. Use Set-Mailbox for mailboxes, Set-DistributionGroup for distribution groups and mail-enabled security groups, Set-DynamicDistributionGroup for dynamic groups and Set-UnifiedGroup for Microsoft 365 groups.

The value works in three ways, and mixing them up is the most common mistake:

# Replaces the whole list with one delegate
Set-Mailbox -Identity seanc@contoso.com -GrantSendOnBehalfTo hollyh@contoso.com
 
# Adds or removes delegates without touching the others
Set-Mailbox -Identity "Contoso Executives" -GrantSendOnBehalfTo @{Add="tempassistants@contoso.com"}
Set-Mailbox -Identity "Contoso Executives" -GrantSendOnBehalfTo @{Remove="tempassistants@contoso.com"}
 
# Clears every delegate
Set-Mailbox -Identity seanc@contoso.com -GrantSendOnBehalfTo $null

Always use the @{Add=...} form when a mailbox already has delegates, or you will silently remove them. For shared mailboxes, Send on Behalf isn't available in the Exchange admin center, so PowerShell is the only way to set it.

Keep a copy in the mailbox's Sent Items

By default, a message a delegate sends as or on behalf of a mailbox is saved only in the delegate's own Sent Items. For a shared mailbox or a manager's mailbox that is usually the wrong place. Configure the mailbox (not the delegate) to keep a copy:

Set-Mailbox -Identity support@contoso.com -MessageCopyForSentAsEnabled $true
Set-Mailbox -Identity support@contoso.com -MessageCopyForSendOnBehalfEnabled $true

Set the value back to $false to turn it off.

Grant permissions in the Exchange admin center

For one-off changes, go to Recipients > Mailboxes, select the mailbox and choose Mailbox delegation. The three sections are Send as, Send on behalf and Read and manage (Full Access); select Edit under one of them, then Add members, pick users or groups, and select Save > Confirm. You can also select several mailboxes at once and use Mailbox delegation to add the same delegate with the permission types you pick.

For groups, go to Recipients > Groups, select the group, then Settings > Manage delegates to set Send as or Send on behalf.

Audit permissions

One mailbox

Get-MailboxPermission -Identity support@contoso.com | Where-Object {$_.AccessRights -like 'Full*'} | Format-Table User,Deny,IsInherited,AccessRights -AutoSize
Get-RecipientPermission -Identity support@contoso.com
Get-Mailbox -Identity support@contoso.com | Format-List GrantSendOnBehalfTo

In the Full Access output, NT AUTHORITY\SELF is the mailbox's own entry and is always present. Entries with IsInherited set to True are inherited rather than granted on this mailbox. The entries that matter are the explicit ones.

Everything one user can send as

Get-RecipientPermission -Trustee "Kim Akers"

This lists every recipient the user can send as. Microsoft documents that the -Trustee filter can miss entries when the trustee's security identifiers have changed, so for an important review also run the tenant-wide report below.

Tenant-wide report

Microsoft recommends the Get-EXO* versions of these cmdlets in Exchange Online PowerShell.

$mailboxes = Get-Mailbox -ResultSize Unlimited
 
# Full Access granted by administrators
$fullAccess = foreach ($m in $mailboxes) {
    Get-EXOMailboxPermission -Identity $m.UserPrincipalName |
        Where-Object { $_.AccessRights -like '*FullAccess*' -and -not $_.IsInherited -and $_.User -ne 'NT AUTHORITY\SELF' } |
        Select-Object Identity, User, AccessRights
}
$fullAccess | Export-Csv C:\Temp\FullAccess.csv -NoTypeInformation
 
# Send As
Get-EXORecipientPermission -ResultSize Unlimited -AccessRights SendAs | Export-Csv C:\Temp\SendAs.csv -NoTypeInformation
 
# Send on Behalf
$mailboxes | Where-Object { $_.GrantSendOnBehalfTo } |
    Select-Object DisplayName, @{n='SendOnBehalf';e={$_.GrantSendOnBehalfTo -join '; '}} |
    Export-Csv C:\Temp\SendOnBehalf.csv -NoTypeInformation

The Send As export includes each mailbox's own NT AUTHORITY\SELF entry; filter those rows out when you review it. Run the report before and after a leaver process or a reorganization, and keep the files as evidence of who had access.

Troubleshooting

Migrations deserve a separate check, because delegation depends on where both the owner and the delegate live. The tenant-to-tenant migration architecture guide covers how mailbox permissions are handled in cross-tenant moves.

Summary checklist

• Read the mailbox: Full Access with Add-MailboxPermission.
• Reply as the mailbox: Send As with Add-RecipientPermission -Confirm:$false.
• Reply showing the delegate: Send on Behalf with -GrantSendOnBehalfTo @{Add=...}.
• Groups scale past the 500-entry limit but don't automap.
• Turn on MessageCopyForSentAsEnabled and MessageCopyForSendOnBehalfEnabled for shared mailboxes.
• Remember that Full Access exposes private calendar items.
• Audit all three permissions; one command never shows the whole picture.

References

• Manage permissions for recipients in Exchange Online
• Add-MailboxPermission
• Add-RecipientPermission
• Get-RecipientPermission
• Get-EXOMailboxPermission
• Get-EXORecipientPermission
• Get-Mailbox
• Automatically save sent items in delegator's mailbox in Exchange Online
• Mailboxes aren't automapped to Outlook profile
• Can't send email message when Full Access is granted to a shared mailbox
• About shared mailboxes in Microsoft 365
• Connect to Exchange Online PowerShell