Unlimited agent mailboxes on your own domain.
openagent.email is a self-hosted mail server that gives AI agents unlimited real mailboxes on a domain you own. The stack is two containers: a catch-all Postfix/Dovecot mailbox (docker-mailserver) and a Node/Hono API that matches incoming mail to identities by the To and Delivered-To headers, with an MCP server on top. It idles at about 190 MB of RAM. Why it exists: agents keep needing to read signup codes and verification links. Hosted agent-mail APIs work, but in a signup flow those emails are the account credentials, and every one of them passes through someone else's servers. Apache-2.0, 268 automated tests, four commands to install.
Unlimited anything@yourdomain addresses Scoped per-identity tokens One-time code and verification link extraction Long-poll wait call built for automated signups Send rate limits and automatic retention Web dashboard for the human MCP server: npx -y @openagentemail/mcp
Agent sign-up flows that need email verification (OTP codes, confirmation links) End-to-end testing of email features Giving coding agents a real inbox to receive and reply to mail Multi-agent setups where each agent gets its own address
Maker of openagent.email - self-hosted email for AI agents. Apache-2.0.
AI video with native sound, paid per clip. Nothing stored.
A calmer Mac menu bar, one click away.
Enterprise Software. Intelligent Automation. Global Impact.
Comments
15Maker of openagent.email - self-hosted email for AI agents. Apache-2.0.
Hi folks! I built openagent.email because my AI agents kept needing to read signup codes and verification links - and in a signup flow those emails ARE the account credentials. I didn't want them passing through a third party, so this is a self-hosted mail server where every agent gets its own mailbox on your own domain. Two containers, ~190 MB RAM, Apache-2.0. Happy to answer anything about the catch-all setup or the MCP server on top.
Self-hosting makes sense when verification mail is effectively a credential. How do you prevent cross-identity leakage with catch-all delivery—for example when To differs from the envelope recipient—and are scoped tokens unable to enumerate mailboxes outside their identity?
Maker of openagent.email - self-hosted email for AI agents. Apache-2.0.
Thanks for asking this the right way — these are the two boundaries that matter on a catch-all. **1. To ≠ envelope / cross-identity reads.** Every identity shares one catch-all mailbox. The API only hands a message to identity A if To, Cc, Bcc, or Delivered-To contains **A’s full address as an exact match** (lowercased — no substring, no prefix). So `k7d2@` cannot read mail for `fox-k7d2@`, and a prefix like `ent@` cannot dump the box. If B’s message never names A, A cannot see it. That’s a **read-time header match**, not encryption between identities. The files still live in one mailbox; the trust anchor is exact matching plus token scope. That’s exactly why self-hosting is first-class here: your VPS, your mailbox files, isolation you can take to disk. One honest caveat, the other direction: a Bcc-only delivery can be **missed** (Bcc is stripped; Delivered-To may be the catch-all address). That’s under-delivery, not a leak. **2. Can a scoped token list other mailboxes?** No. An identity token can only read and send as itself. With that token, the identity list returns only that identity. Full listing, audit, and notification admin need the admin key — keep it offline. Tokens are stored as SHA-256 hashes; the plaintext is shown once at create/rotate. Inbound bodies are treated as data, not instructions (hygiene fence, not a magic guarantee): https://openagent.email/docs/guides/security/#7-reading-untrusted-mail Catch-all + scoped tokens: https://openagent.email/docs/ Credential split: https://openagent.email/docs/guides/security/ Happy to go deeper on any of the matching cases.
AI podcast growth audit for US creators, startup shows, and business podcasts.
The owned-domain approach is compelling for teams that want agents to have separate identities without vendor lock-in. A simple onboarding diagram for DNS setup and routing rules would reduce perceived setup risk.
Maker of openagent.email - self-hosted email for AI agents. Apache-2.0.
Agreed — most of the perceived setup risk is DNS, not the two containers. The wizard prints the exact MX / SPF / DKIM / DMARC / PTR records, and doctor.sh checks them before agents depend on the box: https://openagent.email/docs/quickstart/#4-point-dns-at-it and https://openagent.email/docs/guides/dns-setup/ . That's the onboarding path we point people to today.
An indie maker building LogoWren (logowren.com) — an AI logo generator with simple one-time pricing for small businesses.
Love it, they have such a wide range to choose from
I build & lead the engineering behind AI agents · Co-Founder & VP R&D @ Dial
The distribution problem for autonomous agents is real - you can build something powerful but if it lives in a single app window, adoption stays low. OpenAgentEmail inverts this by letting agents communicate through email, which is infrastructure every organization already has. The ability to spin up unlimited agent mailboxes on your own domain means you're not locked into a platform's namespace - you own the communication channel. For teams building multi-agent systems or handling high-volume automated workflows, having email as the native interface instead of an afterthought is actually transformative.
Maker of openagent.email - self-hosted email for AI agents. Apache-2.0.
Thanks for putting the distribution point this clearly. Email is infrastructure every org already has — that's why the mailbox lives on a domain you own, not a vendor namespace. Quickstart if you want to try it: https://openagent.email/docs/quickstart/
Data science
openagentemail has great potential! A few improvements could make it even better. I'd love to share my feedback and suggestions. Email: [email protected]
Maker of openagent.email - self-hosted email for AI agents. Apache-2.0.
Thanks. If you have concrete suggestions, please post them on this thread so others can see them too — that's the best place for product feedback.
I build & lead the engineering behind AI agents · Co-Founder & VP R&D @ Dial
The distribution problem for autonomous agents is real - you can build something incredibly powerful but if it only lives in a single app window, adoption stays low. OpenAgentEmail inverts this by letting agents communicate through email, which is infrastructure every organization already has. The ability to spin up unlimited agent mailboxes on your own domain means you're not locked into a platform's namespace. For teams building multi-agent systems, having email as the native interface is genuinely transformative.
Builder. Currently working on Audeep, a QA auditor for websites.
The credential-routing concern is understated by most people building agent flows. When agents sign up for services the verification email IS the account credential, and every hosted mail API in between is a potential MITM. Self-hosting flips the threat model: nothing leaves your own infra. The long-poll wait call is the right abstraction for agent signup flows specifically, no need to hand-roll a polling loop. 268 tests on the stack is also a level of rigor I don't see often at this stage.
Maker of openagent.email - self-hosted email for AI agents. Apache-2.0.
Thanks — you named the threat model exactly. In a signup flow the verification mail is the credential, so self-hosting keeps that hop on your box; wait_for is there so the agent does not have to roll its own poll loop. If useful: https://openagent.email/docs/guides/security/
IT Consultant
Looks super, is it safe?
Maker of openagent.email - self-hosted email for AI agents. Apache-2.0.
Thanks — that's the right first question. Short version: identities can't read each other's mail unless they're named on the message, and a scoped token can't list other mailboxes. Isolation is exact header match + token scope on one catch-all store — which is why running it on your own box is the first-class path. Details under Tristan's comment + https://openagent.email/docs/guides/security/