Email inboxes for AI agents
An agent that can only send is half deaf. Agent Email gives it an address that receives: real inbound mail on Amazon SES, threaded conversations, replies that stay in the thread, and a signed webhook when something lands.
Free for 3 inboxes and 3,000 messages a month · no DNS work to start · MCP and REST
Sending is the easy half
Any API can push a message out. The hard part is what comes back: the customer who replies, the service that confirms, the human who asks one more question. Handling that usually means running an IMAP loop, or parsing MIME by hand, or accepting a webhook that hands you a blob and leaves the conversation for you to rebuild.
An inbox is what turns those messages into something an agent can act on: a thread it can read, a reply it can send, and an event it can react to. That is the whole product.
What happens when mail arrives
SES receives on the MX of the inbox domain and writes the raw message to S3. A notification reaches our endpoint, we fetch the object, parse the MIME, store the attachments, and attach the message to the right conversation. Only then does email.received go out to your webhooks.
Nothing in that path polls, and no third-party mailbox provider sits in the middle. The same infrastructure carries your transactional email, which is the part that matters later: suppression, quota and tracking are one set of rules, not two systems to reconcile.
From an agent, in three calls
create_inbox { name: "support" }
→ { id, address: "[email protected]" }
list_threads { inboxId }
get_thread { threadId }
reply_thread { threadId, html: "<p>On it.</p>" }curl -X POST "https://sending.dev/api/v1/inboxes" \
-H "Authorization: Bearer $SENDING_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "localPart": "support", "displayName": "Acme Support" }'
# then, when something arrives
curl "https://sending.dev/api/v1/inboxes/$INBOX_ID/threads" \
-H "Authorization: Bearer $SENDING_API_KEY"The four parts worth understanding
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.
What an inbox inherits from the rest of the account
A message sent from an inbox is a message: it is checked against the suppression list, it needs a verified domain if it leaves one of yours, it consumes the same monthly quota and it lands in the same delivery log. That is deliberate. The alternative, an inbox product bolted on the side, is how an agent ends up writing to an address that bounced three times last week.
The one thing kept separate is the meter: inbox traffic is counted against the Agent Email plan, not against your transactional volume, so a busy support agent does not eat the quota your product emails need.
Where to go next
Questions
What is an email inbox for an AI agent?
A real mailbox the agent owns: it has an address, it receives mail, and it can reply in the same conversation. It is not a webhook that hands you a raw MIME blob. The agent calls a tool to list threads, another to read one, another to reply, and the thread stays a thread for whoever is on the other side.
Do I need my own domain?
No. An inbox can live on the shared domain agents.sending.dev with no DNS work at all, which is how you try this in a minute. When you want the agent to write from your own brand, verify a domain and switch receiving on for it: that is a separate toggle from sending, because it takes over the inbound mail of the whole domain.
How does mail actually get in?
Amazon SES receives it on the MX of the inbox domain, drops the raw message in S3, and notifies our webhook. We fetch it, parse the MIME, store attachments, thread it against what is already there, and fire email.received on your webhooks. There is no polling in the path, and no third-party inbox provider in the middle.
Can the agent send too, or only reply?
Both. Sends from an inbox go through the same pipeline as every other email we send, so they inherit tracking, the suppression list, idempotency and the plan quota. An agent cannot use an inbox as a side door around the guardrails that apply to the rest of the account.
What does it cost to start?
Nothing: the free plan carries 3 inboxes and 3,000 emails a month, received and sent, with no card. The next step up is Developer at 20 euro a month for 10 inboxes.
Is there a per-inbox flood limit?
Yes, and it stays finite on every plan, Enterprise included: 60 messages an hour per inbox on Free, more further up. It is a backstop against a mail bomb aimed at one address, not a commercial lever.
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.
