The short version: shared mailbox access is not just “add the user and close the ticket.” Confirm approval, identify the mailbox, choose the right permission, decide whether the user needs send-as or send-on-behalf, test webmail and Outlook, then document exactly what changed.
Shared mailbox tickets look easy until the user says, “I can see the mailbox but cannot send from it,” or the manager asks why a former employee’s inbox is visible to the wrong person. This checklist is for help desk techs, desktop support, junior Microsoft 365 admins, and anyone who gets access requests that involve shared inboxes, calendars, distribution lists, and Outlook doing Outlook things.
Use it as a practical runbook. Your tenant, policies, and admin portal may differ, but the flow should stay the same: verify, approve, grant, test, document.
The shared mailbox access checklist
| Step | What to check | Why it matters |
|---|---|---|
| 1 | Requester, user, mailbox, and business reason | Prevents vague “add me to email” work |
| 2 | Approval from mailbox owner, manager, or data owner | Mailboxes can contain sensitive data |
| 3 | Permission type: read/manage, send-as, send-on-behalf, calendar | Avoids over-granting access |
| 4 | License and mailbox type | Shared mailbox behavior depends on platform rules |
| 5 | Outlook, webmail, and mobile expectations | Reduces “it still does not work” follow-ups |
| 6 | Test send/receive and visibility | Proves the actual workflow works |
| 7 | Review date or removal trigger | Prevents permanent access creep |
| 8 | Ticket notes and audit trail | Helps security, HR, and the next tech |
1. Translate the request into exact access
Bad ticket:
Need access to sales email.
Better ticket:
Add Maya R. to the Sales shared mailbox so she can read incoming requests and send replies as Sales during coverage week. Approved by Sales manager Priya N.
Before touching permissions, capture:
- User who needs access
- Shared mailbox name and primary email address
- Business reason
- Whether access is temporary or permanent
- Whether the user needs read/manage access only
- Whether the user needs to send as the mailbox
- Whether calendar access is part of the request
- Who approved it
- Any deadline or coverage window
This sounds picky, but “sales email” might mean a shared mailbox, distribution list, Microsoft 365 group, Teams channel email address, CRM queue, or a former employee mailbox. Guessing wrong creates a second ticket and sometimes a privacy problem.
If the request is part of a new hire setup, link it back to your new employee IT onboarding checklist so the access has a clear source instead of living as a random side quest.
2. Confirm approval before granting access
Mailbox access can expose customer messages, HR conversations, invoices, legal discussions, security alerts, and internal drama nobody needed to see before lunch. Do not grant it because someone said “my manager is fine with it” in a chat.
A sane approval path usually looks like this:
| Mailbox type | Typical approver |
|---|---|
| Team inbox like support@ or sales@ | Team manager or mailbox owner |
| Department mailbox | Department head or data owner |
| Former employee mailbox | HR, legal, manager, or approved offboarding process |
| Finance, HR, legal, security mailbox | Formal owner approval, often stricter |
| Temporary coverage mailbox access | Manager approval plus end date |
If the user is replacing someone who left, use the employee offboarding checklist as the related workflow. Offboarding mailbox handoffs deserve extra care because personal and business messages may be mixed together.
3. Choose the right permission
Not all mailbox access is the same. If you only remember one thing, remember this: read access and send access are separate decisions.
Common permission types:
| Permission | What it does | When to use it |
|---|---|---|
| Full access / read and manage | User can open the mailbox and manage mail | User needs to process inbox items |
| Send as | Email appears to come from the shared mailbox | User represents the team mailbox directly |
| Send on behalf | Email shows user sent on behalf of mailbox | You want transparency about who sent it |
| Calendar permissions | User can view or manage calendar items | Scheduling or room/team calendar workflows |
| Distribution list membership | User receives messages sent to a group | Not the same as shared mailbox access |
Do not hand out send-as rights by default. Many users only need to read and triage messages. Send-as can affect customer communication, audit questions, and accountability.
If the request is “I need to receive messages,” confirm whether a distribution list would be better. If the request is “I need to work the queue with the team,” a shared mailbox probably makes more sense.
4. Check mailbox state, licensing, and limits
Before blaming Outlook, confirm the mailbox itself is healthy and exists the way the requester thinks it does.
Check:
- Is this actually a shared mailbox?
- Is it active, hidden, deleted, or converted from a user mailbox?
- Does it have an owner or documented team?
- Does it require a license because of size, archive, retention, or platform rules?
- Are there existing users with similar access?
- Are forwarding, auto-replies, or mail rules already configured?
- Is the mailbox blocked by retention, legal hold, or security policy?
For routine help desk work, you may not own every one of these settings. That is fine. The point is to know when the issue is not “add permission again harder.” Sometimes the mailbox was converted during offboarding, the address changed, or the user is asking for a distribution group instead.
5. Set expectations for Outlook and webmail
Shared mailbox permissions are not always instant from the user’s point of view. Webmail may show the change faster than desktop Outlook. Desktop Outlook may need a restart. Cached mode can be weird. Auto-mapping can add the mailbox automatically in some environments and not in others.
Tell the user what to expect:
- Webmail may be the fastest test.
- Desktop Outlook may need to be closed and reopened.
- The mailbox may appear automatically, or the user may need to open/add it.
- Mobile mail apps may require extra setup or may not be supported by policy.
- Send-as rights may take longer to appear than read access.
- Offline address book or cached data can lag.
Do not close the ticket just because the admin portal accepted the permission. Close it after the user can do the actual task.
If the mailbox opens in webmail but desktop Outlook refuses to behave, treat it like an email client problem and use the email troubleshooting checklist to separate server-side access from local Outlook nonsense.
6. Test the workflow, not just the permission
A shared mailbox request is done when the business workflow works.
Test at least one relevant path:
| Need | Test |
|---|---|
| Read incoming mail | User can open mailbox and view recent messages |
| Triage queue | User can move, categorize, flag, or archive messages as expected |
| Send as mailbox | User sends a test email from the shared address and recipient sees correct sender |
| Send on behalf | Recipient sees the expected “on behalf of” behavior |
| Calendar access | User can view or create the expected calendar item |
| Coverage access | User can perform the needed work during the temporary window |
A good test note is specific:
Verified Jordan can open the Support shared mailbox in webmail, view current messages, and send a test message as [email protected] to the IT test inbox. Desktop Outlook required restart before mailbox appeared.
That is much better than “access granted.”
7. Watch for security and privacy red flags
Pause and escalate if the request feels off.
Red flags:
- User asks for access to a former employee mailbox without HR/manager approval.
- Requester wants send-as rights for an executive mailbox.
- Someone asks to hide forwarding or auto-replies.
- The mailbox contains HR, legal, finance, medical, customer security, or incident data.
- The request comes through chat with no ticket.
- Access is “temporary” but has no end date.
- The same person keeps requesting access to unrelated mailboxes.
You do not need to turn every shared mailbox ticket into a courtroom scene. Just respect that email is often where sensitive business history lives. If you are unsure, escalate instead of guessing.
For identity-sensitive changes like MFA resets or suspicious account activity, use the MFA reset checklist and follow your security workflow.
8. Add a removal date when access is temporary
Temporary access that never expires is how permissions turn into archaeology. Six months later, nobody knows why someone in Marketing can send as the Finance mailbox.
For temporary coverage, note:
- Start date
- End date
- Reason
- Approver
- Permission type
- Who owns removal
- Follow-up ticket or review reminder
If your system supports access packages, group expiration, lifecycle workflows, or automated reviews, use them. If not, a follow-up ticket is still better than nothing.
9. Write ticket notes that pass the “next tech” test
Use this template:
Granted [user] [permission type] to [shared mailbox/email address] per approval from [approver/ticket]. Access needed for [business reason]. Verified [webmail/Outlook/send test/calendar test]. Notes: [restart needed, propagation delay, temporary end date, escalation, exceptions].
Example:
Granted Maya R. full access and send-as permission to [email protected] per approval from Support manager Priya N. Access needed for June coverage rotation. Verified Maya can open the mailbox in webmail, view incoming messages, and send a test email as [email protected]. Desktop Outlook showed mailbox after restart. Temporary access scheduled for removal on 2026-06-29.
If you denied or paused the request, document that too:
No access granted yet. Request is for former employee mailbox and lacks HR or data-owner approval. Sent approval request to HR queue and updated requester.
For more examples like this, use the help desk ticket notes examples post.
Common shared mailbox mistakes
Granting full access when send-as was the real need
Sometimes a user can already see the mailbox but cannot send from it. Adding full access again will not fix send-as. Identify the missing permission.
Granting send-as when read access was enough
Send-as is powerful. If the user only needs to monitor messages, do not grant identity-level sending rights just to be nice.
Closing before Outlook updates
The admin portal can be correct while the user experience is still broken. Test webmail first, then desktop Outlook if that is what the user uses all day.
Confusing shared mailbox with distribution list
A distribution list sends copies to members. A shared mailbox gives users a shared place to work messages. The right answer depends on whether the team needs collaboration, history, and a shared sent folder.
Forgetting temporary access
Coverage access should have an end date. If nobody owns removal, it probably will not happen.
FAQ
How long does shared mailbox access take to work?
It depends on the platform and client. Webmail often reflects changes faster. Desktop Outlook may require a restart and can lag because of cached data or auto-mapping behavior.
What is the difference between full access and send-as?
Full access lets the user open and manage the mailbox. Send-as lets the user send messages that appear to come directly from the mailbox address. Many requests need one but not both.
Should help desk grant mailbox access from a chat request?
Usually no. Ask for the request to be documented in the ticketing system with the mailbox, user, business reason, permission type, and approval.
Should former employee mailbox access be treated differently?
Yes. Former employee mailboxes can contain sensitive or personal material. Follow HR, legal, manager, and retention policy before granting access or forwarding messages.
Bottom line
Shared mailbox access is simple only when the request is specific, approved, and tested. Slow down for two minutes at the start: who needs access, to which mailbox, for what reason, with which permissions, and for how long?
That tiny bit of structure prevents most follow-up tickets and keeps you from accidentally creating a permission mess that someone has to untangle during an audit.