KoltrixShared inbox vs distribution list vs alias: how each one works
Aliases, distribution lists and shared inboxes all route team mail, but they handle replies, read state, history and offboarding very differently. Here's how.
On this page(8 sections)
Three setups can all make support@ reach your team, and from the outside they look identical: someone sends an email and someone on your team gets it. The differences show up later, when two people reply, when someone goes on vacation, or when someone leaves the company.
This explainer walks through the mechanics of each option so you can pick the right one on purpose.
The alias: one address, one destination
An alias is an extra address that delivers into an existing mailbox. If support@ is an alias for maria@, every message to support@ lands in Maria's inbox, alongside her personal mail.
What actually happens:
- A customer sends to [email protected].
- Your mail server sees that support@ is an alias and delivers the message to Maria's mailbox.
- Maria reads it in her normal inbox. When she replies, her client may send from maria@ unless she switches the From address to support@ (if her setup allows it).
Where it works: a single person handles the address and it's fine for replies to come from them.
Where it breaks: as soon as a second person needs to see or answer that mail. There's only one copy, and it's in Maria's mailbox.
Some providers let an alias point at several mailboxes. At that point it behaves like a distribution list, described next.
The distribution list: one address, many copies
A distribution list (also called a group, a mailing list, or a forward to multiple people) takes each incoming message and delivers a separate copy to every member.
What actually happens:
- A customer sends to support@.
- The list expands to, say, four members.
- Four independent copies land in four personal inboxes.
- Each person reads, ignores, deletes or replies to their copy, and none of those actions is visible to the others.
That last point is the crux. Four copies means four separate read states, four separate decisions, and potentially four replies. If Alex replies, Jordan's copy still looks unread and unanswered. If Jordan also replies, the customer gets two answers, possibly contradictory ones.
Where it works: announcements and FYI mail, where everyone should read but nobody needs to reply. Think "all-staff@" or alerts that several people should see.
Where it breaks: anything that expects one coordinated reply, which describes most customer-facing addresses.
The shared inbox: one mailbox, many people
A shared inbox is a mailbox in its own right. support@ isn't a pointer to someone's personal mailbox; it's a place several people open and work in together.
What actually happens:
- A customer sends to support@.
- The message lands once, in the support@ mailbox.
- Everyone with access sees the same message, in the same state.
- When someone replies, the reply goes out from support@ and appears in the thread for everyone.
There's one copy of the conversation and one history. Whether a message has been read, replied to, labeled or archived is a property of the thread, not of each person's copy.
Where it works: customer-facing role addresses (support@, hello@, billing@, sales@) answered by more than one person.
Where it breaks: it doesn't, functionally, but it needs a small amount of process, like agreeing who replies to what, so that shared visibility doesn't turn into everyone waiting for someone else.
Side-by-side comparison
| Alias | Distribution list | Shared inbox | |
|---|---|---|---|
| Copies of each message | 1, in one person's mailbox | 1 per member | 1, in the shared mailbox |
| Who can see it | The mailbox owner | Every member, separately | Everyone with access, together |
| Reply comes from | Usually the person's own address | Each person's own address | The team address |
| Read and replied state | The owner's only | Separate per member, never synced | Shared across the team |
| Risk of duplicate replies | Low (one person) | High | Low, if visible who's replying |
| History when a new person joins | They see nothing | They see only new mail | They see the full history |
| When someone leaves | Their mailbox, and the history, goes with them | Their copies go; others keep theirs | Nothing is lost |
| Access control | Whoever owns the mailbox | List membership | Per-mailbox permissions |
The offboarding test
If you're unsure which setup you have, run this thought experiment: your most experienced support person leaves tomorrow. Their account is disabled.
- Alias to their mailbox: every past conversation with customers is now in a disabled account. Someone has to export it, or it's gone. New mail needs to be re-pointed.
- Distribution list: their copies are gone, but others have their own copies of most messages, except anything only that person replied to, which lives in their sent folder.
- Shared inbox: remove their access. Every thread, including their replies, is still there for the team.
This is often the moment teams realize which model they've been running on.
Common hybrids and their traps
- Alias plus "send as": one person receives, but several people can send as support@. Better replies, but still one person's mailbox holding the history.
- List plus a shared folder rule: members filter copies into a folder. Tidier, but the copies are still separate and states still don't sync.
- Shared password to a regular mailbox: technically a shared inbox, but with no record of who did what, no individual two-factor authentication, and a password that has to change every time someone leaves. Avoid this one.
Choosing quickly
- One person answers, and that's not changing soon: alias.
- Many people should read, nobody needs to reply: distribution list.
- More than one person replies to customers: shared inbox.
Key takeaways
- An alias delivers to one mailbox; a distribution list makes a copy per member; a shared inbox is one mailbox many people use.
- Distribution lists are great for FYI mail and poor for anything that needs a single coordinated reply.
- Shared inboxes keep one history and one state, so replies, vacations and departures don't lose context.
- If you're sharing a password to make a mailbox "shared," switch to real per-person access.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
