Reading a mailbox and sending from it are different permissions
A shared mailbox gives a team a common address and a shared set of messages or calendar items. The delegate normally signs in with an individual identity and receives the capabilities needed for that mailbox. Opening its contents does not automatically authorize every kind of outbound message.
Full Access, often described as Read and manage in administration interfaces, lets a delegate work with mailbox contents. Send As allows the message to appear as the shared mailbox. Send on Behalf has a different sender presentation, identifying the delegate acting for the mailbox. Choose the behavior required by the business instead of granting every capability by default.
Setup: record the intended delegation
Identify the shared mailbox and delegate by their full account identities. Record whether the user needs to read, manage, send as, send on behalf, or a combination. Include the supported client and how the mailbox was opened, because a cached Outlook profile and an explicit web session can provide different diagnostic evidence.
Check the mailbox's current state and the relevant Microsoft 365 service requirements. Do not solve a delegation problem by circulating a shared password. Keep grants tied to named users or supported groups with an owner and an offboarding process.
Investigate a sending failure
- Confirm the delegate can access the intended mailbox and identify the exact From address selected when composing. A similarly named mailbox or stale autocomplete entry can lead to the wrong destination identity.
- Review mailbox delegation in the appropriate Exchange Online administration controls. Compare read-and-manage access with the specific sending grant; successful reading proves only the former path.
- Reproduce the intended send using an approved test recipient and collect the nondelivery report or client error, timestamp and message identifiers. Avoid copying unrelated mailbox content into a support record.
- Compare a supported web-client test with the affected client after allowing the service's permission change to propagate. If the web test works, investigate the local mailbox opening method, cached sender entry and profile behavior before changing unrelated mail-flow policies.
Illustrative incident: a new support agent can read but cannot reply
In this illustrative scenario, a new support agent receives Full Access to a team mailbox and can read incoming tickets. Replies selected from the shared address fail. The onboarding checklist recorded only that the mailbox opened successfully.
The administrator compares the approved role with the actual grants, adds the required supported sending permission and verifies the visible sender at a test recipient. The acceptance checklist now covers reading and the specific outbound behavior separately. This is an example of delegation testing, not a real personnel or customer event.
Diagnostic table
| Observation | Evidence | Boundary |
|---|---|---|
| Mailbox opens but send fails | Sending grant and From identity | Read access is not sending access |
| Recipient sees delegate on behalf | Granted capability and header result | Sender presentation differs |
| Web client works, desktop fails | Profile and cached From entry | Client-specific behavior |
| Access persists after role change | Direct and group delegation | Offboarding grant inventory |
Verify the resulting business workflow
Test permitted reading and sending with the actual delegate identity. Check the recipient-visible sender, reply destination and the team's sent-item expectations using the documented configuration. Verify disallowed actions with a controlled test when the role intentionally lacks them.
Record the grant owner and the reason for each capability. Allow for documented service and client propagation behavior rather than repeatedly changing permissions in a short loop. Escalate persistent failures with the exact identity, timestamp, error and client comparison.
SOP
Add mailbox delegation to onboarding, role-change and offboarding procedures. Review named delegates and supported group membership regularly. The acceptance record should distinguish access to mailbox contents from the authorized sending identity, so a convenient shared address does not become an unmanaged shared account.
See Clouvenix workspace administration for implementation and operational handover.
Technical reference
Official reference 1; Official reference 2. Documentation checked 19 October 2026; confirm behavior for your deployed edition and version.