Aliases, Shared Inboxes & Plus Addressing for Company Email

Default answer: On day one create three real mailboxes—founder@ (or your name), hello@, and billing@—then add support@ when someone will answer it. An alias, plus-address, shared inbox, forward, and catch-all are different tools. ArawaMail documents mailboxes, verified forwarding, catch-all, outgoing webhooks, and MCP against one approved mailbox. It does not document aliases, plus-address routing, send-as, or a shared-mailbox license. Name the roles; do not turn on catch-all “just in case.”

The three addresses every company should name first

Most first-domain setups fail the same way: one personal mailbox, a catch-all “in case someone emails info@,” and everything forwarded to Gmail. That hides who owns each conversation and trains the team never to create the addresses customers already expect.

Map roles before you click Create account:

• A person address — [email protected] or [email protected]. Login, drafts, sent mail, and a sending identity that a human owns.
• A public company address — usually hello@. Printed on the site, invoices, and WhatsApp bios. This is not a vanity alias for the founder; it is a role mailbox with a named owner.
• A money address — billing@ or accounts@. Vendors, banks, and tax software keep this on file for years. Create it even if the same person also owns hello@.

Add support@ when a second person will answer tickets. Do not invent noreply@ as a public identity; that pattern is covered in Stop sending from noreply@.

Mailbox, alias, plus-address, shared inbox, forward, catch-all

Search results mix these terms because Google Workspace and Microsoft 365 sell aliases and shared mailboxes as first-class objects. Treat the words as industry vocabulary, then pick the object your provider actually has.

Term	What it is	Separate login?	When it is the right tool
Mailbox	A full account: username@domain, folders, storage, send path.	Yes	Every role that must receive, store, and send as that address.
Alias	An extra local-part that delivers into an existing mailbox. No second password.	No	Controlled variants of one person’s address on platforms that document aliases.
Plus-addressing	[email protected] routed to ada@. A filter tag, not a secret identity.	No	Inbox rules on providers that honor +. Many signup forms reject the character.
Shared / role inbox	One functional address a team answers (support@, billing@).	Depends on the product	When ownership and “who may send as this address” matter more than the label.
Verified forwarding	A copy leaves the mailbox to a confirmed destination. Local copy stays.	n/a	A second pair of eyes—not a substitute for creating the role mailbox.
Catch-all	Accept any unknown local-part and drop it in one designated mailbox.	Uses an existing mailbox	A short, named miss (legacy printed info@), not day-one design. See Should you use a catch-all inbox?.

An alias is not a shared inbox. Plus-addressing is not disposable email. Catch-all is not “aliases for everything we forgot.”

Should hello@ be an alias or a mailbox?

A mailbox. hello@ will collect sales, press, and “is this the right address?” mail for the life of the company. It needs its own login, retention, and sending identity so a founder offboard does not take the public address with them.

On platforms that sell aliases, folding hello@ into ada@ looks cheaper on day one. It fails the first time Ada leaves, the first time two people must answer the same thread, and the first time you want product mail and human mail on separate credentials. Create the role mailbox. If the same person reads both, they can keep two logins—or later connect a helpdesk—without sharing one password across laptops.

What ArawaMail actually provides

Product claims below follow the live ArawaMail docs for email accounts, receiving, mailbox, outgoing webhooks, and AI assistants. They do not invent an alias UI.

• Receiving first. At least one domain must have receiving active before any account can be created. Connect the zone (typically Cloudflare) and turn receiving on, then add mailboxes. The setup path is in How to connect a Cloudflare domain to ArawaMail.
• An account is username@domain. Usernames may contain letters, numbers, dots, underscores, and hyphens. Docs do not treat + as a routing token. Duplicate addresses are rejected company-wide.
• No documented alias, plus-addressing, send-as, or shared-mailbox license. If you need another local-part, create another mailbox. If you need a short safety net for unknown local-parts, that is catch-all on one active mailbox—not an alias list.
• Verified forwarding is a documented stand-in for “send a copy somewhere else.” Destinations must confirm within 24 hours. Plan caps: Free 1, Pro 5, Business 10 destinations. Forwarded copies count toward the monthly transactional allowance. A local copy is kept. Reply-To is set to the original sender. Forwarding is not a reason to skip creating hello@.
• Outgoing webhooks can feed a helpdesk instead of sharing one mailbox password. Filter by full mailbox or bare domain. Endpoint must be HTTPS, 15-second timeout, up to three retries at 30 seconds / 2 minutes / 5 minutes. Deduplicate on id or message_id.
• MCP / AI assistant attaches to the one mailbox approved in the consent flow. The assistant cannot open another mailbox, manage drafts or spam, download attachments, permanently delete mail, or administer domains. An agent answering support@ is still one mailbox plus one consent—not a team shared-inbox SKU. Related context: Give agents a mailbox, not just an API key.
• Disable mailbox immediately blocks mailbox, SMTP, mobile, and connected AI-assistant access. The disabled address cannot send or act as catch-all. Inbound falls through to the domain catch-all if one is set; otherwise it is discarded. Admins can open retained mail but cannot send as the disabled mailbox.
• Sending from a mailbox requires the domain to be sending-active and is rate-limited per account. Plans document team members (Free 1 / Pro 10 / Business 50), domains, storage, transactional caps, and retention—not an alias quota. See pricing and business email.

