I run AliasFleet, an email-alias service, and this guide rests on one thesis: managing multiple business email addresses is an address-design problem, not an inbox-habit problem. One inbox, fed by aliases. A role gets an address, a vendor gets an address, each pausable on its own, with rules doing the filing. That is the whole system. Everything else is a workaround, and every workaround cracks at the same two points: a person leaves, or a vendor leaks.
The five-login shuffle
Open most small businesses' email and you find a small archaeological site. Layers. The owner's own address on top, a support@ underneath with its password pasted into a shared doc, a second account the office manager pipes into Gmail, and an ancient info@ somebody opens every Friday in case anything landed there. Nobody designed this. It accreted.
Google sells you tools to manage the rubble instead of clearing it. You can sign in to several accounts at once and switch between them, except Google warns it sometimes cannot tell which account you are using. You can pull up to 5 other email addresses into one Gmail over POP, except Google's own page warns that Gmailify and POP support are in flux. Neither reduces the inbox count. They just make the switching faster.
Then there is the shared password, quietly rotting the whole thing from inside. Microsoft's shared mailbox model rests on a single rule: nobody ever logs in as support@. The account carries a system-generated password nobody knows, and sign-in stays blocked. Gmail agrees, in blunter terms. Its delegation docs say that when several people sign in to one Gmail account from different places, Gmail may lock the account. The platforms treat a shared login as a defect, not a feature. Then somebody leaves and the cleanup becomes a project: rotate the password, tell the team, scrub every device, and hope the ex-employee does not keep the old one lying around. That drill has its own guide, written out in full.
Give every job its own address
Begin with roles, not people: support@, billing@, orders@, jobs@. Choose addresses that describe the work, and the work survives the worker. Customers print them and bookmark them. Nobody has to know who is answering this quarter. The person rotates; the address stays put.
Google Workspace makes this nearly free. Their admin docs allow up to 30 aliases per user at no extra cost, and an alias is just a forwarding rule that lands in the primary inbox. Their worked example is Juan: info@, billing@ and sales@ all land in juan@. Four addresses feeding one inbox, one login. The catch is ownership: one alias belongs to one user. When several people need the same address, Google sends you to delegation instead.
The same habit works for a team of one. Your name appears on nothing public. The public addresses are roles, and you answer all of them from a single inbox. The day you hire somebody, you reroute the address instead of renaming it.
Give every vendor its own address
The setup pays for itself with one move. Hand every vendor you pay regularly its own alias: the accountant, the supplier, the subscriptions, the landlord. The mail lands in the same inbox as everything else. The difference: the address itself now carries information.
When a phishing lure or a spam wave arrives on an alias that exactly one vendor ever had, the To field does the detective work for you. No header forensics. It is the same leak-attribution trick the consumer guides describe, aimed at the relationships that touch your money. For the mechanics, the setup guide walks through the three methods. The per-vendor version, with a pause control on each row, is where a dedicated alias service earns its keep.
AliasFleet's version is a single form: name, domain, forward-to inbox, organisation fields. The leak detection lives in the Company or Website field. Mail that alias from any company you did not name, and the system flags it as a leak on the spot.
Name it after the vendor. Come back to the list in six months and it reads as a map of who holds what, and that map is what saves you when something goes wrong.
How do you organise dozens of aliases?
This is where the unglamorous tools come in: categories and descriptions. Per the AliasFleet docs, categories organise without touching routing. Vendors tagged as vendors, roles as roles, and each description written for the hire who will read it years from now. They will.
The switch on every row
Give every alias an off switch of its own. Owning an address you can kill individually is a different thing from merely owning one. Per the AliasFleet docs, deactivating stops forwarding immediately while the alias keeps its history, ready to switch back on any time. Deletion is permanent. Deactivation is reversible; deletion is not. Spam gets paused, finished business gets deleted.
The dashboard shows what that looks like in practice: every row with its own active toggle, its destination inbox, who it was created for, and the mail it has seen. The day a vendor alias starts drawing lottery scams, one toggle kills that channel and nothing else. Their database never held your real address, so there is nothing left to chase.
Under the shared-password model, one compromised address poisons the whole mailbox, and the fix is a credential rotation on every device every person uses. An alias you can kill on its own turns the same incident into a ten-second errand.
Rules do the filing
Aliases route; rules file. Gmail filters take sender, subject or keyword and can label, archive, star, delete or forward. You can build one straight from a message with "Filter messages like these." The pattern for a business inbox looks like this:
- The public hello@ gets labelled and skips the inbox entirely, so the noise queues up for a batch review instead of interrupting you.
- billing@ gets starred and stays in the inbox, because money mail never waits for a batch.
- Mail to each vendor alias gets that vendor's label. Read down the labels and the inbox reads like a ledger.
On AliasFleet's Pro tier, an automated mail rules engine sits above the forwarding layer, handling the routing decisions Gmail filters cannot make. The split of labour stays the same either way. The alias records which address the message arrived on; the rule decides what happens to it. No second inbox in sight.
Do not use a catch-all
The catch-all deserves its own warning. It looks like a shortcut: one setting, and every address at your domain lands somewhere. The misspelled names, the dead addresses, everything. In Google Workspace it is a routing rule that diverts mail "sent to an unknown address" into one mailbox.
For a small business, it is a trap. The catch-all vacuums up every scraped, guessed and spammed address at your domain, leaving you with the highest-volume spam target you own. And because nothing is named, you get zero attribution: spam on a catch-all names no one. Named aliases, each with its own pause switch, cover everything the catch-all covers, with control. AliasFleet does offer catch-all routing on custom domains (a Pro feature), for the rare case where you genuinely need it.
A catch-all cannot tell a mistyped customer email from a dictionary attack. Every address at your domain becomes a valid address, which is exactly what spammers probe for. If you enable one, put a daily volume limit on it and watch it like a meter, not an inbox.
Offboarding is the real test
Every email setup looks solid until somebody leaves. That departure is the moment a design holds or collapses, which is the real argument for building on aliases instead of accounts.
The drill is one action per address: take the departed person's inbox off the destination list, or hand the alias to whoever takes the job. The address the world knows never changes. No password needs rotating, and no customer has to update anything. Google's own admin docs describe the Workspace version of the same recipe: delete a departed employee's account, then add their old address as an alias on a current user, and the mail keeps arriving. The shared team email guide covers the team-side mechanics, including the multi-destination setup where a single alias feeds up to five inboxes.
Onboarding is the same drill in reverse. A new hire means new destinations. A month-long contractor gets a destination added and removed on schedule. Nobody ever gets a password to the address itself. The address behaves like a pointer, and pointers get repointed.
Where the system stops
Two limits, and I will state them plainly: this piece is for people spending their own money.
First, everything here assumes the inbox underneath stays yours. If someone takes over that mailbox, they take over every alias on top of it. Switch on multi-factor authentication on the underlying mailbox first, before any of the rest. The honest version: this system takes one secure inbox as given, and everything here organises the addresses feeding into it.
Second, this system demands a discipline it cannot enforce. Handing the billing@ alias to a vendor out of habit is still on you, and so is answering a payment-change email without ringing the vendor on a number you already trust. An alias names the channel. It cannot verify the money. The small business email guide goes deep on the invoice-fraud version of this, and its rule holds here too: the phone call comes first.
The 30-minute version
- Write your role addresses down first: hello@, billing@, support@, orders@. The list is the design, and it comes before any settings.
- Attach them as aliases to your account: 30 per user at no cost on Google Workspace. In AliasFleet, they come from the form above, each with a destination inbox and a category.
- Issue each vendor you pay regularly its own alias, named after the vendor, with the vendor's name in the description field.
- Create the filters: public addresses labelled and archived, money addresses kept in the inbox, each vendor alias carrying its own label.
- Post two rules where the team can see them. No shared passwords on role addresses. When someone leaves, the destination moves, not the address.
That is the operations guide, the whole of it. One inbox, addresses that mean something, an off switch on every row, rules doing the filing. When the next vendor leaks you will know which one before your coffee cools, and the fix is a single click. For the machinery underneath, how email aliases actually work covers the forwarding rule, the reply trick and the kill switch; what an email alias is sorts the definitions if you want them. The docs handle destinations, custom domains and everything else.
Top comments (0)