Every team ends up with a support@. Somebody creates the mailbox and shares the password around. From that day, the address belongs to everyone who ever had the password, including people who left. I run AliasFleet, an email-alias service built for teams that route, not share: no shared password, a team address routes to whoever needs it today.
AliasFleet is built around that idea: on the Business plan, one alias can forward to up to 5 destinations, so a team address reaches exactly the inboxes that need it and nobody else.
The password is the problem, not the address
Here is the honest version of the problem. Three setups exist for a team address. One: a normal mailbox with one password in a shared doc. Two: a Microsoft 365 shared mailbox. Three: a Google Group with the collaborative inbox turned on, or a delegated account. Only the first one has a shared password. The other two were designed specifically to avoid it.
Microsoft's documentation is blunt on the point. A shared mailbox exists for exactly this case, addresses like support@ and info@ that several people need. Every shared mailbox has a corresponding user account with a system-generated password that is, in Microsoft's words, not known and not intended for use. The guidance says to block sign-in for that account and keep it blocked. Nobody logs in as support@. People open it through their own licensed accounts, and that is the entire security model.
Google's version rhymes. A collaborative inbox lets members take a conversation, assign it to someone else, and mark it complete, duplicate, or needing no action, all from their own accounts. And Gmail delegation hands someone access to an account without handing them the password at all, up to 10 delegates on a personal account and 1,000 on Workspace, none of whom can change your password. Even Google's failure mode is instructive: if several people sign in to the same Gmail account from different places, Gmail may lock it. The platforms treat a shared login as a malfunction, not a feature.
So the industry consensus is real and it is old: the address is not a credential. The odd one out is the setup most small teams actually run, one mailbox and one password, because it takes five minutes and nobody is watching. A British IT firm put it plainly in September 2026: shared accounts remain "surprisingly common within SMEs", and many businesses simply do not know who has access to what anymore.
Two stories about the shared password going wrong
In 2019, an IT consultant wrote up what happened when a business fired a disgruntled employee. The individual account was disabled. But the shared mailbox password was known, because it had been reset and handed out so people could open the shared mailbox on their phones. The ex-employee connected straight back in over IMAP and sent hostile emails to all staff from the company address, and was caught only because they used their own ISP's IP address. The password did exactly what shared passwords do: it outlived the employment.
Five years later, an Australian workplace tribunal heard a stranger version of the same failure. At a retail store in Miranda, New South Wales, every member of staff used an identical password, and the passwords were posted on a company dashboard. When a confidential email about a worker's roster was forwarded to that worker's personal account, nobody could prove who had opened the original. The Fair Work Commission found the employer had failed "even the most basic of appropriate security measures, including individualised and secure passwords" (HCA Magazine's report), ruled the dismissal unjust, and awarded $1,334.75 in compensation. Sit with that for a second: the company lost because it could not show who opened its own email.
Both are offboarding stories: the address outlived the person's employment, and the credential did too.
What the offboarding drill actually costs
When someone leaves a team that shares one password, the correct procedure is a small project. An IT firm that works with small businesses lists it plainly: change the password everywhere it is used, tell every remaining employee the new one, update every application and device that had the old one, and hope no former employee still remembers it. Their honest footnote: many businesses skip these steps altogether.
Then there is multi-factor authentication. MFA is built for one person, and on a shared account the questions answer themselves: whose phone gets the code, who approves the login, what happens when they are on holiday. Most shared accounts end up with MFA disabled or half implemented.
Then there is the audit trail, which nobody thinks about until something goes wrong. With one login, "who sent that email" has no reliable answer, so when investigators find suspicious activity on the shared account, the investigation turns into guesswork. The Australian tribunal case is that sentence made real.
On Microsoft's own Q&A forum, the accepted answer on sharing one mailbox credential among several people puts it bluntly: it violates Microsoft's licensing and security guidelines, and it breaks MFA. (That is a community answer, not Microsoft legal.) Offboarding is where the shared-password inbox fails hardest, because the fix is a drill and drills get skipped.
The routing model: the address is a pointer
An email alias is a routing rule, not a mailbox. Nothing about that changes when the alias belongs to a team: shared team email aliases apply that rule to a roster instead of a person. support@ becomes a pointer: mail arrives, the rule looks up who owns it today, and copies go to those inboxes. One address, many destinations, no shared credential.
On AliasFleet this is literal: the Business plan forwards one alias to up to 5 destinations. Add one when someone joins the rotation; remove it when they leave. The address the world knows never changes: no password to rotate, no email to the team announcing the new one. If the team owns its domain, connect it (Pro covers up to 3 custom domains, Business up to 10, per the pricing page) and support@yourcompany.com is a routed alias like any other.
Each person's copy arrives in their own inbox (on plans with alias banners or subject prefixing, labelled with the alias it came through), so the alias list reads as a map of who holds what. That labelling is the same mechanism the leak-tracing guide is built on: the address on the message names the relationship.
Replies work the same way they do for a personal alias. Two-way reply routing sends the answer from the alias address, so whoever you write back to never sees anyone's personal address. And pausing is per-alias and instant: if a team address starts getting abused, one click stops the flow for everyone without deleting anything.
The habit is the same one the one-alias-per-site guide describes, pointed at people instead of websites.
When someone leaves, you change the routing, not the password. The address the world knows stays exactly the same.
A departure, step by step
Make it concrete. Priya runs support with two colleagues. support@ is an alias with three destinations: their three inboxes. One of them moves to a different team.
- Remove that inbox as a destination. One action. Their personal email is untouched. The team's address is untouched. Customers notice nothing, because there is nothing to notice. Compare that with the drill from the last section: new password, notify everyone, update devices, hope.
- Do the same for temporary cover. A contractor triaging careers@ for a month gets their inbox added as a destination and removed at the end of the month.
- Let seasonal addresses expire. For addresses with a natural end date, like a seasonal hiring round, the alias itself can carry a self-destruct timer, so gradscheme-2026@ dies on schedule instead of lingering in somebody's memory of old passwords.
What routing does not give you
I have never run a support queue, so I will not pretend the shared view has no value. Here is what the routing model honestly lacks.
First, there is no shared queue. Mail lands in each person's own inbox, which is exactly the point, and also exactly what a team loses: one screen where everyone watches the same pile. If your team needs that, Microsoft's shared mailbox or Google's collaborative inbox is still the honest answer. Routing and shared mailboxes solve different halves of the problem.
Second, the team-routing feature is a Business feature. The free tier covers a single destination per alias, which is right for one person and wrong for a team. I would rather say it here than have you discover it mid-setup.
Third, internal discussion about a message still lives wherever your team talks: the alias moves the mail, it does not replace the channel where you decide what to do with it.
Fourth, a routed alias has no shared calendar and no shared sent folder. If the team's workflow leans on those, the shared mailbox keeps its edge.
The address outlives the team
People rotate: contractors come and go, colleagues change teams, the person who set the whole thing up leaves. The address the world knows should not rotate with them.
The whole case for treating a team address as a routing rule: the world gets one stable address, and inside it points at whoever needs it today. When the team changes, the pointer changes, and the password question never comes up, because there is no password to share.
If you want the mechanics, how email aliases actually work walks through the forwarding rule, the reply trick, and the kill switch. The docs cover destinations and custom domains. Start with one team address, the one whose password is currently in the most places, and route it instead.
Top comments (0)