How MSPs Can Manage Client Shared Mailbox Access Requests

A request for access to a client’s shared mailbox deserves more attention than the words ‘please add this colleague’ suggest. The mailbox may contain customer complaints, contractual discussions, finance records or messages intended for several employees. Granting access changes who can read that material and, depending on the permission selected, who can communicate using the organisation’s identity. For a managed service provider (MSP), the job is to deliver a precisely authorised business capability, not merely to make a mailbox appear in Outlook.

Good handling begins with three separate questions: who is authorised to approve the request, which mailbox and individual account are involved, and what must that person actually do? The answers determine both the technical permission and the evidence needed at closure. This guide focuses on the common Microsoft Exchange Online shared-mailbox model whilst explaining controls that remain useful for other platforms. It does not assume that all clients have identical approval rights, that the MSP owns mailbox content or that an Exchange permission change automatically covers independent applications and devices.

Establish authority before examining permissions

Start with the client’s agreed service-request channel and a stable ticket reference. Record the requester, intended delegate, mailbox and business reason. Verify the requester against the client’s current authorisation arrangements; an employee who already has mailbox access is not automatically empowered to grant it to somebody else. A department manager may approve routine cover, while a mailbox containing legal, payroll or sensitive commercial information may require a designated information owner. Where the requester and the approver are different people, preserve both identities in the approved record.

Use authoritative account identifiers rather than display names alone. Two people can have similar names, while a client may operate different addresses for regional support, sales and confidential enquiries. A mistaken grant to the wrong recipient can expose historical correspondence immediately. Confirm the exact shared mailbox address or object identifier, the account that should receive the rights and whether the request applies to a personal account, external delegate or service identity. Do not copy complete private email conversations into general helpdesk notes simply to explain the need.

If the instruction is ambiguous, resolve it before making a consequential change. ‘Add to accounts’ might mean reading incoming invoices, replying from the shared address or seeing a particular subfolder. Each outcome can call for different rights. An MSP should explain the available options and ask an authorised person to select the intended one, rather than interpreting an informal request for ‘full permissions’ as blanket consent.

Separate reading from sending and representation

Exchange Online provides three important delegation concepts. Full Access, also described as Read and manage, permits a delegate to open a shared mailbox and interact with its contents. It does not by itself permit them to send mail from that shared identity. Send As permits messages to appear as though they were sent directly from the shared mailbox, without the delegate’s name appearing in the sender representation. Send on Behalf makes the delegate’s involvement visible in the sender display. Microsoft documents these distinctions in its Exchange Online permission guidance. The correct combination depends on the user’s actual responsibility, not on a default that grants every available right.

Consider an employee covering an enquiries inbox. They may need to read previous conversations and reply using the department’s address, in which case approved reading and sending rights may both be necessary. A manager authorised only to send a notice under the department identity may not need to inspect all historic messages. Another colleague may legitimately read messages but have no authority to speak on behalf of the organisation. These examples are operational illustrations, not instructions to grant particular rights without client approval.

There is a further distinction between sender presentation and actual auditability. A recipient seeing the mailbox address under Send As does not mean the platform lacks administrative evidence of who acted. Conversely, displaying ‘on behalf of’ does not eliminate the need for suitable logging, retention and internal approval. Administrators should check the organisation’s audit configuration and relevant controls rather than treating the visible From line as the complete security record.

Check the supported Exchange environment and existing grants

Determine whether the client uses Exchange Online, an on-premises Exchange deployment or a hybrid arrangement. Management interfaces and propagation behaviour can differ. Microsoft’s Exchange Online guidance describes both the Exchange admin centre and supported PowerShell permissions, but instructions for a different server edition should not be applied uncritically. Confirm the tenant, directory identity and actual mailbox object before administration. In particular, do not use a familiar display name or cached technician search result as sufficient target verification.

Inspect existing permissions before adding new ones. An individual may already receive rights through a group or an earlier delegation, and different kinds of access are not necessarily displayed in the same way. Microsoft notes that Full Access auto-mapping behaves differently for individually granted access and permissions granted to a group. A mailbox failing to appear automatically in Outlook therefore does not, on its own, prove the access is absent. Check the authoritative permission state and the supported client configuration before repeatedly granting privileges.

