Choose one custom-domain pattern and keep it: firstname.lastname@ for people, and a short list of role addresses such as hello@ and billing@ as their own mailboxes. On Arawa Mail a role address is a real account, or a verified forward from one, not an alias of the founder. Consistency beats a clever local-part.
The problem: proposals still leave from free webmail
A founder sending contracts from a personal Gmail or Outlook.com address looks early-stage even when the product is not. Buyers cannot tell who owns billing, and the second hire inherits a pile of mail sent as jane@ that was really the company. The fix is a naming convention before the first mailbox is created, not a later rename.
Why a custom domain is worth it, compared with free webmail, is covered in custom-domain email vs Gmail. This article owns the local-part: people versus functions.
Use one pattern that still works at ten people
For a two-person studio, prefer jane.doe@yourdomain over jane@. The shorter form collides when a second Jane joins, and it mixes a person with the company identity. Dots are allowed. They are part of the address, not a display trick.
Recommended day-one set:
firstname.lastname@for each person who sends as themselves.hello@for inbound enquiries that should not depend on one person being online. This is its own mailbox.billing@for invoices and payment questions. This is its own mailbox.
Skip info@, mail@, and firstname123. They are hard to say on a call and they do not tell the recipient who should answer. Skip noreply@ for product mail. People reply to receipts. See stop sending from noreply.
| Need | Address shape | On Arawa Mail |
|---|---|---|
| A person | jane.doe@ | Mailbox. Display name can be Jane Doe and is separate from the address. |
| A function | billing@ | Its own mailbox, not an alias of Jane. |
| A copy to a founder | Forward from that mailbox | Only after the destination confirms the link, within 24 hours. |
| Unknown local-parts | Catch-all | A separate decision. Do not turn it on to avoid naming addresses. See catch-all inboxes. |
Role addresses are mailboxes, not aliases
Arawa Mail account docs do not document aliases, plus-address routing, or send-as. sales@ cannot be an alias of the founder. Creating jane+billing@ is not a documented way to route billing mail. The boundary is explained in aliases and shared inboxes.
A second function needs its own mailbox. If a copy must also reach a person, an administrator can add forwarding on that mailbox. Forwarding starts only after the destination opens the verification email and approves the link within 24 hours. Destination caps, checked on the email accounts page on 3 October 2026, are 1 on Free, 5 on Pro, and 10 on Business. Forwarding is not a substitute for creating hello@. Workspace team-member counts on the pricing page are seats in the company workspace, not extra addresses on one mailbox.
Shared-inbox operations, including how a team answers one address without sharing a password, are a different design. This guide stops at the name.
Characters the local-part may use
When an administrator creates an account, the address is username@domain. The username may contain letters, numbers, dots, underscores, and hyphens. Duplicate addresses in the company database are rejected. The password is at least 12 characters. Display name can be changed later without rotating that password. Leave the password field blank when you only update the name.
Practical rules:
- Prefer dots between name parts:
amina.owuor@. - Use a hyphen only when a name already uses one.
- Do not encode a department in a personal address (
amina.sales@). The person will change roles. The role address will not. - Keep role addresses short and speakable.
How we checked this
On 3 October 2026 we re-read Arawa Mail email-account and mailbox docs. Receiving must be active before Add account is available. Local-part rules, duplicate rejection, the 12-character password, display-name updates, verified forwarding, and forwarding caps match that page. Alias, plus-address, and send-as behaviour is absent from those docs, which is why this article does not recommend them. We did not invent a mailbox-count plan limit.
Create the accounts only after receiving is active
A mailbox can exist before outbound sending is switched on for the domain. Receiving has to be active first, or Add account stays disabled. Connecting the Cloudflare domain, reviewing MX, and creating the first account is the job of set up a custom-domain email address. Product context for team inboxes lives on business email.
Write the pattern down before that setup call: people as firstname.lastname@, functions as their own mailboxes, no catch-all as a naming shortcut, no plus-addressing.
FAQ
Should we use jane@ or jane.doe@?
Use jane.doe@ unless the company is one person and you accept a rename later. The longer form survives a second hire with the same first name.
Which role addresses should exist on day one?
hello@ and billing@ cover most small teams. Add sales@ or support@ only when someone is actually responsible for that queue.
Can sales@ be an alias of the founder?
Not on Arawa Mail as documented. Create sales@ as a mailbox, or forward from that mailbox after the destination confirms.
What characters are allowed?
Letters, numbers, dots, underscores, and hyphens in the local-part. Plus-addressing is not a documented routing feature.
How do we avoid a rename when the second person joins?
Do not give the company identity to one first name. Keep people on firstname.lastname@ and functions on role mailboxes from the first day.