Mailboxes & aliases

An address in Knobs is a local part — the bit before the @ — and it exists at every domain your workspace has verified. Claim jd and both jd@your-team.knobs.io and jd@yourcompany.com deliver to the same inbox. Domains and addresses are separate concerns: Settings → Domains is where domains are added and verified, Settings → Aliases is the admin console for every address in the workspace (each member manages their own under Settings → Profile → Your addresses).

This means the address list is workspace-wide. A local part belongs to exactly one member (or one group) across all your domains — you can’t point hello@brand-a.com at one person and hello@brand-b.com at another.

Member addresses

Every member gets an address when they join, at every verified domain.
When a new domain verifies, every existing address — members’, aliases, and group addresses — starts working there automatically. A newly verified domain is never empty.
A member’s primary address is their original one — it’s their login identifier and can’t be removed.

Address format

By default, new members pick their own address, availability-checked as they type. An admin can instead set a workspace address format — first.last, f.last, or first.l — in workspace settings, so every invitee’s address is derived from their name automatically and the roster stays consistent.

Personal aliases

Members can claim extra addresses for themselves — jesse@ alongside jesse.lovelace@ — under Settings → Profile → Your addresses. Type the address; availability is checked live, workspace-wide. There is no domain to pick: the alias works at all of them.

Aliases deliver to the member’s own inbox, and can be selected as the From address when composing. Members can remove their own aliases (except the primary); removing one releases it at every domain.

Notes for admins:

Role-style local parts — admin, support, billing, sales, hello, info, team, and similar — are reserved: members can’t self-claim them. They’re meant for group addresses (below).
The Email aliases toggle (also in Settings → Aliases) disables new alias claims. Existing aliases keep delivering; the toggle only stops new ones.
An address an admin disabled can’t be re-claimed by its former owner.

All workspace addresses

Settings → Aliases → All workspace addresses lists every address in the workspace with its owner (a member, or a group) and how many of your domains it covers. From here you can add an address for a member — supply their uid, or leave it blank to claim it for yourself — or disable one. Both apply at every verified domain.

Repair addresses re-runs the rule that every address exists at every verified domain, and reports how many rows it had to create. It’s idempotent and safe to run any time; you shouldn’t normally need it.

Group addresses

A group can claim an address — team@ — that fans mail out to every group member’s inbox. Like every address, it works at every verified domain; the group’s listed address is the one on your default domain. Delivered messages show a “via group” chip so recipients know how it reached them.

Internal groups accept mail from your own domains only, and members can send as the group address. Reserved local parts like support@ are claimable here — that’s what they’re reserved for.
External groups accept mail from anyone (spam-filtered) and can include outside email addresses as members, who receive copies with working reply and unsubscribe behavior.

Groups are managed by admins (and per-group managers) in Settings.

Undelivered mail

Mail sent to a non-existent address on your domain isn’t bounced into the void — it’s held in the admin-only Undelivered view (in Settings → Domains) for 30 days. For each held message you can:

Create the address it was sent to — which claims it at every verified domain — then deliver it, or
Deliver anyway to an existing mailbox.

This makes a typo’d address or a not-yet-invited teammate a recoverable event instead of lost mail.

Held messages are listed newest first, a page at a time — Load more brings in older ones, so a busy domain’s backlog is all reachable. Delivering or dismissing a message leaves it in the list with its status updated, rather than making it disappear.