Overview

Being able to open a shared mailbox does not automatically mean a user can send from it. Sending requires Send As or Send on Behalf permission in addition to mailbox access.

Do not broaden delegation to troubleshootConfirm the approved permission model before adding or changing shared-mailbox rights.

Why this happens

A user may have Full Access but lack Send As, may be selecting the wrong From address, may have a recently changed permission that has not propagated, or Outlook may be using stale cached identity information.

Before you begin

  • Confirm the user is authorized to send from the mailbox.
  • Record the exact error or NDR.
  • Determine whether Send As or Send on Behalf is intended.
  • Do not add permissions that have not been approved.

Click-by-click troubleshooting

Step 1: Test sending from Outlook on the web

Action: Open the shared mailbox in Outlook on the web. Create a new message, show the From field if necessary, select the shared mailbox address, and send to an approved recipient.

Why this matters: This tests Exchange Online delegation without relying on desktop Outlook cache.

What to look for: Confirm whether the message sends or an authorization error appears.

Expected result: If web sending succeeds, Exchange permission is likely valid and desktop Outlook becomes the main suspect.

Step 2: Verify the From address in desktop Outlook

Action: Create a new message. Select Options > From if the field is hidden. Choose From > Other Email Address and select the exact shared mailbox.

Why this matters: Outlook can send from the user's own mailbox if the From field is not explicitly set.

What to look for: Confirm the visible From address matches the shared mailbox exactly.

Expected result: The message should be submitted using the intended shared-mailbox identity.

Step 3: Verify Send As or Send on Behalf permission if authorized

Action: Open Exchange Admin Center > Recipients > Mailboxes. Select the shared mailbox > Mailbox delegation and review Send As and Send on Behalf.

Why this matters: Full Access controls opening the mailbox; sending requires separate delegation.

What to look for: Confirm the correct user has the approved sending permission and note which type is assigned.

Expected result: The user should have exactly the approved delegation needed to send.

Step 4: Allow time for a recent delegation change

Action: If the permission was added or changed recently, close Outlook and wait for Exchange Online propagation before retesting.

Why this matters: Delegation changes are not always effective immediately across all clients.

What to look for: Compare the timestamp of the permission change with the failed send attempts.

Expected result: After propagation, Outlook and Outlook on the web should enforce the new delegation consistently.

Step 5: Compare Send As with Send on Behalf behavior

Action: Review the approved permission type. Send As should make the message appear directly from the shared mailbox. Send on Behalf should identify the user as sending on behalf of the mailbox.

Why this matters: The two permissions have different behavior and should not be interchanged casually.

What to look for: Confirm the expected sender presentation matches organizational requirements.

Expected result: The configured delegation should produce the intended sender identity.

Step 6: Preserve the exact failure for escalation

Action: Capture the Outlook error, NDR, sender address, recipient, and test result from Outlook on the web.

Why this matters: Exchange permission failures are much easier to diagnose with the exact server response.

What to look for: Look for messages stating the user does not have permission to send on behalf of or as the mailbox.

Expected result: IT should receive evidence that distinguishes delegation, client, and mail-flow problems.

What to look for

  • Can open mailbox but cannot send: delegation issue is likely.
  • Web works but desktop fails: Outlook cache or client issue.
  • Wrong From address: user is not actually sending as the shared mailbox.
  • Recent permission change: allow propagation.

When to stop

Stop before adding unnecessary delegationDo not grant Full Access, Send As, or Send on Behalf beyond the approved users or groups. Do not change shared-mailbox ownership or convert mailbox types merely to fix sending.

When to contact IT

Contact J3 Systems Group if Send As or Send on Behalf is correctly assigned but sending still fails, the web and desktop behavior differ, or an NDR persists. Include article code KB-05.005, mailbox address, user, permission type, and error text.

Need help with this issue?

J3 Systems Group supports small businesses and nonprofits with Microsoft 365, Google Workspace, cybersecurity, devices, documentation, and day-to-day IT operations.

Contact J3 Systems Group

Authoritative references

Vendor interfaces, licensing, and security guidance can change. Verify current platform behavior against the primary documentation below before making high-impact production changes.

Article KB-05.005 · Review after material vendor, licensing, interface, security, or service changes.