Shared mailbox accounts are not intended to be used as ordinary shared login credentials. Microsoft’s documentation describes access through named user accounts and delegation, rather than a team sharing the mailbox’s own password. Keep the underlying account’s direct sign-in restriction under the supported client policy. This helps preserve identity attribution and makes it practical to remove one person’s rights without changing everybody else’s authentication details.

Plan temporary cover, sensitive cases and downstream effects

Holiday cover, parental leave and short projects may justify temporary delegation. Record the approved start, end or review event alongside the business owner who can confirm continued need. A calendar reminder without an accountable removal process is weak control: staff can change roles or leave before the planned date. Where an external contractor requires access, examine contract, security and cross-organisation requirements before granting it; a guest identity or federation arrangement may need a different supported method from an internal employee account.

Assess whether granting reading rights exposes content beyond the current task. Full Access can include historical correspondence and folders unrelated to the delegate’s immediate work. If the request concerns only one information subset, consider whether the supported platform and client policy provide a narrower route, or whether a business-process alternative is preferable. Do not grant broad access simply because it is easier than checking the data owner’s requirements. Also consider retention, confidentiality and regulatory obligations without inventing a universal legal rule that every shared mailbox must have a particular approval form.

Mailbox changes can affect how people work together. A new delegate may see items another person moved, a reply may appear under the shared identity, and different users may interpret read/unread states differently. Give the team clear conventions for handling customer enquiries, assigning ownership and avoiding duplicate replies. Permission management is necessary but not sufficient for an effective shared inbox workflow. If the business has its own case-management or ticketing platform, identify whether work should be tracked there rather than in a purely mail-based process.

Apply the approved change and verify the actual outcome

Use an authorised administrator account and the supported management method. Record the exact mailbox and delegate identifiers, the approved permission type, execution time, operator and change reference. Avoid pasting passwords, tokens, private message content or sensitive administrative output into unrestricted case records. Where an existing grant must be removed or replaced, distinguish the old state, action taken and resulting state. Do not make unrelated membership changes merely because the technician is already in the administration interface.

After the change, verify the platform’s effective permission state and then the intended user journey. For Full Access, a legitimate check might establish that the named user can open the correct mailbox and perform an authorised reading task. For Send As, a controlled test should confirm the expected sender representation without sending a real customer message inappropriately. For Send on Behalf, check that the named delegate is represented as intended. Use safe test correspondence and approved accounts; do not impersonate another employee to prove the setup.

Be careful about timing. Outlook configuration, client caching, auto-mapping and cloud changes can affect when users see the result. A successful administrative command is not proof that the employee has completed the intended work, and a temporarily missing mailbox icon is not proof that the grant failed. Confirm the supported evidence and troubleshoot the specific boundary before repeating commands. If the recipient cannot verify the access immediately, keep the ticket at a truthful pending-verification stage, with a named next check rather than claiming full completion.

Close the access lifecycle rather than the ticket alone

A reliable closure record states who authorised access, which named user and mailbox were affected, the actual rights applied, what was verified and when the permission should be reviewed. Preserve the operational decision without unnecessarily retaining message content. Where changes are controlled by a different supplier or client administrator, record accepted handover evidence and the owner of any outstanding action. A supplier acknowledgement is not the same as proof the effective permission exists.

Make mailbox delegation part of the organisation’s mover and leaver procedures. Disabling a person’s primary account may block normal sign-in, but separately managed access and privileges should still be reviewed under the client’s identity lifecycle. A delegated role that was appropriate for a temporary project may become excessive when that employee moves to a different department. Keep mailbox owners and authoritative approvers current so the next MSP technician can resolve a request without guessing who controls the content.

Finally, review recurring permission tickets. If the same authorised team repeatedly needs identical access, a properly governed group or role model may reduce administrative friction, but membership still needs approval and review. If users repeatedly report that they can read but cannot send, improve the request form so it distinguishes those capabilities. If mailbox names are routinely confused, strengthen resource identification. The useful end state is not a completed permission command; it is a defensible, limited access decision that the client can understand, test and reverse.

Technical evidence: Microsoft Learn, Shared mailboxes in Exchange Online (Exchange Online management and shared mailbox delegation; accessed 30 October 2026) and Microsoft Learn, Manage permissions for recipients in Exchange Online (delegation semantics, admin methods and auto-mapping limits; accessed 30 October 2026). These are vendor-specific sources, not substitutes for a client’s authorisation rules or evidence that a particular tenant was configured.