Rebuilding a Shared Team Inbox Without Buying Licences
Contoso (4,200 users, Microsoft 365 E3) merged two field-operations teams. IT built the new team inbox by creating a distribution list named [email protected] and a separate user mailbox [email protected], then granting 60 people Full Access and Send As through a PowerShell loop. Three weeks later: replies sent by staff land in each person's personal Sent Items, deleted mail looks inconsistent between users, and new hires sometimes wait hours before the team calendar appears. The department also wants a monthly all-hands announcement that the whole company can receive but only two managers can post to. Leadership asks whether to keep the current design or rebuild it, without buying new licences.
1. Which Microsoft 365 object should hold the team's shared correspondence, and what should happen to the two objects that exist today? Justify the choice against each symptom.
Read the worked answer
Decision: a shared mailbox, not a licensed user mailbox plus a distribution list.
Reasoning by symptom:
- Cost and scale - a shared mailbox consumes no licence and the 60 delegates sit comfortably inside documented delegation guidance. The current design burns one licence on ops-desk@ and still forces everyone through a second identity.
- Sent Items in the wrong place - with Full Access or Send As, Sent Items copy to the sender's own Sent Items by default. Shared mailboxes have explicit switches for this (
MessageCopyForSentAsEnabled,MessageCopyForSendOnBehalfEnabled). That is the actual fix; the object type alone does not solve it. - Inconsistent Deleted Items - a shared mailbox has one Deleted Items and one Recoverable Items tree, so all 60 people see the same state. The user mailbox with scripted delegation gives each client different delete behaviour.
- Calendar delay - that is Outlook auto-mapping and client caching, not a permission problem. Shared mailbox automapping has the same characteristic, so set expectations or add the mailbox manually.
Migration order (the risky part): [email protected] currently belongs to the DL and cannot also belong to a mailbox. Create the shared mailbox with a temporary address, migrate content, remove the alias from the DL, add it to the shared mailbox, then retire ops-desk@. Keep the DL alive until mail flow is verified - a distribution list cannot be converted directly into a shared mailbox, so the address move is the migration.
2. How should the all-hands announcement be distributed, and why is it not the same object as the team inbox?
Read the worked answer
Use a distribution list (or a Microsoft 365 group with restricted posting), not the shared mailbox.
- The requirement is one-way broadcast: 4,200 recipients, two authorised senders. A shared mailbox is a shared identity for correspondence; it has no membership model and no sender restriction.
- Sender restriction is the deciding factor. Configure the DL so only the two managers can send; without that, any recipient can reply to the list.
- Recipient limits matter here: a single message may not exceed 500 recipients, so typing 4,200 addresses into To: fails. Sending to the distribution list expands distribution-side and counts as one recipient, which is why a DL is the right tool rather than a giant To: line.
- Choose an M365 group only if the announcement should also have a shared mailbox archive, a SharePoint document library, or a Teams space. The trade-off: a group gives members a mailbox and posting rights that must then be restricted, and every message is stored in the group mailbox.
Do not reuse the shared mailbox for this: it conflates two different permission models and puts 4,200-recipient broadcast traffic into the team's correspondence store.
3. The CIO asks for one sentence on the biggest risk in this rework. What do you say, and what do you do about it?
Read the worked answer
The risk is the address cutover, not the mailbox creation.
[email protected] can only be attached to one mail-enabled object at a time. Every address move creates a window where inbound mail to that address either bounces or is delivered to the wrong object.
Mitigation sequence:
- Create the shared mailbox on a temporary address and grant the 60 delegates access - do this days ahead, not minutes ahead.
- Export or note the DL's current membership and any rules or delegates before touching it.
- Remove the alias from the DL, immediately add it as a proxy address on the shared mailbox, and send test mail from an external account.
- Only after delivery is confirmed, retire ops-desk@ and repoint documentation, signatures and the ticketing system.
Secondary risks worth naming: users who had ops-desk@ in their Outlook profile need it re-added, and any mail flow rules or connectors that reference the old address must be updated or they will silently stop matching.