How to Give Your AI Agent an Email Address

The problem: AI agents can't do email

Modern AI agents can browse the web, write and run code, file pull requests, call APIs, and drive a terminal. But the moment the agent needs to sign up for something, confirm a verification code, reply to a vendor, or triage an inbox on its own — the wheels come off. The existing options are all designed for humans or for machines impersonating humans:

• Gmail API
  requires OAuth against a human Google account, tokens rot, and Google actively detects and blocks automated sign-in. Agents break within days.
• Self-hosted Postfix or Stalwart
  full send/receive, but you're on the hook for DKIM, DMARC, reverse DNS, IP warming, blocklists, disk quotas, and staying off spam lists. Weeks of plumbing before the first email goes out.
• Transactional providers (SendGrid, Mailgun, Resend)
  great at outbound blasts, not designed for per-agent mailboxes, inbound threading, or the guardrails an autonomous loop needs.
• Scraping IMAP
  brittle, slow, and violates the terms of every major provider.

None of them give you what you actually want: a real mailbox that an agent owns, with full SMTP send and receive, webhooks for inbound, and a way to programmatically provision new ones.

Meet Robotomail

Robotomail is managed email infrastructure for AI agents. API and CLI only — no web UI for email operations, because agents don't click through web UIs. Real send and receive over real SMTP, with proper authentication (SPF, DKIM, DMARC), thread-aware replies, webhooks for inbound mail, attachment handling, and built-in rate-limit guardrails.

Live demo: provision a mailbox in one command

One CLI call and the agent has a mailbox. No DNS, no OAuth, no waiting. The mailbox address goes live on the shared platform domain — yourname@robotomail.co — and you can immediately send and receive from it.

npx @robotomail/cli mailbox create shopping-agent

Or use the API directly:

curl -X POST https://api.robotomail.com/v1/mailboxes \
  -H "Authorization: Bearer rbt_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "shopping-agent",
    "domainId": "dom_platform"
  }'

With the mailbox created, send the first email:

curl -X POST https://api.robotomail.com/v1/mailboxes/mbx_shopping/messages \
  -H "Authorization: Bearer rbt_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "to": ["vendor@example.com"],
    "subject": "Order #A-4521 — delivery update?",
    "bodyText": "Hi, checking on the status of order A-4521. Expected delivery is Thursday. Please confirm or advise."
  }'

And when the reply arrives, Robotomail delivers it to your webhook within a few seconds. The payload is a clean, structured JSON envelope — no MIME parsing on your end.

{
  "event": "message.received",
  "mailbox": "shopping-agent@robotomail.co",
  "message": {
    "id": "msg_01HX...",
    "from": "vendor@example.com",
    "subject": "Re: Order #A-4521 — delivery update?",
    "text": "Delivery confirmed for Thursday 2pm.",
    "threadId": "thr_01HX...",
    "receivedAt": "2026-04-17T10:00:00Z"
  }
}

Inside the agent loop

From the agent's perspective there are four tools: send, list, read, and reply. That's the whole surface area. Replies automatically carry the correct In-Reply-To and Referencesheaders so threads stay intact on the recipient's side — your agent doesn't have to think about any of it.

The daily send cap is the critical guardrail. A runaway loop or a prompt-injection escalation would, in a world without caps, cheerfully email a million people. Robotomail enforces the cap at the API layer — 100 sends per mailbox per day on the free tier, higher on paid plans — and returns a 429 the moment it's hit.

Custom domains: five DNS records

The platform domain is great for getting started. When you're ready to send as agent@yourcompany.com, add a custom domain. Robotomail generates exactly five DNS records — two MX for inbound routing and the send subdomain, one SPF TXT, one DKIM TXT, and one DMARC TXT. Paste them into your DNS provider and run verify.

MX    acme.com               mail.robotomail.com              (priority 10)
MX    send.acme.com          feedback-smtp.us-east-1.amazonses.com  (priority 10)
TXT   send.acme.com          v=spf1 include:amazonses.com ~all
TXT   resend._domainkey      p=MIGfMA0GCSq...
TXT   _dmarc                 v=DMARC1; p=quarantine; rua=mailto:dmarc@robotomail.com

$ npx @robotomail/cli domain verify acme.com
⏳ checking DNS...
✓ MX       propagated
✓ SPF      valid
✓ DKIM     aligned
✓ DMARC    policy ok
✓ acme.com is fully verified.

Gotchas worth knowing

• DKIM alignment is non-obvious
  DMARC requires that the DKIM signing domain aligns with the visible From domain. Robotomail signs with a selector on your domain so alignment is automatic — but if you roll your own, this is where most setups fail silently into the spam folder.
• Suppression lists matter
  Hard bounces and spam complaints land the address on a suppression list — every subsequent send to that address is blocked at the API layer. This protects your sender reputation, which is the single most important input to deliverability.
• Rate limits are your friend
  Per-mailbox daily caps catch the bugs you didn't know you had. Treat the 429 as a signal, not a blocker.

What to build

• Shopping agents
  Place orders, confirm deliveries, and handle returns — see the e-commerce orders pattern.
• Recruiting bots
  Run first-touch outreach and schedule interviews — see the recruiting pattern.
• Support triage
  Read incoming tickets, propose responses, and escalate to humans — see the customer support pattern.
• Newsletter digesters
  Consolidate a week of subscriptions into a single summary — see the newsletter agent pattern.
• Multi-agent workflows
  Agents email each other across organizations — see the multi-agent pattern.

Frequently asked questions