"Email for agents" describes a specific, narrow capability: giving a piece of autonomous software — not a human, not a shared team account — a real email address it can draft from, send from, and receive into on its own. DimeBox builds that capability directly: an agent provisions an inbox, drafts and sends mail, and reads whatever arrives, paying a few cents per call instead of signing up for an account. There's no signup, no API key, and no subscription for the core per-call product. This guide covers what email for agents means in practice, how payment actually works, and how the pieces — drafting, sending, receiving, security — fit together. Links throughout point to the posts on this blog that go deeper on each piece.
Most "email for AI" discussion today means something narrower than it sounds: a human's Gmail account with an LLM drafting replies inside it, or a shared support inbox an agent is allowed to read. Email for agents, as DimeBox builds it, means the agent itself is the account holder. It provisions its own inbox, gets its own address, and the only thing proving it owns that inbox afterward is a credential issued to it directly — not a login shared with a person.
That inbox isn't a full mailbox. There's no IMAP, no webmail, no folders — just a flat, time-ordered list of messages capped at the newest 500, with older messages pruned automatically. That's a deliberate scope cut, not a missing feature: an agent doesn't need a client-side mail app, it needs an address it can poll or get pushed to. The single credential controlling read access is a read token shown once at creation time, with no password-reset flow to fall back on if it's lost.
An agent that borrows a human's email account inherits that human's entire mail history, contacts, and blast radius the moment the credential leaks. An agent that's only allowed to read a shared support inbox can't send anything distinctly as itself. Neither setup gives the agent a durable, scoped identity of its own — which matters more as agents start corresponding with other agents and services, not just relaying messages for a person watching over their shoulder. Starting that identity with an inbox is a reasonable default: an email address is portable, it's one of the few identifiers almost every system already knows how to validate, and it doesn't require the agent's operator to register anything in advance.
Provisioning reflects that: a free, IP-throttled route (three per day) hands back a random slug like bold-ember-564, no payment or account required. An agent that wants a specific name instead pays a flat $1.00 to claim one — availability is checked before payment settles, so an unavailable name fails for free. Reserved, phishing-prone slugs (admin, support, billing, security, paypal, noreply, and similar) are rejected outright, on both routes.
That reservation list isn't about trademark protection — it's about not letting a phishing operation register paypal-support@ or billing@ under an agent-provisioning API that doesn't ask who's behind the request. The same logic that makes free provisioning fast for legitimate use makes it attractive to abuse, so the names most useful for impersonation are the ones taken off the table entirely rather than left to a case-by-case review.
Every paid call in DimeBox follows the same pattern, and it's the part of email for agents that's genuinely new rather than just email with extra steps. x402 revives HTTP's long-dormant 402 Payment Required status code as an actual payment handshake: call a priced endpoint unpaid, get back a 402 describing the price in a PAYMENT-REQUIRED header, sign a USDC payment authorization under x402's exact scheme (an EIP-3009 transferWithAuthorization, specifically), and retry the same call with a PAYMENT-SIGNATURE header attached. The paid route then runs normally. A facilitator verifies and settles that signed authorization against USDC on Base — Base mainnet (eip155:8453) in production, Base Sepolia (eip155:84532) for testing — and settlement only happens if the route's own response comes back under 400. A failed call, for any reason, is never charged.
Signing a payment on every call is the right model for an agent that already holds a wallet key, but it's not the only option. DimeBox also accepts a card-funded wallet: send Authorization: Bearer <wallet_secret> instead of a signed payment, and the same priced routes run at the same prices without the 402 round trip. The wallet is funded through Stripe Checkout and supports a daily spend limit, auto-reload (a threshold and a top-up amount), and an optional monthly subscription that waives the one-time setup fee. New wallets are capped — $50 balance, $10 per day — for their first few days as an anti-fraud measure before those caps lift. See paying by card instead of crypto and how the wallet itself works for the full mechanics, and the threat model behind x402 if you're deciding which model fits your agent. Either way, prices are read live from this deployment's config at call time; see the API docs for the authoritative numbers.
Drafting is its own call, with no inbox required: POST /api/emails/generate takes a recipient and a plain-language purpose (plus optional tone, key points, and sender name) and returns a subject and body, for $0.02. That's useful on its own for an agent that just needs copy, but most agents want to draft and send in the context of a real inbox they already hold.
Sending from an inbox costs $0.01 per call and accepts two shapes: a raw {to, subject, body} payload sent exactly as written, or — if the inbox has AI drafting enabled, which is the default — a {to, purpose, tone, key_points} brief the same drafting model turns into copy before sending. Choosing between the two is mostly about how much latitude your agent's task actually needs; an inbox provisioned with AI drafting turned off rejects a purpose body outright rather than silently drafting one. Either way the response comes back 202 Accepted immediately — delivery happens on a background queue, so the paid call never blocks on an SMTP round trip. The response itself only confirms the message was accepted onto that queue; checking whether it actually reached the recipient's server still means polling the inbox's own message list afterward.
Receiving splits into two channels because plain SMTP has no way to carry an x402 payment handshake — a human replying from their own mail client can't sign a wallet authorization mid-send. Ordinary mail arrives free: a third-party mail relay accepts anything addressed to the inbox's domain and forwards it in, the same way mail reaches any ordinary mailbox, subject to that relay's own spam filtering along the way. A priority channel exists alongside it — another x402-speaking agent or service pays $0.03 to write a message directly into the inbox's history in the same request that settles payment, with no dependency on the free relay's filtering or queue.
Whichever channel mail arrives through, treat the content as untrusted input before handing it to an LLM. Neither channel currently attaches SPF/DKIM/DMARC results to a message, and nothing marks a body as suspect before your agent sees it — the same caution you'd apply to any other third-party text landing in a prompt applies here too.
A few design choices in DimeBox exist because the caller is assumed to be a machine, not a person who can call support. Read tokens are the only way in — DimeBox hashes them rather than storing them directly, the same way a password would be handled, and there's no recovery flow if one is lost. New wallets start capped specifically because an autonomous caller that discovers it can spend without a human double-checking each transaction is exactly the failure mode those caps exist to contain. And DimeBox never records which wallet or address paid to create a given inbox, which limits what could leak even if the application's database were ever exposed.
None of this makes an agent's inbox more trustworthy than a human's by default — it just means the trust boundaries are explicit instead of assumed. That's arguably the more honest starting point for software that pays its own way and corresponds without a person reading every message first.
The fastest way to see the whole flow is the live quickstart in the API docs, with working Node and Python examples against the current x402 buyer SDKs. If you're deciding whether per-call pricing fits your use case at all, pay-per-call vs. subscription pricing for agent APIs and the Python quickstart are good next stops, and DimeBox vs. rolling your own SMTP + LLM stack covers what you're trading off against building this yourself. For the wallet side specifically, the wallet page is where funding, limits, and auto-reload actually live.
None of this assumes any particular framework or language. The payment handshake and the inbox API are both plain HTTP — a signed header on a request is the only thing a buyer SDK adds, and the SDKs cover the common case so you don't have to implement signature logic by hand. Whether that call comes from an agent framework's tool call, a cron job, or a shell script makes no difference to the API on the other end; it only ever sees a request with or without a valid payment attached.
Every agent eventually needs some way to correspond outside its own runtime — email for agents is simply the version of that capability built on infrastructure that already exists everywhere, rather than a new protocol every counterparty has to adopt first. The rest of this blog is organized around the pieces covered above: x402 fundamentals, inbox mechanics, drafting and sending, receiving, wallets, the economics of paying per call, security, framework integration, and how this compares to the alternatives. Start wherever your agent's actual bottleneck is.