Keep shared mailbox access aligned with staff responsibilities

A shared mailbox should reflect the people doing the work today. When someone changes teams, covers a colleague or leaves the business, review reading access, sending permissions and connected applications separately. Record who approved the change, then verify both the access that should remain and the access that should stop.

An inbox such as accounts@ or reception@ can look straightforward from Outlook while the business responsibility behind it is unclear. One person answers enquiries, another checks payments and a temporary replacement covers leave. Giving everybody the same permissions avoids a discussion, but it does not answer who may represent the business or change its correspondence.

This guide is for Microsoft 365 organisations using Exchange Online. Microsoft says hybrid Exchange environments require the appropriate on-premises management approach; use its creation and management guidance before changing those environments. The review process below is Mimir's editorial advice, not a report of a customer implementation or a tenant security test.

Start with the work and its accountable owner

Name a business owner for each shared mailbox before reviewing technical assignments. That owner should understand what arrives, who must respond and which messages need restricted handling. IT can implement an access decision; it should not have to infer the authority to answer a supplier or disclose a personnel matter from an old support ticket.

Write a short purpose statement. For example, a reception inbox might handle appointment enquiries and visitor arrangements. That does not automatically mean everyone covering reception needs access to an unrelated finance inbox.

Record the normal team, approved cover arrangements and the person who can approve exceptions. Choose a review trigger that matches the work, such as a role change, contractor departure or change of business owner. A calendar reminder can support that process, but should not postpone a known access change until the next quarter.

Separate shared mailbox reading and sending permissions

Microsoft documents three distinct delegation permissions in its shared-mailbox permission guide:

• Full Access lets a delegate open and manage mailbox contents, including removing items. It does not itself grant sending permission.
• Send As lets a delegate send using the mailbox's identity. The recipient does not see a separate delegate attribution.
• Send on behalf identifies the delegate alongside the mailbox. It does not itself grant reading access.

These permissions are not interchangeable. For shared mailbox access, decide whether the person needs to handle messages, send a response, or both. Do not describe Full Access as read-only access in an approval record.

Microsoft's Exchange Online permissions reference states that Send As takes precedence when both sending permissions are assigned. If identifying the individual sender matters to the business, inspect the actual assignments and test the resulting message. Selecting a preferred display style in a policy does not prove the recipient will see it.

Keep people on their own identities

Microsoft's shared-mailbox guidance says delegates use their own licensed Exchange Online mailboxes. It also says the shared account is not intended for direct sign-in and should remain blocked.

The business implication is straightforward: a shared address does not require staff to share a password. Let people authenticate through their own identities and give them the approved delegation.

Mimir recommends checking the sign-in state during an access review, rather than assuming the original configuration has remained unchanged. Do not unblock the account as a shortcut when Outlook behaves unexpectedly. First establish which identity is signed in, which permission was granted and which client is being used.

If an application appears to depend on the shared account's credentials, treat that as a separate integration review. Agree its supported authentication method and owner before changing it, so fixing one access problem does not silently interrupt another process.

Review shared mailbox access beyond the Outlook sidebar

A mailbox appearing in Outlook is not an access inventory. Microsoft's permissions reference explains that automapping applies to individually assigned Full Access and does not work for group assignments. A missing automatic entry therefore does not prove that a person has no access.

Ask the administrator to review direct assignments and any groups used to grant permissions. Record the route by which each person receives access. If a group is involved, confirm its current membership and who is allowed to change it.

Do not remove a group membership without checking its other purposes. A group used for several services can make a narrowly intended email change affect unrelated work. Where that creates ambiguity, propose a clearer access structure and review the consequences before implementing it.

Also record approved forwarding, inbox rules and workflow dependencies as separate review items. A list of human delegates is only one part of understanding where correspondence goes. This inventory step is an operational recommendation, not a claim that one screen exposes every access path.

Treat a role change as a controlled handover

Consider a hypothetical employee moving from reception to purchasing. They still work for the company, so disabling their whole account would be the wrong response. The question is which reception permissions should end and which purchasing responsibilities should begin.

