Opening a shared mailbox and sending from it are separate permissions. Full Access lets a person work with its contents. Send As makes outgoing mail appear to come from the shared address. Send on Behalf identifies the person acting for that address. Decide which behavior the business needs, then test it with the actual user.
This guide covers delegated access to Microsoft 365 shared mailboxes in Exchange Online. It is a decision and acceptance checklist for the mailbox owner and authorized administrator, rather than a tenant-specific configuration script.
Choose the permission by the job
| Permission | What it allows | What it does not provide |
|---|---|---|
| Full Access / Read and manage | Open the mailbox and read, create, change or delete items. | Permission to send from the mailbox. It is also not a read-only role. |
| Send As | Send with the shared mailbox shown as the sender. | Access to read the mailbox. |
| Send on Behalf | Send with the delegate identified as acting on behalf of the mailbox. | Access to read the mailbox. |
The distinction matters for a reception or accounts team. Someone handling incoming messages and replying as the department will generally need Full Access plus the chosen sending permission. Microsoft documents these capabilities in its shared mailbox guidance.
Do not label Full Access “read only” in an approval request. A manager who only wants a colleague to view selected information needs to discuss a narrower sharing arrangement with the administrator. The permission name should describe the access actually being granted.
Decide what the recipient should see
Use a simple illustrative scenario: Maya handles the shared Accounts inbox. The business wants customers to see “Accounts” as the sender, so the approved combination is Full Access and Send As. A different business wants the individual representative visible; it chooses Full Access and Send on Behalf instead. These are examples, not TX Computing customer records.
Avoid granting both sending permissions as a troubleshooting shortcut. When a delegate has both, Microsoft says Send As takes precedence. The resulting message can therefore hide the individual attribution the business intended. See Microsoft’s recipient permissions reference.
Before implementation, write down the shared address, named delegates, required permissions, approving owner and review date. Include whether each person needs access permanently or only to cover an absence. “Add the team” leaves too much ambiguity when membership later changes.
Keep individual sign-ins and shared mail separate
Staff should use their own authorized accounts to access the shared mailbox. Verify that direct sign-in to the shared mailbox account is blocked; do not distribute a shared password as an access method. Microsoft’s creation and sign-in guidance explains this account setting. Check the saved state for an existing mailbox rather than assuming its configuration matches a newly created one.
The authorized administrator should also confirm the mailbox’s environment. Hybrid Exchange management differs from a cloud-only setup. Keep license, retention and archive decisions separate from the permission request; this checklist does not establish eligibility for a particular license arrangement.
Agree where sent messages belong
A colleague may successfully send as Accounts while another team member cannot find that reply in the shared Sent Items folder. By default, messages sent from a shared mailbox are saved in the sender’s Sent Items. An administrator can enable copies in the shared mailbox. Microsoft’s shared mailbox configuration guide describes this setting.
Make shared visibility of replies an explicit acceptance requirement if the team relies on it. Confirm the setting for the sending mode in use. Seeing a test message in one person’s mailbox does not prove that the rest of the team can follow the conversation.
Run this acceptance check before closing the request
Use harmless test content and an agreed test recipient. Record the date, delegate account and Outlook client tested. The mailbox owner can use this checklist to accept the work:
- Open: The approved delegate opens the intended shared mailbox using their own account and finds the test message.
- Send: The delegate selects the shared address and sends a test reply. The recipient confirms the actual sender display matches Send As or Send on Behalf as approved.
- Receive: The test recipient replies, and the team verifies the reply arrives where expected.
- Trace: A second authorized team member can locate the sent copy if shared conversation visibility was required.
- Record: The administrator records the final permission assignments; the owner confirms the approved people and review date.
Keep the result beside the access request. “Permissions added” records an administrative action; a successful user test records whether the requested workflow works.
If the mailbox is missing or sending fails
Start with the failing step. A mailbox that opens but rejects sending calls for a check of the separate sending permission. A mailbox that does not appear automatically may need a client configuration check: Microsoft’s recipient permissions reference explains that automapping works for individual assignments, not assignments through groups. Lack of automatic appearance alone does not establish lack of access.
Ask the administrator to compare the approved request with effective assignments and the actual client behavior. Record the error and time. Avoid adding broad permissions repeatedly without identifying which requirement is failing.
For a wider rollout, include these checks in your Microsoft 365 migration acceptance plan. For help reviewing the request, bring the delegate list and required sender behavior to a discussion about TX Computing’s email solutions.
By mjunaid for TX Computing. Sources checked November 6, 2026. The cover is a generated conceptual illustration, not a customer installation.