← All posts

Introducing Robotomail: Email Infrastructure Built for AI Agents

The missing primitive

I've been thinking a lot about what AI agents are still missing. Not intelligence. Not model quality. Not frameworks. Those are moving fast. What's still missing is infrastructure that makes agents feel like real participants in software systems. Email is one of those missing primitives. (I wrote more about this on my personal blog.)

If you want an agent to actually do useful work in the real world, eventually it needs an inbox. It needs to send reminders, receive replies, react to incoming messages, and operate with a real identity instead of faking everything through a human's Gmail account. I hit this while building OpenClaw agents — OAuth setup, JSON credentials files, creating separate Google accounts to avoid suspicion. It worked, barely, until I realized Google's ToS explicitly prohibits automated bot usage.

Transactional services like SendGrid and Mailgun solve a different problem. They're built for one-way notifications — password resets, receipts, marketing blasts. They're not designed for two-way conversations. Inbound parsing is bolted on, threading is an afterthought, and you can't give each agent its own real mailbox. Your agent doesn't need to send a million marketing emails. It needs to have a conversation.

The last option is running your own mail server. Postfix, Dovecot, DNS records, TLS certs, IP reputation, spam filtering, deliverability monitoring. If you've done it, you know: it's a full-time job. If you haven't, trust the people who have — don't. You're building an AI product, not becoming a mail server admin.

What Robotomail is

Robotomail is email infrastructure purpose-built for AI agents. One API call to sign up. One API call to send an email. Every agent gets a real mailbox with a real email address — not a forwarding alias, not a shared inbox, not a webhook-only endpoint. A proper [email protected] address that can send and receive like any other mailbox on the internet.

Under the hood, we run production-grade mail servers with SMTP, IMAP, and JMAP. We handle DNS configuration automatically — MX records, SPF, DKIM signing, DMARC policies. When your agent sends an email, it lands in the recipient's inbox, not their spam folder. When someone replies, the message hits your webhook endpoint in real time. No polling. No cron jobs. No stale data.

I built Robotomail because I needed it. While building OpenClaw agents that had to communicate with people over email, every existing option was either against ToS, missing half the features, or required becoming a mail server operator. The moment I watched Hal receive an email via SSE, process it, and fire back a reply — all without a human in the loop — I knew this needed to be its own product.

How it works

Robotomail is a REST API. Four steps to go from nothing to a working email agent.

Step 1: Sign up. Create an account and get your API key in a single request. Your agent can do this itself — no human in the loop required.

curl
curl -X POST https://api.robotomail.com/v1/signup \
  -H "Content-Type: application/json" \
  -d '{
    "email": "[email protected]",
    "password": "a-strong-password",
    "slug": "myagent"
  }'

You get back your API key, a ready-to-use mailbox at [email protected], and your send limits. The slug becomes both your account identifier and your default email address prefix.

Step 2: Send an email. Use the mailbox ID from your signup response to send a message. Plain text, HTML, or both.

curl
curl -X POST https://api.robotomail.com/v1/mailboxes/{mailbox_id}/messages \
  -H "Authorization: Bearer rm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "to": ["[email protected]"],
    "subject": "Hello from my AI agent",
    "bodyText": "This email was sent by an autonomous agent via Robotomail."
  }'

That's it. The email goes out over SMTP with proper DKIM signatures. Threading is handled automatically — if you include an inReplyTo header, Robotomail threads the conversation for you. If you don't, we fall back to subject-line matching.

Step 3: Register a webhook. Tell Robotomail where to send inbound messages. You can scope webhooks to a specific mailbox or receive events for all of them.

curl
curl -X POST https://api.robotomail.com/v1/webhooks \
  -H "Authorization: Bearer rm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-app.com/webhooks/email",
    "events": ["message.received"],
    "mailboxId": "{mailbox_id}"
  }'

Every webhook delivery is signed with HMAC-SHA256 via the X-Robotomail-Signature header, so you can verify the payload came from us. The webhook secret is returned when you create the webhook — store it securely.

Step 4: Receive and respond. When someone replies to your agent's email, the message hits your webhook endpoint as a JSON payload with the full message body, headers, thread ID, and any attachments. Your agent parses the message, decides what to do, and responds with another API call. The conversation threads automatically.

If you prefer server-sent events over webhooks, Robotomail also supports SSE streaming at the /v1/events endpoint. Same data, different delivery mechanism. Use whichever fits your architecture.

What makes it different

  • Agent self-onboarding. Your agent can sign up, provision a mailbox, and start sending without any human interaction. Hand it the quickstart docs and let it go.
  • Automatic threading. Replies are threaded by In-Reply-To and References headers first, then by normalized subject matching. Your agent always knows what conversation a message belongs to.
  • Per-mailbox rate limits. Each mailbox has its own daily and monthly send limits. No single runaway agent can burn through your entire account's quota.
  • Custom domains. Bring your own domain for branded email. Robotomail generates the DNS records (MX, SPF, DKIM, DMARC) — you add them to your DNS provider, and we verify automatically.
  • No OAuth dance. Authentication is a single API key in the Authorization header. No refresh tokens, no consent screens, no token expiration headaches.
  • CLI tool. The @robotomail/cli npm package gives you a command-line interface that wraps the full API. Useful for debugging, scripting, and giving agents a tool-use interface.
  • Scoped API keys. Create API keys that are restricted to specific mailboxes. Give each agent only the access it needs — least privilege out of the box.

Who it's for

The number one use case right now is OpenClaw agents — autonomous agents that need to reach out to people, respond to inquiries, and manage ongoing email conversations. But Robotomail works with any agent framework: LangChain, CrewAI, AutoGen, Claude, Codex. If your agent needs to communicate over email, this is the infrastructure layer you've been missing.

It's also for teams that need to give multiple agents their own email identities without managing mail server infrastructure. Spin up a mailbox per agent, per workflow, or per customer. Tear them down when you're done. It's infrastructure, not a commitment.

What's next

We're just getting started. Custom domains, attachments, and automatic threading are already live. Coming soon: webhook event filtering so you only receive the events you care about, and more agent-native features like conversation summarization and intent detection on inbound messages. The roadmap is driven by what builders actually need — if you have a use case that isn't covered, I want to hear about it.

Get started

The free tier includes a platform mailbox, 50 sends per day, and webhook delivery — no credit card required. Sign up in one API call or through the docs. Read the quickstart guide to have your agent sending email in under five minutes. Or check out the messages API reference if you want to dive straight into the details.