Have the business owner identify outstanding work and nominate the person taking it over. Agree the effective change time and any genuinely necessary overlap. If temporary access is approved, record its purpose, expiry and the person responsible for removing it.

The administrator should then reconcile each relevant permission against that decision. Removing reading access alone is not the same decision as removing the ability to send. Check each separately, including a group-based route where one exists.

Verify the result using agreed test messages and authorised test accounts or user-assisted checks. Confirm that the continuing team can work and that the changed user no longer has the permissions removed. A screenshot of a submitted change is useful evidence, but it does not replace checking the resulting behaviour.

Make sent correspondence visible to the right team

Shared mailbox work can become confusing when the next person cannot find an outgoing reply. Microsoft's Sent Items guidance describes messages being saved in the delegate's Sent Items and mailbox settings that retain copies centrally. It distinguishes copies for Send As from copies for Send on behalf.

Decide what the team needs to see before changing those settings. Then send controlled test messages using each approved sending mode and inspect the relevant folders. Check the clients staff actually use; do not assume that a successful test in one application settles every workflow.

This is also a process question. A visible sent message tells the next person that a reply exists, but not necessarily whether the enquiry is finished. Agree how staff indicate ownership and completion, and where exceptions should be escalated. Avoid relying on one person's memory to prevent duplicate replies.

Include applications in the access conversation

An unattended integration is not simply another member of the inbox team. Microsoft's application access documentation describes application permissions and resource scopes separately from human delegation. It also explains that Exchange application grants and Microsoft Entra grants can be additive.

For the review, list systems that read, send or move messages and name their operational owners. Ask the administrator to identify their authentication method, applicable permissions and intended mailbox scope. Do not assume that removing an employee's delegation also removes an application's access.

This article is not an application-permission migration procedure. Where the inventory finds broad or unexplained access, investigate it as a separate change with its own test and recovery plan. Keep that unresolved dependency visible rather than marking the shared mailbox review complete.

Verify the evidence available for investigations

Microsoft says mailbox auditing is enabled by default and supports shared mailboxes, but it records defined actions rather than providing an unlimited account of everything a user might have seen. Its auditing documentation also identifies licence-dependent actions and a limitation for cross-geo mailbox activity.

Ask an appropriately authorised administrator to confirm the organisation's settings, relevant operations and available search evidence. Decide what the business needs to establish after an incident, then check whether the configured records can answer that question.

Keep the approval record and the technical change record together. Include the affected address, previous and intended permissions, approver, implementer, time and verification result. Protect that record as administrative information.

Do not promise that removing access erases messages previously copied or downloaded. Define the objective as preventing the access that should no longer be permitted, then handle retained information through the organisation's established offboarding and information-handling process.

Use a review record someone else can repeat

A useful shared mailbox review should survive the departure of the administrator who performed it. Keep a concise record with enough evidence for another person to understand the decision:

• Purpose and owner: what work belongs here, and who approves access.
• Permission routes: direct grants, relevant groups, sending modes and identified applications.
• Change decision: what stays, what ends, temporary exceptions and their expiry.
• Verification: expected access, denied access, sender appearance and sent-message visibility.
• Follow-up: unresolved dependencies, accountable owners and the next review trigger.

Start with one business-critical address and make the record useful before expanding the exercise. A finance or customer-enquiry inbox can expose practical questions about cover and response authority that a purely technical membership export will not settle.

Where internal staff and an external provider share administration, define who approves, implements and verifies the change. Our co-managed IT support approach covers that division of responsibility.

Know when the mailbox is not the whole solution

Microsoft's guidance allows up to 50 GB without a separate mailbox licence, but additional capacity and certain advanced features have separate licensing conditions. Check the actual requirement before treating shared mailbox operation as universally free.

If the business needs formal assignment, response deadlines, approval workflows or detailed case history, assess a service-management process rather than expecting an inbox convention to provide those controls. That is a fit decision, not a reason to buy another product automatically.

Use the access review to surface those requirements and put them into the wider IT strategy and oversight plan. Keep the email setup where it meets the need. Change the process where it does not, with clear ownership and evidence that the revised arrangement works.