Send As Permission Not Working: A Read-First Grant Type, Outlook vs OWA, and Group Triage

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 HiddenFromAddressListsEnabled is True, 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?

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)

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)

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:

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 HiddenFromAddressListsEnabled is True, because those permissions require the mailbox to be visible in Outlook via the Global Address List.

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:

1. Add-RecipientPermission granted Send As; Get-RecipientPermission confirms it.
2. User types the address in From; Outlook autocomplete uses outdated Offline Address Book data.
3. Send fails with an insufficient-permissions NDR in Outlook.
4. The same user succeeds in Outlook on the web with the same From address.

Fix (user-side, no permission change):

1. New message → From → Other Email Address.
2. In that dialog, choose From, switch the address book to the Global Address List.
3. 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:

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:

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:

1. In Outlook on the web, compose → set From → send a test to yourself.
2. In Outlook desktop, use From → Other Email Address → GAL (not autocomplete) → send.
3. If you unhid a mailbox, wait for address-book sync / download the Offline Address Book before declaring desktop still broken.
4. 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

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:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=send-as-permission-not-working

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.