How we checked the product surface

This piece is an address-design guide, not a feature announcement. On draft day we re-read ArawaMail’s introduction, email-accounts, mailbox, sending, outgoing-webhooks, and AI-assistant (MCP) docs. Those pages describe mailboxes and the stand-ins above. They do not describe aliases, plus-routing, or send-as. If that changes, the product section should be rewritten from the live docs—not from Workspace or Microsoft 365 vocabulary.

Who owns support@ when three people answer it

One mailbox. One named human owner on the company side. Everyone else works through that mailbox or through a helpdesk fed by outgoing webhooks.

Sharing one password across three laptops looks like a “shared inbox.” It is actually one credential with no audit trail, no offboarding story, and a sending identity that any laptop can burn. Prefer:

1. Create support@ as a real mailbox.
2. Name the person who may send as that address today.
3. Route copies into the ticketing tool with an outgoing webhook, filtered to that mailbox.
4. When someone leaves, disable the mailbox only if the role is retiring. If the role continues, keep support@ and rotate access around it—do not delete the address customers already have.

Clients that already live on IMAP can keep using IMAP; POP3 is the wrong default for a role box several people may open. That choice is covered in IMAP vs POP3 for business email.

Should receipts use plus tags?

Only on a provider that documents plus-addressing, and only as a filter—not as privacy. [email protected] is still Ada. Anyone who sees the tag can strip it and write to the base address. Many billing forms reject +.

ArawaMail usernames allow letters, numbers, dots, underscores, and hyphens. Docs do not promise that ada+stripe@ will route into ada@. Do not print plus-tags on invoices for an ArawaMail mailbox. If you need a dedicated receipt address, create receipts@ or billing@ as a real mailbox.

Day-one setup that does not use catch-all as a design tool

1. Connect the custom domain and activate receiving.
2. Create founder@ (or the operator’s name), hello@, and billing@.
3. Leave catch-all off unless you can name a printed leftover such as info@. If that leftover exists, either create info@ as a mailbox or enable catch-all for a short bridge, then turn it off. The on/off rule lives in the catch-all essay.
4. Create support@ when a person will answer it. Wire a webhook to the helpdesk instead of sharing the password.
5. Keep reading mail in the ArawaMail mailbox. Forwarding a copy is fine; forwarding everything to Gmail and never opening the local copy is how role history disappears. Teams leaving Workspace can follow How to move business email off Google Workspace without collapsing every role into one personal Gmail.

The anti-pattern is one founder mailbox plus catch-all, plus forwarding to a free Gmail, plus never creating hello@. That is the opposite of custom-domain email vs Gmail: you paid for the domain and then hid the company addresses.

When you still think you need an alias

You probably need another mailbox, or you need a time-boxed catch-all.

• Printed leftover (info@, sales@) — create the mailbox, or catch-all briefly while you update the print.
• Two spellings of one person — create the second mailbox only if both addresses must send. Otherwise pick one local-part and update signatures.
• Vendor that rejects dots or plus — create a simple role mailbox (billing@) rather than hoping plus-routing exists.
• Team answering one address — one role mailbox plus webhook, not a shared password.

ArawaMail will reject a second account with the same address. Choose another username or update the existing account. That constraint is why the map comes first: you cannot later “alias” your way out of a name you already used.

FAQ

Does ArawaMail support email aliases or plus-addressing today?
Not in the documented product surface. Create a real mailbox for each local-part you need to receive and send.

Is hello@ an alias of the founder mailbox?
No. Make it its own mailbox so the public address survives staffing changes.

Is plus-addressing a private or disposable identity?
No. It is a visible tag on the base address. Many forms also reject +.

Can three people share support@ by sharing the password?
Do not. Keep one mailbox, name an owner, and feed a helpdesk with outgoing webhooks.

Is catch-all a substitute for naming billing@?
No. Create billing@. Catch-all is a residual for unknown local-parts, not a role map.

What happens if we disable a role mailbox?
Mailbox, SMTP, mobile, and connected AI access stop. The address cannot send or serve as catch-all. Inbound goes to domain catch-all if configured; otherwise it is discarded.