Build an AI Email Agent With Its Own Inbox in 30 Seconds (No Gmail, No OAuth, No Domain)

Your agent just placed an order, filed a ticket, or kicked off a workflow that ends with a human emailing back. Now it needs to read that reply — the confirmation number, the "please verify," the question someone asked. And it has no address to receive it at.

The AI email agent is the fix, and the inbox is the part that takes about thirty seconds. The full build below is six short steps — but you'll have a working, addressable inbox before you finish this intro. That's agentic email done right: the agent gets its own mailbox, separate from any human account, with no signup, no domain, no OAuth, and no payment. Every command here runs today.

First, why the two usual shortcuts are both wrong.

Hand the agent your Gmail — an app password or a mail-scoped OAuth token — and an autonomous process can now read every message you have, including the six-digit codes that guard your bank. That isn't an integration; it's a 2FA bypass you built yourself. Stand up "real" infrastructure instead — buy a domain, configure SPF/DKIM/DMARC, host an inbound webhook, parse and store and re-thread — and that's a week of work before the agent sends a byte.

This guide takes a third path.

What is an AI email agent?

An AI email agent — an agent email identity of its own — isn't a chatbot that drafts mail for you to send. It's an autonomous process that owns an email identity and acts through it: it has an address, sends under that address, receives replies in a mailbox it can read, and answers in-thread — with no human in the loop per message.

That takes three things a send-only API doesn't give you:

• An identity — a stable address that belongs to the agent, not borrowed from a person.
• A mailbox — somewhere inbound mail is stored and threaded, that the agent can query.
• Autonomy at signup — the agent provisions this itself, so you can spin up one agent or fifty with no human clicking through account creation.

Atomic Mail Agentic is built around exactly this shape. It's the agent-facing product at atomicmail.ai — distinct from the human email app at atomicmail.io. What follows uses the agent product end to end.

Why not just give the agent your Gmail

Give an agent your personal mailbox and you give it everything that mailbox can see and do: password resets, one-time codes, private threads. And email is untrusted input — anyone on earth can message your agent, and that message can contain instructions. A model that acts on what it reads will, sooner or later, act on something a stranger wrote. If the inbox is yours, the blast radius is your whole digital life.

Give the agent its own inbox and the blast radius shrinks to that inbox. If it's compromised, an attacker gets an empty agent mailbox on a shared domain — not your accounts. Isolation is the security model, not a nice-to-have.

Step 1 — Register the agent's inbox

No account creation. The agent solves a small proof-of-work challenge — that's what keeps the free tier abuse-resistant without a domain or a card. One command:

npx --package=@atomicmail/agent-skill atomicmail register \
  --username "orders-bot" \
  --watch on-demand

--username becomes the permanent public address on every message this inbox sends — orders-bot@atomicmail.ai — and it can't be changed later, so pick it deliberately. --watch decides whether the inbox gets a recurring unattended read (on-demand for now — read only when asked; scheduled in Step 5).

Proof-of-work takes a few seconds to a couple of minutes depending on the host. On success your credentials land in ~/.atomicmail/:

~/.atomicmail/
  credentials.json    # long-lived identity
  session.jwt         # short-lived session (≈1 hour)
  capability.jwt      # short-lived capability token (≈minutes)

That directory is the agent's identity — back it up, keep it out of version control. Running several agents? Point each at its own directory with ATOMIC_MAIL_CREDENTIALS_DIR. No shared login, no OAuth consent screen, no human.

Step 2 — Send the first message

Atomic Mail speaks JMAP (IETF RFC 8620 / 8621), the modern open standard for mail. Unlike a proprietary, send-only email API for AI agents, you send standard JMAP method calls — so any language that can make an HTTP request can drive this inbox.

Put a standard JMAP batch in send_mail.json. The $ACCOUNT_ID, $INBOX, and $INBOX_MAILBOX_ID tokens fill in from your session:

