Full Access vs Send As vs Send on Behalf: What’s the Difference?
Three grants, three storage locations, three audit commands. What each one really allows, and how they drift.
The short answer
Full Access, Send As and Send on Behalf are three independent grants. Full Access lets a delegate open and work in the mailbox. Send As and Send on Behalf let a delegatesend from it. Having one does not give you the others, and each is stored and audited in a different place, which is why permission drift is easy to miss.
| Permission | What it allows | Where it lives | Common mistakes | How Tenvero can audit it |
|---|---|---|---|---|
| Full Access | Open the mailbox and read, create, change and delete items. Does not by itself allow sending. | Mailbox permission (Get-MailboxPermission) | Granted directly to individuals instead of through a group; left in place after a role change or offboarding; assumed to imply Send As. | Compares each trustee with the intended group and flags unmanaged direct access. |
| Send As | Send a message that appears to come from the mailbox itself, with no sign of the delegate. | Recipient permission (Get-RecipientPermission) | Granted to someone who only needed to read mail; orphaned entries for deleted accounts; forgotten because it is not in the mailbox permission list. | Reads recipient permissions separately and flags disabled or orphaned trustees. |
| Send on Behalf | Send a message that shows both the delegate and the mailbox ("Delegate on behalf of Mailbox"). | Property of the mailbox (GrantSendOnBehalfTo) | Confused with Send As; never checked because it is a property, not a permission entry. | Reads the mailbox property and compares it with the intended access model. |
Reading each one in PowerShell
The three grants need three different read commands:
# Full Access
Get-MailboxPermission -Identity [email protected] |
Where-Object { $_.AccessRights -contains 'FullAccess' -and -not $_.IsInherited -and $_.User -ne 'NT AUTHORITY\SELF' }
# Send As
Get-RecipientPermission -Identity [email protected] |
Where-Object { $_.AccessRights -contains 'SendAs' -and $_.Trustee -ne 'NT AUTHORITY\SELF' }
# Send on Behalf
(Get-Mailbox -Identity [email protected]).GrantSendOnBehalfToReferences:Get-MailboxPermission,Get-RecipientPermission,Set-Mailbox (GrantSendOnBehalfTo).
Which one should a delegate get?
- Read and manage the mailbox only: Full Access.
- Send so the message looks like it came from the team: Send As (plus Full Access if they also work in the mailbox).
- Send while staying visible as the actual sender: Send on Behalf.
Why one PowerShell audit isn't enough
You can run those commands once and get a correct answer for today. The answer then decays: people change roles, accounts are disabled, someone is granted access directly "just for this week". The question that matters is not only who has access but why they have it: is the grant part of the intended group-based model, or is it drift?
Where Tenvero fits
Tenvero turns shared-mailbox delegation from a one-time permission change into an auditable desired state that can be checked and reconciled continuously. You define the intended access model with AD or Entra security groups, Tenvero compares it with the actual Full Access, Send As and Send on Behalf entries in Exchange, and shows direct, disabled or orphaned access before anything is changed. For a one-off check, use thefree audit script generator.
Tenvero compares the intended group-based access model with actual Exchange permissions and shows the drift.
Start 30-day trial