Understand the practical difference between Microsoft 365 shared mailboxes and aliases for addresses such as accounts, sales and support.
Two businesses can both publish accounts@example.com while using completely different Microsoft 365 configurations. One may be an alias delivered into a person’s mailbox; another may be a shared mailbox used by a team. Choosing deliberately makes permissions, continuity and staff changes much easier.
An alias generally delivers mail addressed to an additional address into the same underlying mailbox. It is useful when one person owns several public addresses or when an old address should continue receiving mail. Because it is not a separate mailbox, it does not provide an independent inbox history or team workflow.
A shared mailbox can hold its own messages and folders while authorised users access it from their accounts. This suits functions such as accounts, reception or support where responsibility belongs to the business rather than one employee.
If all enquiries arrive as an alias in one employee’s personal mailbox, handover becomes awkward when that person leaves. A shared mailbox can keep the business correspondence associated with the role, subject to appropriate permissions and retention requirements.
Users may need read access, Send As permission or the ability to send on behalf of the shared address. Grant only what the workflow requires and test outbound identity. A mailbox that receives correctly but sends from the wrong address can confuse customers.
Some organisations create a normal licensed user for every generic address because it seems simple. Depending on Microsoft licensing rules and the mailbox’s requirements, a shared mailbox may be more appropriate. Check current Microsoft requirements for size and features rather than assuming every address needs a licence.
Adding an alias or shared mailbox usually does not require a new MX record. MX routes mail for the domain to Microsoft 365; Exchange then determines which recipient receives it. If the whole domain has delivery trouble, investigate DNS using our Microsoft 365 DNS guide.
Inventory aliases and shared mailboxes before moving providers. Otherwise the main user accounts may migrate successfully while important public addresses are forgotten. Our email migration checklist includes this step.
The right structure depends on who needs access and how correspondence should survive staff changes. TempWebz provides Microsoft 365 setup and business email support for small businesses that want mailboxes, aliases and permissions configured around real workflows.
Ask each intended team member to open the mailbox from their own account. Check receiving, replying and composing a new message. Read the From field on a message delivered to an external test account. Full Access alone does not grant permission to send; Microsoft explains the separate permissions in its shared mailbox setup guide.
Also check where sent messages appear. A colleague who can read incoming messages may still lack a complete record of replies. Microsoft documents how to keep copies in the shared Sent Items folder. Decide what the team needs before changing that setting, then test it from the Outlook clients they actually use.
Imagine a sole trader receives enquiries at both hello@example.com and the owner’s named address. An alias may fit while one person handles all correspondence. If two employees later take turns answering hello@example.com, a separate shared mailbox can make ownership clearer. The public address can stay familiar to customers while the internal workflow changes.
Before making that change, list any website forms, accounting tools or supplier records that use the address. Decide whether historical messages need to move and who can access them. Test the new arrangement before removing the old routing. A tidy mailbox structure should not interrupt enquiries or expose unrelated personal correspondence.
Assign a business owner to each shared address. Keep a record of who can read messages and who can send, and review it when staff responsibilities change. Use individual accounts rather than circulating a common password. Ask an authorised administrator to remove access that a departing staff member no longer needs.
Agree on a simple working convention too: who checks the inbox, how the team avoids duplicate replies and where unresolved requests belong. Mailbox permissions cannot replace that agreement. If the team needs formal assignment, response targets or a detailed case history, consider whether a support-ticket workflow would fit better than a shared inbox alone.
Finally, document the address, purpose, owner and recovery contact in the business handover record. Keep passwords and recovery secrets out of routine notes. This makes the next staffing change easier without turning a straightforward email decision into unnecessary complexity.