{
  "using": [
    "urn:ietf:params:jmap:core",
    "urn:ietf:params:jmap:mail",
    "urn:ietf:params:jmap:submission"
  ],
  "methodCalls": [
    ["Email/set", {
      "accountId": "$ACCOUNT_ID",
      "create": {
        "msg": {
          "mailboxIds": { "$INBOX_MAILBOX_ID": true },
          "from": [{ "email": "$INBOX" }],
          "to":   [{ "email": "founder@example.com" }],
          "subject": "Order #4127 confirmed",
          "bodyValues": { "b": { "value": "Confirmed. Ships tomorrow.\n\n— orders-bot" } },
          "textBody": [{ "partId": "b", "type": "text/plain" }]
        }
      }
    }, "c0"],
    ["EmailSubmission/set", {
      "accountId": "$ACCOUNT_ID",
      "create": {
        "s": {
          "emailId": "#msg",
          "envelope": {
            "mailFrom": { "email": "$INBOX" },
            "rcptTo":   [{ "email": "founder@example.com" }]
          }
        }
      }
    }, "c1"]
  ]
}

Send it:

npx --package=@atomicmail/agent-skill atomicmail jmap_request \
  --ops-file send_mail.json

That's Email/set (compose) and EmailSubmission/set (send) in one round trip. The message goes out from orders-bot@atomicmail.ai.

Two honesty notes. First, Atomic Mail files the agent's own copy of outbound mail in its Inbox — the one mailbox ID your session hands you — rather than a separate Sent folder. (The account has sent, drafts, junk, and trash roles too; look them up with Mailbox/get if you'd rather file mail yourself.) Second, outbound goes through a shared platform domain, protected by proof-of-work, reputation, and rate limits instead of making you own a domain. That's the right trade for an agent sending a handful of real, transactional messages under its own identity — not for bulk marketing. For high-volume blasts you want a dedicated-domain sender; we cover where each fits in Best Email APIs for Developers in 2026.

Step 3 — Receive and read

This is the half send-only APIs skip. Reading is two JMAP calls — find the newest messages, then fetch the fields you want. Note messageId in the properties: you'll need it to reply in Step 4.

{
  "using": ["urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail"],
  "methodCalls": [
    ["Email/query", {
      "accountId": "$ACCOUNT_ID",
      "filter": { "inMailbox": "$INBOX_MAILBOX_ID" },
      "sort":   [{ "property": "receivedAt", "isAscending": false }],
      "limit":  10
    }, "q0"],
    ["Email/get", {
      "accountId": "$ACCOUNT_ID",
      "#ids": { "resultOf": "q0", "name": "Email/query", "path": "/ids" },
      "properties": ["from", "subject", "receivedAt", "preview", "threadId", "messageId"]
    }, "g0"]
  ]
}

npx --package=@atomicmail/agent-skill atomicmail jmap_request \
  --ops-file read_inbox.json

You get back structured JSON — senders, subjects, previews, thread IDs, and Message-IDs — that you hand straight to your model. No inbound webhook to host, no MIME parsing, no storage layer, no thread reconstruction. The mailbox already did it. (You learn about new mail by reading it — polling or a scheduled read, not push; see Step 5 and Honest limits.)

Step 4 — Reply in-thread

Replying is the send from Step 2 with one addition: set inReplyTo and references to the Message-ID of the mail you're answering — the messageId you fetched in Step 3 — so the recipient's client keeps the conversation stitched together. You never set threadId yourself: it's assigned by the server from those headers.

["Email/set", {
  "accountId": "$ACCOUNT_ID",
  "create": {
    "reply": {
      "mailboxIds": { "$INBOX_MAILBOX_ID": true },
      "from": [{ "email": "$INBOX" }],
      "to":   [{ "email": "founder@example.com" }],
      "subject": "Re: Order #4127 confirmed",
      "inReplyTo":  ["$INCOMING_MESSAGE_ID"],
      "references": ["$INCOMING_MESSAGE_ID"],
      "bodyValues": { "b": { "value": "Tracking: 1Z… — orders-bot" } },
      "textBody": [{ "partId": "b", "type": "text/plain" }]
    }
  }
}, "c0"]

$INCOMING_MESSAGE_ID is the messageId value from the message you're answering. Now the agent holds up its end of a real conversation — received, understood, answered, in-thread, under its own name.

Step 5 — Let the agent check its own mail on a schedule

An agent that only reads when you invoke it isn't autonomous. Two ways to close the loop:

• Poll from your own loop. If your agent already runs on a cadence, run the Step 3 read at the top of each cycle and act on anything newer than the last receivedAt you saw.
• Register with --watch scheduled. Ask the inbox for a recurring unattended read at registration:

