Helpdesk: "Alex was granted Send As on info@ yesterday. In Outlook he picks info@ in From and gets 'You do not have the permission to send the message on behalf of the specified user.' Maria has Send As on the All Staff distribution group and the same NDR. Jordan can send as billing@ in Outlook on the web, but classic Outlook still fails. Can you remove and re-add Send As, or rebuild their Outlook profiles?"
Don't re-grant yet. Send As is a different permission from Full Access, and "permission not working" usually means one of five things Microsoft already documents: the user only has Full Access (or only Send on Behalf), Send As was granted on the wrong object or to the wrong trustee type, the mailbox/group is hidden from the address list, Outlook is using a cached Offline Address Book entry in the From box, or the From address is a distribution group / Microsoft 365 group with its own delegation rules. DEVTO_58 Step 7 covers the shared-mailbox "shows up but can't send" sidebar in one table; this post is the full Send As / Send on Behalf triage for shared mailboxes, user mailboxes, and groups.
If the real problem is "the shared mailbox isn't in Outlook at all," start with Shared Mailbox Not Showing in Outlook. If you need a monthly inventory of who has Full Access and Send As, use A Monthly Exchange Online Hygiene Check. This post covers "I was told I have Send As, but sending fails" — in Outlook, in Outlook on the web, or only on one client.
TL;DR
- Full Access does not include Send As. Microsoft's shared-mailbox and recipient-permission docs are explicit: Full Access opens the mailbox; Send As (or Send on Behalf) is required to send. Granting Full Access alone is the most common ticket that looks like "Send As broken."
- Send As and Send on Behalf are different. Send As looks like the mailbox/group itself. Send on Behalf shows "User on behalf of Mailbox". If both are present, Microsoft says Send As is always used.
-
Hidden from the GAL breaks desktop Send As. Microsoft says Send As and Send on Behalf do not work in Outlook desktop when
HiddenFromAddressListsEnabledisTrue, because those permissions require the mailbox to be visible via the Global Address List. - Works in Outlook on the web, fails in Outlook? Often a cached From address. Microsoft Support: use From → Other Email Address, switch the address book to the GAL, and pick the mailbox again — not the autocomplete suggestion from the Offline Address Book.
- Groups can hold Send As, and groups can be the From address. Trustees for Send As are mailboxes with user accounts, mail users with accounts, or mail-enabled security groups. Distribution groups, dynamic distribution groups, mail-enabled security groups, and Microsoft 365 groups can also receive Send As so people can send as the group.
-
Sent Items in the wrong mailbox is not a Send As failure. Default behavior saves Send As mail in the sender's Sent Items. Fix with
MessageCopyForSentAsEnabled/MessageCopyForSendOnBehalfEnabled(new Outlook: mailbox-side settings only).
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Exact client, exact error/NDR, how From was chosen | "Send As broken" with no client or From method |
| 2. Grant type clear | Ticket asks for Send As, Send on Behalf, or both — not "access" | Admin granted Full Access; user expected to send |
| 3. Permission on the object |
Get-RecipientPermission lists SendAs for the trustee (or GrantSendOnBehalfTo for SOBO) |
Permission never saved, wrong mailbox, or wrong group |
| 4. Trustee type valid | Trustee is a user mailbox / mail user / mail-enabled security group | Grant looks fine in EAC but never applies to members |
| 5. Not hidden from GAL |
HiddenFromAddressListsEnabled is False when using Outlook desktop |
OWA works; classic/new Outlook desktop fails |
| 6. From uses live GAL | From picked from GAL (or OWA), not stale OAB autocomplete | Permission confirmed in PowerShell; Outlook NDR only |
| 7. Right recipient type | Shared / user mailbox vs DG / MESG / M365 group rules understood | "Send as the DL" ticket treated like a shared mailbox |
Write down the sender's UPN, the From address they want to use, whether that address is a shared mailbox, user mailbox, distribution group, mail-enabled security group, or Microsoft 365 group, every client they tried (classic Outlook, new Outlook, Outlook on the web, Mac), the exact error or NDR text, and how the permission was granted (EAC mailbox delegation, Microsoft 365 admin center, PowerShell Add-RecipientPermission, or a group trustee). Most tickets are solved by the grant-type and From-method fields.
Step 1: Capture the exact symptom (read-only)
| What the user sees | Most likely layer |
|---|---|
| Opens the shared mailbox fine; send fails with permission / NDR | Full Access without Send As (or only Send on Behalf in a profile that needs Send As) |
| Dialog: "You do not have the permission to send the message on behalf of the specified user" (often Online mode) | Missing Send As, wrong From identity, or hidden-from-GAL on desktop |
NDR in Inbox with 0x80070005 / "do not have the permission to send … on behalf" (Cached mode) |
Same server-side permission story; classic Outlook surfaces it as NDR |
| Fails in Outlook desktop; works in Outlook on the web | Cached From / OAB (Step 6), or HiddenFromAddressListsEnabled (Step 5) |
| Works for one user in a MESG, fails for another | Membership, not the Send As ACE itself |
| Can send as a shared mailbox, can't send as a distribution group | Group Send As not granted on the group object (Step 7) |
| Send succeeds; copy only in the user's Sent Items | Expected default — Sent Items config, not a permission failure (Step 8) |
| From shows "Alex on behalf of info@" and they wanted pure Send As | They have Send on Behalf (or both; Send As should win if both exist — verify the grant) |
Microsoft's troubleshooting article for Full Access without Send As matches the shared-mailbox "I can open it but can't send" case: Exchange requires Send As to send as that mailbox in the configurations they describe. Don't treat every "on behalf of" error string as proof the user was granted Send on Behalf — Outlook often uses that wording for missing Send As too.
Step 2: Name the grant you actually need (read-only)
| Permission | What the recipient sees | Opens mailbox? | Notes from Microsoft |
|---|---|---|---|
| Full Access | n/a (not a send permission) | Yes | Cannot send unless Send As or Send on Behalf also exists |
| Send As | Looks like the mailbox/group sent it | No (by itself) | No "on behalf of" marker |
| Send on Behalf | "Delegate on behalf of Mailbox/Group" | No (by itself) | Replies go to the mailbox/group, not the delegate |
| Both Send As and Send on Behalf | Send As behavior | — | Microsoft: Send As is always used when both exist |
Shared mailboxes almost always need Full Access + Send As for day-to-day team use (Microsoft's create-shared-mailbox article says both are required for successful shared mailbox operation). A pure Send As grant (no Full Access) is valid when the user only needs to send as the address without reading the inbox — common for distribution groups and some helpdesk aliases.
Send on Behalf for shared mailboxes is available via Set-Mailbox -GrantSendOnBehalfTo (and in newer EAC flows); older notes that "EAC can't grant SOBO on shared mailboxes" are stale for some tenants — verify in your EAC, and use PowerShell when the UI lacks the control.
Step 3: Confirm the permission on the right object (read-only)
Exchange Online PowerShell, signed in with an account that can read recipients:
# Read-only. Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
$from = 'info@contoso.com' # mailbox or group in the From box
$user = 'alex@contoso.com' # person trying to send
# What is the From address?
Get-Recipient -Identity $from | Select-Object DisplayName, PrimarySmtpAddress, RecipientTypeDetails, HiddenFromAddressListsEnabled
# For mailboxes: hidden flag + Send on Behalf list + Sent Items copy flags
Get-Mailbox -Identity $from -ErrorAction SilentlyContinue | Select-Object `
DisplayName, PrimarySmtpAddress, RecipientTypeDetails,
HiddenFromAddressListsEnabled, GrantSendOnBehalfTo,
MessageCopyForSentAsEnabled, MessageCopyForSendOnBehalfEnabled
# Who has Send As on this recipient?
Get-RecipientPermission -Identity $from |
Where-Object { $_.Trustee -notlike 'NT AUTHORITY\*' } |
Select-Object Identity, Trustee, AccessRights
# Is this specific user (or a group they belong to) listed?
Get-RecipientPermission -Identity $from -Trustee $user -ErrorAction SilentlyContinue |
Select-Object Identity, Trustee, AccessRights
# For distribution / mail-enabled security / dynamic DG Send on Behalf:
# Get-DistributionGroup -Identity $from | Select-Object GrantSendOnBehalfTo
# Get-DynamicDistributionGroup -Identity $from | Select-Object GrantSendOnBehalfTo
# Get-UnifiedGroup -Identity $from | Select-Object GrantSendOnBehalfTo
How to read it:
| Finding | Meaning |
|---|---|
No SendAs row for the user or their MESG |
Send As was never granted (or was removed); Full Access alone won't send |
SendAs listed for a group, user not listed directly |
Effective if the user is a member of that mail-enabled security group — check membership next |
GrantSendOnBehalfTo includes the user, no Send As |
They can send on behalf, not as; From will show the on-behalf marker |
RecipientTypeDetails is MailUniversalDistributionGroup / GroupMailbox / etc. |
You're on a group From address — use group delegation cmdlets/UI, not only mailbox delegation |
Get-Mailbox fails, Get-Recipient succeeds |
Likely a group or mail user; don't force mailbox-only cmdlets |
Whichever portal granted access (Microsoft 365 admin center mailbox permissions, EAC Mailbox delegation / Manage delegates, or PowerShell), the result is readable with Get-RecipientPermission for Send As and the GrantSendOnBehalfTo property for Send on Behalf.
Step 4: Trustee type and group membership (read-only)
Microsoft's recipient-permissions table lists who can be a delegate (trustee) for Send As:
- Mailboxes with user accounts
- Mail users with accounts
- Mail-enabled security groups
A plain (non-mail-enabled) security group, a distribution group as trustee, or a Microsoft 365 group as trustee is the wrong shape for holding Send As on behalf of its members. If the EAC let someone pick an odd principal and members still can't send, check the trustee with Get-Recipient:
# What kind of object is each Send As trustee?
Get-RecipientPermission -Identity 'info@contoso.com' |
Where-Object { $_.AccessRights -contains 'SendAs' -and $_.Trustee -notlike 'NT AUTHORITY\*' } |
ForEach-Object {
$t = $_.Trustee
Get-Recipient -Identity $t -ErrorAction SilentlyContinue |
Select-Object @{n='Trustee';e={$t}}, DisplayName, PrimarySmtpAddress, RecipientTypeDetails
}
# If trustee is a MESG, is Alex a member?
# Get-DistributionGroupMember -Identity 'Printer Support' | Where-Object { $_.PrimarySmtpAddress -eq 'alex@contoso.com' }
Mail-enabled security groups are the supported way to scale Send As. Distribution groups are a common From address (Step 7), not the preferred trustee container.
Step 5: Hidden from address lists (read-only)
Microsoft documents the same rule in create-shared-mailbox and manage-permissions-for-recipients:
Send As and Send on Behalf do not work in the Outlook desktop client when
HiddenFromAddressListsEnabledisTrue, because those permissions require the mailbox to be visible in Outlook via the Global Address List.
| Finding | Outlook desktop | Outlook on the web |
|---|---|---|
HiddenFromAddressListsEnabled = False
|
Send As can resolve via GAL | Works if permission exists |
HiddenFromAddressListsEnabled = True
|
Send As / SOBO fail even when Get-RecipientPermission is correct |
Often still usable — compare clients before re-granting |
This is a frequent "security hardening" footgun: someone hides info@ from the GAL so it doesn't appear in the address book, then Send As tickets start for every Outlook desktop user. Read the flag before removing and re-adding permissions.
Full Access has a related note: if Full Access is assigned on a mailbox hidden from address lists, the delegate won't be able to open the mailbox either. Discovery mailboxes are hidden by default.
Step 6: Outlook From cache vs Outlook on the web (read-only / user action)
Microsoft Support documents a classic Exchange Online case:
-
Add-RecipientPermissiongranted Send As;Get-RecipientPermissionconfirms it. - User types the address in From; Outlook autocomplete uses outdated Offline Address Book data.
- Send fails with an insufficient-permissions NDR in Outlook.
- The same user succeeds in Outlook on the web with the same From address.
Fix (user-side, no permission change):
- New message → From → Other Email Address.
- In that dialog, choose From, switch the address book to the Global Address List.
- Select the mailbox/group you have Send As on, then send.
If OWA works and desktop fails after a GAL pick, look at Step 5 (hidden) next — not at removing Send As. If both fail, the permission or recipient type is wrong (Steps 3–4, 7).
Also confirm the user isn't typing a secondary SMTP that belongs to a different recipient object than the one you granted on. Resolve the From entry from the GAL display name, then compare PrimarySmtpAddress to your Get-RecipientPermission -Identity.
Step 7: Sending as a distribution group or Microsoft 365 group (read-only)
"Send as permission not working" on a group is a different object than a shared mailbox:
| From address type | Send As via | Send on Behalf via | Notes |
|---|---|---|---|
| Shared / user / resource mailbox |
Add-RecipientPermission / EAC mailbox delegation |
Set-Mailbox -GrantSendOnBehalfTo |
Full Access is separate (Add-MailboxPermission) |
| Distribution group / mail-enabled security group |
Add-RecipientPermission / EAC group delegates |
Set-DistributionGroup -GrantSendOnBehalfTo |
No Full Access on a DG — it's not a mailbox |
| Dynamic distribution group | Add-RecipientPermission |
Set-DynamicDistributionGroup -GrantSendOnBehalfTo |
Membership is filter-based; trustees still need a valid delegate type |
| Microsoft 365 group |
Add-RecipientPermission / EAC group delegates |
Set-UnifiedGroup -GrantSendOnBehalfTo |
Sending as the group has its own Outlook/OWA UX; confirm group settings allow it in your tenant |
EAC path for groups: Recipients → Groups → select the group → Settings → Manage delegates (Send as / Send on behalf).
If Maria's All Staff DL ticket only checked shared-mailbox delegation screens, Send As was never written on the group. Re-run Step 3 against the group identity.
Step 8: Sent Items looks wrong (not a send failure)
If the message sent, but the copy is only in the user's Sent Items:
| Setting | Default | Effect when $true
|
|---|---|---|
MessageCopyForSentAsEnabled |
False |
Also save Send As copies in the shared mailbox Sent Items |
MessageCopyForSendOnBehalfEnabled |
False |
Also save Send on Behalf copies in the shared mailbox Sent Items |
Microsoft: in Microsoft 365, you open the shared mailbox from your own mailbox, so Outlook sends from the sender's account and stores the copy there by default. For new Outlook, only the mailbox-side MessageCopyFor… methods apply; the classic DelegateSentItemsStyle registry workaround does not.
Treat this as a configuration ticket after Steps 1–7 prove send itself works.
Step 9: Change one thing (only after the read)
Only after Steps 1–8, and only with change control:
# EXAMPLES: deliberate changes. Make one, retest From in Outlook AND Outlook on the web.
# Grant Send As on a shared mailbox to a user:
# Add-RecipientPermission -Identity 'info@contoso.com' -Trustee 'alex@contoso.com' -AccessRights SendAs
# Grant Send As to a mail-enabled security group (preferred for teams):
# Add-RecipientPermission -Identity 'info@contoso.com' -Trustee 'Printer Support' -AccessRights SendAs
# Grant Send As on a distribution group (send *as the DL*):
# Add-RecipientPermission -Identity 'allstaff@contoso.com' -Trustee 'alex@contoso.com' -AccessRights SendAs
# Send on Behalf on a mailbox (additive):
# Set-Mailbox -Identity 'info@contoso.com' -GrantSendOnBehalfTo @{Add='alex@contoso.com'}
# Unhide so Outlook desktop Send As can resolve via GAL (change control — visibility impact):
# Set-Mailbox -Identity 'info@contoso.com' -HiddenFromAddressListsEnabled $false
# Keep a copy in the shared mailbox Sent Items:
# Set-Mailbox -Identity 'info@contoso.com' -MessageCopyForSentAsEnabled $true
# Set-Mailbox -Identity 'info@contoso.com' -MessageCopyForSendOnBehalfEnabled $true
Retest:
- In Outlook on the web, compose → set From → send a test to yourself.
- In Outlook desktop, use From → Other Email Address → GAL (not autocomplete) → send.
- If you unhid a mailbox, wait for address-book sync / download the Offline Address Book before declaring desktop still broken.
- Permission replication is usually minutes, not instant — Microsoft's shared-mailbox guidance often says a few minutes after membership/permission changes; don't rebuild the profile in the first hour.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Full Access only; user needs to send as the mailbox | Add-RecipientPermission … -AccessRights SendAs |
Rebuilding the Outlook profile |
| Send As confirmed; fails only in desktop; OWA works | GAL From pick (Step 6); then check hidden flag | Remove + re-add Send As as the first move |
HiddenFromAddressListsEnabled = True
|
Unhide (if policy allows) or use OWA / accept desktop limitation | Granting Send As a second time on a still-hidden mailbox |
| Team needs Send As | Grant Send As to a mail-enabled security group, manage membership | Individual grants that drift on every joiner/leaver |
| User wanted pure Send As but has only SOBO | Add Send As (Send As wins if both exist) | Training users to ignore the "on behalf of" display if policy requires Send As |
| Can send; Sent Items wrong |
MessageCopyForSentAsEnabled / MessageCopyForSendOnBehalfEnabled
|
Fleet-wide DelegateSentItemsStyle registry on new Outlook |
| From is a DL / M365 group | Grant Send As on the group object | Looking only at shared-mailbox delegation UI |
| Works for one MESG member, not another | Fix group membership | Re-granting Send As on the mailbox |
FAQ
Why is Send As permission not working?
In order of how often it happens: the user only has Full Access (or only Send on Behalf); Send As isn't on the object they're putting in From (mailbox vs distribution group); the trustee is a group they aren't in; the mailbox is hidden from the address list (breaks Outlook desktop); or Outlook is using a stale Offline Address Book entry in From. Read Get-RecipientPermission and compare Outlook on the web to desktop before removing permissions.
User has Send As permission but cannot send — what next?
Confirm Send As with Get-RecipientPermission -Identity <from> -Trustee <user>. Have them send in Outlook on the web. If OWA works, use From → Other Email Address and pick the GAL entry in Outlook, then check HiddenFromAddressListsEnabled. If both fail, the grant is on the wrong identity or the trustee type doesn't apply to them.
Send As vs Send on Behalf — which do I need?
Use Send As when mail should look like it came from the mailbox or group with no delegate marker. Use Send on Behalf when you want "Alex on behalf of info@" visible. If both are assigned, Microsoft says Send As is always used.
Does Send As work on a distribution group?
Yes. Grant Send As on the distribution group (EAC group delegates or Add-RecipientPermission on the group). That is separate from shared-mailbox delegation. Dynamic distribution groups and Microsoft 365 groups also support Send As / Send on Behalf per Microsoft's recipient-permissions table.
Why does Send As fail only in Outlook desktop?
Two Microsoft-documented causes dominate: (1) HiddenFromAddressListsEnabled is True, and (2) the From box was filled from cached Offline Address Book data instead of the GAL. Test Outlook on the web first; it splits those cases cleanly.
Related posts
- Shared Mailbox Not Showing in Outlook (automapping / Full Access visibility — Step 7 there is the short Send As sidebar this post expands)
- A Monthly Exchange Online Hygiene Check (read-only inventory of Full Access, Send As, and Send on Behalf)
- Does a Shared Mailbox Need a License? (shared mailbox limits; the user still needs a licensed mailbox)
- Exchange Online Mail Flow Rule Not Working (when send "fails" because a transport rule rewrites or rejects after permission succeeded)
- An Offboarding Checklist for M365 + Intune Admins (converting a leaver to a shared mailbox and granting access the right way)
Free checklist
Send As tickets often land in the same week as a Conditional Access or MFA rollout, when "I can't send as billing@" and "I can't sign in" share one queue. Before you enforce, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the M365 admin runway written down for the team (break/fix cards, offboarding and mailbox decisions, and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=send-as-permission-not-working
Admin Pack Studio; not affiliated with Microsoft. Steps 1–8 only read: client menus, Outlook on the web, Get-Recipient, Get-Mailbox, Get-RecipientPermission, Get-DistributionGroup / Get-DynamicDistributionGroup / Get-UnifiedGroup, and Get-DistributionGroupMember. Add-RecipientPermission, Remove-RecipientPermission, Set-Mailbox, Set-DistributionGroup, Set-DynamicDistributionGroup, Set-UnifiedGroup, and address-book visibility changes are deliberate changes. Make one change for one user or one group, retest in Outlook on the web and Outlook desktop (GAL From pick), and check current Microsoft Learn and Microsoft Support for menu labels, which change often in new Outlook.
Top comments (0)