One inbox per agent
An address is identity. The moment an agent has one, the conversation it holds becomes something you can read, audit and hand to a colleague, instead of a log line that says a message went out.
Why not just use a mailbox you already have
Because a human mailbox is a shared surface with no boundaries: the agent sees mail it has no business reading, and anything it sends is indistinguishable from what the person sent. When something goes wrong, and eventually it does, there is no way to answer the only question that matters, which is who wrote this.
A dedicated inbox draws the boundary in the one place that survives: the address on the envelope. Allow and block rules, folders and metrics all hang off it.
Two places an address can live
# shared domain: nothing to configure
create_inbox { name: "support" }
→ [email protected]
# your own verified domain, with receiving enabled
create_inbox { name: "support", domainKind: "tenant", domainName: "acme.dev" }
→ [email protected]The shared domain is the fast path: no DNS, no verification, a working address in one call. Its reputation is shared with other workspaces, which is fine for internal agents and for anything a human is expecting anyway.
Your own domain is the right home for anything a customer sees. It needs the domain verified for sending and receiving switched on, which publishes an MX for the whole domain. Do that on a subdomain you control, not on the one your company already receives mail on, unless you mean to move all of it.
How many you actually need
One per job, not one per user. A support agent, a billing agent and a recruiting agent have different senders, different allow lists and different volumes: splitting them costs nothing and makes every later question answerable. Splitting per end customer does not: that is what threads are for.
The free plan carries 3 inboxes and 3,000 messages a month, which is enough to run two or three agents in production before anyone has to think about it.
Questions
Can several agents share one inbox?
They can, and it is usually a mistake. Two agents reading the same threads will answer the same message twice, and neither of them can tell which reply came from the other. One inbox per agent keeps the conversation attributable, and the folders stay meaningful.
Shared domain or my own?
Start on agents.sending.dev: nothing to configure, and the address works in a minute. Move to your own domain when the recipient should see your brand, or when you want the reputation of that traffic to be yours. Both can coexist: the inbox carries its own address.
What does enabling receiving on my domain change?
It publishes an MX for the whole domain, which means all inbound mail for it goes through us. That is why it is a separate toggle from verifying the domain for sending: one is additive, the other takes over a channel you may already be using.
Keep reading
One inbox per agent
Why an agent needs an address of its own, where it should live, and what a shared domain costs you in practice.
Threading that survives the reply
How a reply stays in the same conversation on the recipient's side, and why folders are views rather than labels to maintain.
Inbound webhooks, signed
Being told a mail arrived instead of polling for it, and verifying the signature before you trust the payload.
Allow and block rules
Deciding who may write to an agent, and what happens to mail that fails SPF, DKIM or DMARC.
