A user can open a shared mailbox but cannot send from its address. This is not contradictory: Exchange Online separates access from sending. Identify the function needed before granting more permissions.
Distinguish three permissions
- Full Access: open the mailbox and read, add and remove content. It is not read-only and does not include sending.
- Send As: messages appear to come directly from the shared mailbox, without identifying the delegate as sender. It does not allow reading the mailbox.
- Send on behalf: recipients see the delegate on behalf of the mailbox. Replies go to the mailbox. This does not grant read access either. If both sending permissions exist, Exchange uses Send As.
Inspect existing delegation
- Record the exact mailbox address, affected user and requested task: manage content, send, or both? Before an approved change, preserve existing permissions and group memberships so only your change can be reversed.
- In the correct tenant, open Exchange admin center → Recipients → Mailboxes. Select the specific shared mailbox and open Mailbox delegation.
- Check Read and manage (Full Access) and Send As separately. Account for permissions through mail-enabled security groups and current membership. A missing direct user entry alone does not prove missing effective access.
- Send on behalf is unavailable in EAC for shared mailboxes. An authorized administrator can read the assignment in Exchange Online PowerShell with
Get-Mailbox -Identity "team@example.com" | Format-List GrantSendOnBehalfTo. Replace the example address with the authorized target mailbox.
Change only what is needed
If a permission is demonstrably missing and its grant is approved, edit only that permission in the relevant delegation section, add the intended user and save. Check the list again. Do not grant all three permissions as a precaution or replace a whole delegate list. Users sign in through their own licensed Exchange Online account; direct sign-in remains blocked for the shared mailbox account.
Test opening and sending separately
First test opening as the affected user without deleting content. Test sending only within the agreed scope to a designated recipient; verify the From field beforehand and the actual sender identity afterwards. A mailbox not appearing automatically in Outlook does not prove a permission failure: automapping works for direct user assignments, not groups.
New assignments can take time to replicate; Microsoft mentions about an hour for the corresponding sending errors. Record time, client, exact error and both test results before changing permissions again. Also check whether the mailbox is hidden from address lists if relevant. Rollback removes only your documented addition, not other people’s existing permissions.