Exchange Online mailbox permissions: fixing Full Access, Send As and Send on Behalf errors

A delegate can see the shared mailbox, but every message they send from it bounces. Or the mailbox won't open at all. In Exchange Online these problems nearly always come down to three things: which delegate permission was granted, who it was granted to, and which address the client used as the sender. In this post I'll match each error to its cause, fix it with Exchange Online PowerShell and show how to prove the fix.

Symptoms#

When someone sends from a mailbox without the right permission, Outlook returns an NDR that says:

You do not have the permission to send the message on behalf of the specified user.

The diagnostic information for administrators shows the server-side reason:

554 5.2.0 STOREDRV.Submission.Exception:SendAsDeniedException.MapiExceptionSendAsDenied; Failed to process message due to a permanent exception with message Cannot submit message.

• Applications and scripts that sign in with SMTP AUTH as one account and send from another address are rejected with 5.7.60 SMTP; Client does not have permissions to send as this sender.
• Opening the other mailbox in classic Outlook fails with Cannot expand the folder. The set of folders cannot be opened. You do not have permission to log on.
• Sending works in Outlook on the web but fails in classic Outlook.
• Messages are delivered, but recipients see "Jane on behalf of Sales" when they should see Sales.

Why it happens#

Exchange Online has three delegate permissions, and none of them includes the others:

The usual causes behind the errors above:

• Full Access only. The mailbox opens (often automapped), so users assume they can send from it. They can't.
• Send on Behalf instead of Send As. The mail goes out, but with "on behalf of". If a delegate has both permissions, Microsoft documents that Send As is always used.
• The mailbox is hidden from address lists. Microsoft documents that delegates can't open a hidden mailbox with Full Access or send from it with Send As or Send on Behalf.
• The wrong kind of delegate. Delegates must be users (mailboxes or mail users with accounts) or mail-enabled security groups. Distribution groups are accepted only for Send on Behalf.
• A stale sender address. Outlook's Auto-Complete list can supply an old entry for the mailbox, so the server refuses it even though the permission is correct. That's why Outlook on the web often works when classic Outlook doesn't.
• The change hasn't taken effect yet. Permission changes aren't instant, and Outlook caches what it knows.
• Hybrid. When the mailbox and the delegate live in different environments, other rules apply. Microsoft Entra Connect doesn't synchronize Send As, for example. See Cross-premises permissions in Exchange hybrid.

How to fix it#

1. List what's actually granted. Connect to Exchange Online PowerShell and check all three permissions, plus whether the mailbox is hidden:
   PowerShell

   Connect-ExchangeOnline
   $mbx = "sales@contoso.com"
   
   # Full Access (explicit entries only)
   Get-MailboxPermission -Identity $mbx |
       Where-Object { -not $_.IsInherited -and $_.User -notlike "NT AUTHORITY*" } |
       Format-Table User, AccessRights, Deny -AutoSize
   
   # Send As
   Get-RecipientPermission -Identity $mbx |
       Where-Object { $_.Trustee -notlike "NT AUTHORITY*" } |
       Format-Table Trustee, AccessRights, AccessControlType -AutoSize
   
   # Send on Behalf, and whether the mailbox is hidden
   Get-Mailbox -Identity $mbx | Format-List RecipientTypeDetails, GrantSendOnBehalfTo, HiddenFromAddressListsEnabled

2. Grant the permission the user really needs. Pick Send As when mail should come from the mailbox itself, and Send on Behalf when recipients should see who sent it:
   PowerShell

   # Send As
   Add-RecipientPermission -Identity sales@contoso.com -Trustee jane@contoso.com -AccessRights SendAs -Confirm:$false
   
   # Send on Behalf
   Set-Mailbox -Identity sales@contoso.com -GrantSendOnBehalfTo @{Add="jane@contoso.com"}
   
   # Full Access without automapping it into Outlook
   Add-MailboxPermission -Identity sales@contoso.com -User jane@contoso.com -AccessRights FullAccess -InheritanceType All -AutoMapping $false
   
   # Groups: Send As works the same way; Send on Behalf is a group property
   Add-RecipientPermission -Identity "Sales Team" -Trustee jane@contoso.com -AccessRights SendAs -Confirm:$false
   Set-DistributionGroup -Identity "Sales Team" -GrantSendOnBehalfTo @{Add="jane@contoso.com"}

   In the Exchange admin center, the same settings are under Recipients › Mailboxes: select the mailbox and open Mailbox delegation, where Full Access is called Read and manage. Microsoft notes that the EAC doesn't offer Send on Behalf for shared mailboxes, so use Set-Mailbox for those.
3. Deal with hidden mailboxes. If HiddenFromAddressListsEnabled is True and delegates need it, unhide it with Set-Mailbox -HiddenFromAddressListsEnabled $false. For a mailbox synchronized from on-premises, change it there with Set-RemoteMailbox.
4. Fix the sender address in Outlook. In classic Outlook, start a new message, select From › Other email address, select From again, switch to the Global Address List and pick the mailbox. Then delete the old suggestion from the Auto-Complete list so it isn't offered again.
5. Fix applications that use SMTP AUTH. For 5.7.60, grant Send As on the From address to the account the application signs in with, or make the From address match that account. If the sign-in itself fails, see SMTP AUTH, relay connectors and 5.7.57.
6. Restart Outlook and allow time. Give the change a while to apply before you change anything else, then retest.

Verify the fix#

Check the entry you added. For Send As, good looks like one line with SendAs and Allow:

Get-RecipientPermission -Identity sales@contoso.com -Trustee jane@contoso.com |
    Format-Table Trustee, AccessRights, AccessControlType -AutoSize

Get-MessageTraceV2 -SenderAddress sales@contoso.com -StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date) |
    Format-Table Received, SenderAddress, RecipientAddress, Subject, Status

• Have the delegate send a test from the shared address to an external mailbox. Recipients should see the mailbox (Send As) or "Jane on behalf of Sales" (Send on Behalf).
• Message trace should show the test as Delivered, with the shared address as the sender. If it isn't listed at all, the message was refused at submission. Check the NDR again. My message trace guide explains how to read the results.
• For Full Access, the delegate should be able to open the mailbox in Outlook on the web with Open another mailbox.

Prevent it next time#

• Decide per mailbox whether people send as it or on behalf of it, and grant only that permission.
• Grant permissions to mail-enabled security groups for teams. Remember that group-based Full Access never automaps; see Shared mailbox automapping in Outlook, which also covers keeping sent items in the shared mailbox.
• Give admin and helpdesk accounts Full Access with -AutoMapping $false.
• Don't hide a shared mailbox from address lists if delegates need to send from it.
• For the on-premises version of these errors, see 554 5.2.0 SendAsDenied on Exchange Server.

References#

• Manage permissions for recipients in Exchange Online (Microsoft Learn)