# Mailboxes > Create company addresses and choose who can read, send, and manage each one. ## Create a mailbox A mailbox needs a verified domain. In **Settings → Inboxes**, choose **Add inbox**, then provide: - **Address** — the local part before `@`, such as `hello` or `founder`. - **Display name** — the human-readable sender name recipients see. - **Visibility** — shared or private. The local part can contain letters, numbers, dots, dashes, and underscores. It must be unique on the selected domain. ## Shared mailboxes Every workspace member can read a shared mailbox. People who can use it may reply and compose from its address. Shared mailboxes work well for `hello@`, `support@`, or another address handled by the team. ## Private mailboxes A private mailbox belongs to an owner. Its messages and attachments are visible only to that owner and people granted explicit access. A grant can include read-only or read-and-send permission. > **Roles do not leak content** > > A workspace admin can manage routing and billing without automatically gaining access to a private > mailbox’s messages. ## Mailbox access in developer tools API keys and MCP connections see only mailboxes available to the identity behind the key. Scope still applies: `mailboxes:read` lists mailbox metadata, `mail:read` exposes threads, and `mail:send` permits sending from a mailbox where the identity can send. ## Address lifecycle Mailbox addresses are durable identities. Treat renaming or moving an address as a migration: tell correspondents, update automated integrations, and test replies. Startup Mail does not provide catch-all routing.