Shared inbox naming works when each public function has one canonical address, one human owner, and a mailbox people can actually answer. Start with hello@, support@, and billing@. Do not mint info@, contact@, and help@ as extra aliases of the same founder Gmail. Forwarding is not a naming strategy, and a shared password is not a team inbox.
A common early-stage pattern: hello@, info@, contact@, and support@ all forward into one personal Gmail. The founder is the brand, the helpdesk, and the invoice desk. Six months later nobody knows who owns billing@ when the bookkeeper leaves, and the product still sends receipts from noreply@.
Arawa Mail is mailboxes plus sending on a company domain — not a helpdesk with assignment SLAs. Naming still matters because exact addresses collide in the company database, MCP attaches to one approved mailbox, and API-originated mail lands in Sent on the From address you chose.
The problem ad-hoc addresses create
Role addresses exist so customers know where to write and so your team knows who must answer. When four public names dump into one person, you get:
- Orphaned aliases nobody monitors
- A founder inbox that is also the public brand
- Transactional mail from addresses no human reads
- Offboarding surprises when the only “owner” was a shared password
Usernames (the local part) may contain letters, numbers, dots, underscores, and hyphens. Duplicate exact addresses are rejected. That is collision detection, not alias intelligence. Create the names on purpose.
Recommended starter set
For a three-person studio on a custom domain, three role mailboxes plus personal accounts is enough. No catch-all.
| Address | Purpose | Human owner | Answers transactional mail? |
|---|---|---|---|
| hello@ | Public brand / first contact | Founder or office lead | Only if that mailbox is monitored daily |
| support@ | Product and customer issues | Whoever is on support that week | Yes, if tickets and product alerts use this From |
| billing@ | Invoices, tax, vendor mail | Bookkeeper or ops | Yes for billing mail; keep it a real mailbox |
| firstname@ | Personal work mail | That person | No — do not send product receipts from a leaver’s address |
A 12-person SaaS adds sales@, jobs@, and privacy@ only when those functions have owners. Prefer one canonical name per function. You do not need both support@ and help@.
Should hello@ be a person or a role? A role. The person can change; the public name should not. Personal style (first.last@) is a separate decision from role taxonomy.
Do not create these by default
- info@ and contact@ next to hello@ — three doors to the same room
- help@ next to support@ unless you have two teams
- noreply@ as a From address customers cannot answer — see Stop sending from noreply@
- A catch-all instead of named mailboxes — see Should You Use a Catch-All Inbox?
- A second copy of an address “just in case”; exact duplicates are rejected anyway
Plus-addressing can tag mail on providers that explicitly support it. Arawa Mail’s public documentation does not promise plus-address routing. For an Arawa Mail role that needs its own address, create a real mailbox such as support@ or billing@.
Ownership, not shared passwords
Every role address needs a named human owner even if two people read it. When the bookkeeper leaves, billing@ still has to exist. Disable the leaver’s personal mailbox; do not delete history you may need. Permanent delete has no recovery. The offboarding checklist is in Employee email offboarding.
Do not run the team by sharing one password for hello@. That pattern is the problem a later access guide will solve. Name it now so you do not bake it into DNS and stationery.
Forwarding is not a shared inbox
Administrators can forward new inbound mail to verified destinations and keep a local copy. That is a copy path. It is not shared ownership, assignment, or a helpdesk. Forwarded copies count toward transactional allowance. Caps are plan-based; check current docs before you treat forwarding as capacity planning.
If the goal is “several people can answer support@,” you still want one mailbox named support@, a named owner and an explicitly supported access or helpdesk workflow, and a Sent folder you can audit. Product mail sent through the API also lands in Sent — so the From address on receipts should be a mailbox someone watches. See Receipts from a real address and Support should see the transactional email log.
For the hosting-versus-forwarding distinction, read Email forwarding vs mailbox hosting.
Same address for receipts and replies?
Yes, when humans monitor that mailbox. A good pattern is receipts@ or billing@ as both From and Reply-To for invoices. A bad pattern is noreply@ for receipts and founder@ for everything else.
Mailbox sending requires the domain to be sending-active and is rate limited per account. Role inboxes that also send product mail must be real accounts on a receiving-active domain, not decorations.
Naming is a prerequisite for assistants
An AI assistant connected over MCP can attach to one approved mailbox. If support@, help@, and hello@ are three names for one neglected Gmail forward, the assistant has nothing clean to triage. Pick the canonical support mailbox first; connect tools second.
Product boundaries
Arawa Mail documents mailboxes, administrator access, verified forwarding, outgoing webhooks, and mailbox-scoped MCP. It does not promise delegated shared-mailbox access or plus-address routing. For several agents answering support@, feed a helpdesk through an outgoing webhook rather than sharing the mailbox password.
A two-minute naming checklist
- One public name per function
- A human owner written down for each role address
- No catch-all as a substitute for names
- Transactional From addresses that accept replies
- Personal mailboxes for people; role mailboxes for functions
- No shared password as the access model
When you are ready to mint the first custom-domain accounts, use How to set up a custom-domain email address for a small business.
FAQ
Do we need both support@ and help@?
Almost never. Pick one canonical support address. A second name is justified only when a second team owns it.
Who owns billing@ when the bookkeeper leaves?
The company does. Disable the person’s mailbox; keep the role address and assign a new owner. Do not delete the only copy of vendor mail.
When is plus-addressing enough instead of a new mailbox?
Only when your provider explicitly supports plus-address routing. Arawa Mail does not document it; use a real mailbox for each required role.
Is forwarding the same as a shared inbox?
No. Forwarding copies inbound mail to a verified destination. A shared inbox is a named mailbox with an owner and people who can sign in without sharing one password.
Sources and review
Reviewed against the linked documentation on 3 October 2026. Examples are illustrative; code that depends on application models must be adapted and tested in your own project.