Almost every business needs a shared address. Accounts wants an inbox at accounts@ that the whole finance team can see, sales wants enquiries@ so a lead never sits unread while one person is on leave, and the front desk wants info@ answered by whoever is at their desk. A shared mailbox in Microsoft 365 does exactly this, and for most businesses it costs nothing to run.
The mechanics are straightforward once the licensing rule is clear. What causes the confusion Frontrow sees most often is the permissions layer, the difference between Full Access, Send As and Send on Behalf, and the automapping behaviour that decides whether the mailbox appears in Outlook on its own. This guide walks through the licensing rule first, then every method of creating a shared mailbox, then permissions, conversion, and the decision between a shared mailbox and the two things people most often confuse it with.
What a shared mailbox is, and the one licensing rule that matters
A shared mailbox is a mailbox that several people open and send from using their own sign-in. It has no username and password of its own and nobody logs into it directly. It has a single email address and a shared calendar, and every reply sent from it goes out from the shared address rather than the individual staff member's name. That is what makes it right for a team address like support@ or orders@.
The licensing rule is the part worth getting right before anything else. A shared mailbox can store up to 50 GB of data without a licence assigned to it. That covers the large majority of team inboxes. Three situations change that:
- To grow the mailbox beyond 50 GB (up to a 100 GB limit), it needs an Exchange Online Plan 2 licence assigned to it. Plan 1 on its own does not raise the storage limit.
- To place the mailbox on Litigation Hold or an In-Place Hold, it needs an Exchange Online Plan 2 licence, or an Exchange Online Plan 1 licence with the Exchange Online Archiving add-on, assigned to the mailbox itself.
- To give the mailbox its own archive with auto-expanding archiving, the same licensing applies as for hold: Plan 2, or Plan 1 plus the Archiving add-on.
Method 1: create a shared mailbox in the Microsoft 365 admin center
This is the path for most administrators. It needs no scripting and takes about a minute.
- 1Sign in to the Microsoft 365 admin center at admin.microsoft.com with an account that holds an admin role.
- 2In the left navigation, open Teams & groups, then Shared mailboxes. If Teams & groups is not visible, select Show all at the bottom of the navigation first.
- 3Select Add a shared mailbox, then enter a display name such as Accounts. The email address is generated from the name and can be edited before saving.
- 4Select Save changes. The mailbox is created within a few minutes.
- 5On the confirmation screen, select the option to add members. The people added here are given permission to read and send from the mailbox.
The member step is the one to slow down on. Adding a member here grants both Full Access and Send As, which is the combination most teams want, but it is worth being deliberate about which staff get send rights rather than adding the whole department by reflex.
Method 2: create a shared mailbox in the Exchange admin center
The Exchange admin center gives finer control over recipient settings and is where an administrator already working on mail flow or delegation will tend to be. Note that only the current Exchange admin center exists now; the classic version was retired in September 2022, so older guides that reference it are out of date.
- 1Sign in to the Exchange admin center at admin.exchange.microsoft.com.
- 2Open Recipients, then Mailboxes.
- 3Select Add a shared mailbox, then supply the display name, alias and email address.
- 4Save, then open the new mailbox and use the Delegation section to assign Read and manage (Full Access), Send As, and Send on behalf permissions as needed.
Method 3: create a shared mailbox with PowerShell
PowerShell is the method for creating mailboxes in bulk, scripting a repeatable build, or handing a documented procedure to another engineer. Connect to Exchange Online Management first, then create the mailbox with a single cmdlet.
Connect the session (the module is regularly updated; recent releases require PowerShell 7.6 or later, and the older Remote PowerShell protocol is being retired in favour of the REST-based cmdlets):
"Connect-ExchangeOnline -UserPrincipalName admin@contoso.com.au"
Create the shared mailbox:
"New-Mailbox -Shared -Name "Accounts" -DisplayName "Accounts" -Alias accounts -PrimarySmtpAddress accounts@contoso.com.au"
The -Shared switch is what makes it a shared mailbox rather than a user mailbox. To change settings later, such as adding an alias or adjusting properties, use Set-Mailbox against the same identity.
Granting the right permissions: Full Access, Send As, and Send on Behalf
Permissions are where a shared mailbox either works cleanly or generates support tickets. There are three distinct rights and they answer different questions.
Full Access
Full Access lets a person open the mailbox, read everything in it, and manage its contents and calendar. It does not, on its own, let them send email that appears to come from the shared address. Grant it with:
"Add-MailboxPermission -Identity accounts@contoso.com.au -User jordan@contoso.com.au -AccessRights FullAccess -InheritanceType All"
Send As
Send As lets a person send email that appears to come directly from the shared address, with no sign that an individual sent it. For a support@ or accounts@ inbox this is usually what is wanted, so that replies read as coming from the team. Grant it with:
"Add-RecipientPermission -Identity accounts@contoso.com.au -Trustee jordan@contoso.com.au -AccessRights SendAs"
Send on Behalf
Send on Behalf sends from the shared address but shows the recipient that a named person sent it, rendered as 'Jordan on behalf of Accounts'. This suits mailboxes where accountability matters, such as an internal approvals address, and it is deliberately more transparent than Send As. Grant it with:
"Set-Mailbox -Identity accounts@contoso.com.au -GrantSendOnBehalfTo @{Add="jordan@contoso.com.au"}"
Converting an existing user mailbox to a shared mailbox
A common scenario: a staff member leaves, and their mailbox needs to stay reachable so the team can pick up replies to their address. Converting that user mailbox to a shared mailbox keeps the history and the address, and lets the paid licence be reclaimed.
The order of operations matters. The mailbox must still have a licence assigned at the moment of conversion, otherwise the option does not appear, so if the licence was already removed it needs to be re-added first. In the Exchange admin center, open Recipients, then Mailboxes, select the mailbox, and choose Convert to shared mailbox. The PowerShell equivalent is:
"Set-Mailbox -Identity alex@contoso.com.au -Type Shared"
Once the conversion is complete and the mailbox is under 50 GB, the licence can be removed and returned to the pool. Two cautions. Do not delete the underlying user account, because it anchors the shared mailbox and removing it takes the mailbox with it. And confirm the mailbox size before pulling the licence, because a long-serving staff member's mailbox plus archive can sit above 50 GB, in which case the licence needs to stay or the mailbox needs trimming first.
Try it
Find licences you can reclaim
Converting departed-staff mailboxes to shared is one of the more reliable ways to return paid licences to the pool. This tool gives an initial read on where licences are assigned but not earning their keep, before a full review with Frontrow.
Shared mailbox, distribution list, or Microsoft 365 Group?
These three get chosen interchangeably and they are not interchangeable. Picking the wrong one is behind a good share of the 'why can nobody see the replies' questions Frontrow fields.
Shared mailbox
A single inbox and calendar that a team works from together, under one address, with each person using their own sign-in. The right choice when incoming mail needs to be seen, triaged and replied to as a group, which is the case for info@, support@, accounts@ and orders@.
Distribution list
A distribution list sends a message on to each member so they read it in their own inbox. There is no shared inbox to work from and no shared calendar, and it is built for one-way announcements rather than collaborative handling. Use it when the goal is to reach a group, such as all-staff@ or a team notification address, not to manage replies together.
Microsoft 365 Group
A Microsoft 365 Group carries a shared inbox and calendar like a shared mailbox, but adds a SharePoint site, shared files, a Planner, and the option to connect Microsoft Teams. It suits a project or department that needs a place to collaborate, not just an address to answer. The trade-off is weight: for a plain team inbox with no files or Teams requirement, a Group is more moving parts than the job needs, and a shared mailbox is the cleaner fit.
A useful rule of thumb: if the team only needs to see and answer email from one address, use a shared mailbox. If they need to reach people with announcements, use a distribution list. If they need a shared workspace with files and tasks around that email, use a Microsoft 365 Group.