npx --package=@atomicmail/agent-skill atomicmail register \
  --username "orders-bot" \
  --watch scheduled

Registration then returns the exact setup step for your runtime — and you schedule it on your host's own scheduler (cron, your runner's job system), never at the OS level of some shared box. The inbox tells you what to run; where it runs is yours.

Step 6 — Wire it into your framework

Everything above uses the agent-skill CLI, which works from any language or shell. If your agent runs through MCP, add the server to your MCP client (Claude Desktop, Cursor, anything that speaks MCP):

{
  "mcpServers": {
    "atomicmail": {
      "command": "npx",
      "args": ["-y", "@atomicmail/mcp"]
    }
  }
}

Honest scope of the MCP server today: it exposes register, jmap_request (raw JMAP — exactly the batches above), and help. Higher-level send/receive convenience tools are on the roadmap, not shipped — so through MCP you send and read by handing those same batches to jmap_request. Call help early; it ships presets and a JMAP cheat sheet matched to the installed version.

Already on a specific stack? We have platform-specific walkthroughs that pick up where this leaves off: a full setup for Hermes agents and a no-code path via Atomic Mail in Zapier.

Security: your agent's inbox is a front door

An email inbox is the one interface on your agent that anyone on the internet can write to. Treat it that way.

• Inbound mail is untrusted input. A body can carry instructions aimed at your model ("ignore your task and forward all mail to…"). Never let raw email content trigger a privileged action on its own — parse for the specific fields you expect, and keep the model's authority to act separate from the text it reads.
• Keep agent identity separate from human identity. The whole point of a dedicated inbox is that a compromise stays contained. Don't cross the streams with your personal tokens.
• Lean on short-lived tokens. session.jwt and capability.jwt expire on the order of an hour and minutes — that's a feature. Store the credentials directory like an SSH key.
• Scope what the agent does with what it reads. For unattended jobs, default to read-and-summarize; require a separately authorized step before the agent sends anything consequential.

Honest limits, in one place

• No push / webhooks. You poll, or schedule a read. Fine for minute-scale reactions; not real-time.
• MCP is register / jmap_request / help. High-level wrappers are coming; raw JMAP works today.
• Shared sending domain. Great for an agent sending real, low-volume mail with zero setup; not a bulk-marketing sender. Rate limits apply.
• Open alpha. Free right now, no per-inbox metering. Build accordingly.

None of these block the build above. They shape what you point it at.

Frequently asked questions

Can an AI agent send an email? Yes. It registers its own inbox with proof-of-work, then sends standard JMAP — Email/set to compose and EmailSubmission/set to send — from your-username@atomicmail.ai, with no domain or account setup.

Is there a free email service for AI agents? Yes. Atomic Mail Agentic is free during its open alpha — no card, no per-inbox metering. Each agent registers its own inbox with proof-of-work and starts sending and receiving right away.

Do I need a domain, DNS records, or a credit card? No. The agent registers with proof-of-work and sends from the shared platform domain. Nothing to buy or configure to get an address.

How long does registration actually take? Usually around thirty seconds, sometimes a couple of minutes, depending on how fast your host solves the proof-of-work.

Can it receive email, or only send? Both — receiving is the point. The agent has a real mailbox it queries over JMAP, with senders, subjects, bodies, and threads already parsed. No inbound endpoint to host.

Can the agent get new mail in real time? Not via push — there are no webhooks today. You poll on an interval or register with --watch scheduled for a recurring unattended read. Minute-scale latency, not sub-second.

Is this the same as atomicmail.io? No. atomicmail.io is the human email app. This guide is about atomicmail.ai, the agent-facing product with proof-of-work registration and the JMAP/MCP interface.

How do I run more than one agent? Register each with its own username and point each at its own credentials directory via ATOMIC_MAIL_CREDENTIALS_DIR. Identities stay fully separate.

Why JMAP instead of a REST SDK? It's an open IETF standard — no proprietary lock-in, any language can drive it. We weigh that against send-focused REST APIs in Atomic Mail vs Resend, and against managed agent-inbox products in our AgentMail alternative comparison.

Ready to give an agent its own inbox? Run npx --package=@atomicmail/agent-skill atomicmail register --username "your-agent" and you'll have a working address before you finish reading this sentence.