Most contractor offices end up with a few email addresses that belong to a job, not a person: bids@ for invitations to bid, service@ for customer requests, maybe updates@ for schedule notes to the crew. In Microsoft 365, the two usual ways to set those up are a shared mailbox and a distribution list (Microsoft also calls it a distribution group). Both give you one address, but they handle incoming mail very differently.
The quickest test is whether someone has to answer as that address, in one company thread.
One question decides it
Answer mail
Shared mailbox
- Each message is stored once, in one mailbox
- History stays there for people added later
- People given send permission can reply as the address
One-way notices
Distribution list
- Every member gets their own copy
- The list keeps no company copy of the thread
- A new hire doesn’t get the old messages
You can use both. Neither one decides who replies.
This guide covers Microsoft 365. Google Workspace handles shared addresses with its own tools, which work differently.
Shared mailbox vs distribution list: one copy or many
A shared mailbox is one mailbox that several people use, like a support or bids address. Microsoft’s comparison of group types notes it comes with a calendar too, though nothing in it assigns who replies. A distribution list is built for one-way updates. It broadcasts a message, each member gets a separate copy in their own mailbox, and the list keeps no company copy of the thread. That’s the whole difference: one stored message, or a copy in every member’s mailbox.
It shows up when people come and go. History stays in the shared mailbox, including for someone added later, so a new estimator can read last month’s bid thread there. With a list, a new hire doesn’t inherit anything. The old messages still sit in other people’s mailboxes, but they were never one company file.
Bids and service requests from outside the company need that single thread. Internal schedule notes don’t. There’s also a setting to watch. Microsoft’s distribution group guide says that by default a list only accepts mail from people inside your organization, and rejects outside mail until an admin allows senders inside and outside. An admin can change that, but a bids@ list left on the default will turn away outside bidders.
For a shared mailbox, Microsoft’s comparison page says it can receive outside email if an admin has enabled it, but doesn’t say whether that starts on or off. Either way, confirm with your admin that outside bidders can reach the address.
What a shared mailbox won’t do for you
Two estimators can both hit reply on the same invitation to bid, and the mailbox won’t pick one of them. Who answers, and who can see what was sent, aren’t automatic.
When someone asks for a “shared inbox,” this is usually what they mean. But features like assigning messages, warning you when a coworker is already replying, and reports come from separate add-on tools, some paid and some with a free tier. They aren’t part of the shared mailbox.
Opening a message isn’t the same as owning the reply
Full Access, the permission that lets people open the mailbox, means more than one person can open the same message. It doesn’t assign the reply. Microsoft’s permissions guide also says Full Access doesn’t let the person send. So the office manager needs to name who checks for unanswered mail. That job isn’t a feature of the mailbox or of the list.
Don’t assume sent replies land in the shared mailbox
Don’t assume the whole team can see what was sent from the shared mailbox, because Microsoft’s own pages describe the default differently. Its troubleshooting article on sent mail says mail sent as or on behalf of a shared mailbox is saved in the sender’s own Sent Items, not the shared mailbox, until a copy setting is turned on. But a later step in its guide to converting a list into a shared mailbox says mail sent as the shared mailbox isn’t copied to the sender unless a setting is changed. Since the two don’t agree, ask your admin where sent copies are stored before you treat the shared mailbox as the record of what went out.
An alias or a Microsoft 365 Group is a different choice
An alias is just another address on an existing mailbox. Mail sent to the alias lands in that same inbox. It isn’t a team inbox. Microsoft’s guide to email aliases tells admins who want several people on an address like info@ or sales@ to create a shared mailbox instead. So if two estimators need to share bids mail, an alias on the owner’s mailbox is the wrong thing to ask for.
A Microsoft 365 Group is a collaboration workspace: email plus shared files, a calendar, Planner for tasks and, optionally, Teams. For a small bid desk, it’s the wrong default. Microsoft’s comparison page also notes that a shared mailbox can’t be migrated to a Microsoft 365 Group.
An example: bids@ and updates@
Take a made-up company at example.com, Northline Example Contracting, on Microsoft 365. Its bids@example.com address gets invitations to bid from general contractors. Two estimators and the office manager all need to see each request, and exactly one of them should answer. The general contractor should see the reply come from bids@example.com, not a personal address, and a new estimator should be able to read last month’s thread.
The second address, updates@example.com, carries one-way schedule notes from the owner to the office and field staff. Nobody should answer as updates@example.com.
Two addresses, two different jobs
Who receives it?
- bids@example.com
- Everyone given access to the one shared mailbox sees the same incoming message.
- updates@example.com
- Each member of the distribution list gets a separate copy.
Where does history live?
- bids@example.com
- In the shared mailbox, including for someone added later.
- updates@example.com
- Only in each person’s own mailbox. A new hire doesn’t inherit old copies.
Who can send?
- bids@example.com
- Only people given Send As, or Send on Behalf if the admin chooses it and you’re fine with the “on behalf of” label. Full Access alone can’t send.
- updates@example.com
- Membership doesn’t create a shared From address. A delegate can be given Send As or Send on Behalf on the list, but there’s still no shared inbox of replies.
Who owns follow-up?
- bids@example.com
- A named person, like the office manager, checks what’s unanswered. The mailbox doesn’t assign that job.
- updates@example.com
- Nobody. Replies aren’t expected, which is why it’s the wrong kind of address for bids.
| Question | bids@example.com | updates@example.com |
|---|---|---|
| Who receives it? | Everyone given access to the one shared mailbox sees the same incoming message. | Each member of the distribution list gets a separate copy. |
| Where does history live? | In the shared mailbox, including for someone added later. | Only in each person’s own mailbox. A new hire doesn’t inherit old copies. |
| Who can send? | Only people given Send As, or Send on Behalf if the admin chooses it and you’re fine with the “on behalf of” label. Full Access alone can’t send. | Membership doesn’t create a shared From address. A delegate can be given Send As or Send on Behalf on the list, but there’s still no shared inbox of replies. |
| Who owns follow-up? | A named person, like the office manager, checks what’s unanswered. The mailbox doesn’t assign that job. | Nobody. Replies aren’t expected, which is why it’s the wrong kind of address for bids. |
So bids@example.com should be a shared mailbox, and updates@example.com a distribution list. Giving someone send rights on the list, which Microsoft’s permissions guide and distribution group settings both allow, doesn’t change that. There’s still no shared mailbox of replies.
In this example, the shared mailbox replaces a pile of personal copies with one company file. Making sure only one estimator answers is still a staffing rule, not a setting.
If your bids@ is already a distribution list, know that Microsoft says there’s no automated way to convert a list into a shared mailbox, and its steps don’t cover moving the copies already sitting in people’s personal mailboxes.
For the rest of your company addresses, see our guide to setting up company email.
What to decide before you ask an admin
Send As versus Send on Behalf
Full Access lets someone open the mailbox and change items in it. It doesn’t include sending. Microsoft’s guide to shared mailboxes in Exchange Online and its permissions guide both say so. Sending takes one of two separate permissions:
- Send As makes the message look like it came from the mailbox itself. On its own, it doesn’t let you read the mailbox.
- Send on Behalf shows your name “on behalf of” the mailbox. Replies go to the mailbox or list, not to you.
If someone has both, Send As is the one used. According to those same pages, Send on Behalf for a shared mailbox isn’t a switch in the Exchange admin center. Your admin grants it with PowerShell, Microsoft’s command-line tool.
Does a shared mailbox need a license?
Not for the mailbox itself, up to a point. Microsoft’s overview of shared mailboxes says one can store up to 50 GB without its own license. But each person who opens it needs a licensed Exchange Online mailbox, on a subscription that includes Exchange. Microsoft 365 Apps for business doesn’t include email. Microsoft 365 Business Standard does.
More storage, an archive or a litigation hold (preserving mail for a lawsuit or investigation) can need extra licensing, so ask your admin which plan you have. Microsoft’s Exchange Online limits can also vary with how long your organization has been on Microsoft 365, and Education plans can differ on storage.
Questions to settle with your admin
- Is this address for answering mail, or for one-way announcements?
- Who can read it?
- Who can send as the address, and is “on behalf of” acceptable?
- Which named person owns mail nobody has touched?
- Do outside senders need to get through? Check the delivery setting on a list, or confirm a shared mailbox accepts outside mail.
- Does the team expect sent replies to show up in the shared mailbox? Ask where sent copies are stored.
Once your admin has given you access, here’s how to add a shared mailbox in Outlook.