Email for Agents · September 26, 2026

State of Agent Email 2026: Four Architectures

Agent email architecture types, tested against 20 products' own docs: what each is best at, and the failures each will keep no matter who builds it.

Ask a dozen vendors how to give an AI agent email and you get a dozen answers that sound alike and rest on four different foundations. Some mint a new mailbox per agent with an API call. Some borrow a person’s Gmail or Outlook through OAuth. Some are sending platforms that hand you inbound mail as a webhook. Some give you routing rules and storage and leave the rest to you. Roundups table them as if they competed on features. They do not. They make different promises about whose name is on the From line and who keeps the record, and those promises decide which failures you get.

This piece proposes a taxonomy of agent email architecture types, places 20 products into it using only their own pages as read on 25 September 2026, and names the problems each architecture keeps regardless of how well it is built. The finding with the most practical weight is about approval. Whether the credential an agent holds, rather than application code, can stop it from sending is largely settled by the architecture before any vendor is chosen. A vendor can offer it in two places: an agent-owned inbox whose vendor withholds the send path, and Microsoft Graph, which keeps Mail.Send apart from Mail.ReadWrite. Every Gmail API scope that can create a draft can also send, and in a self-assembled system the property exists only once you build it. We sell one of the four, we say which, and we say where it loses. If you are choosing between two of them for a single agent, agent inbox versus connecting Gmail is the narrower comparison.

Four agent email architecture types, sorted by two questions

Two questions sort the market cleanly. Whose identity sends the mail? And who holds the mailbox of record, meaning the durable copy of every message and thread the agent reasons over? Features vary within each answer; the failures follow the answers.

The evidence forced one refinement to the four axes this started from. Architectures 3 and 4 give the same answer to both questions: the application is the mailbox. What separates them is who writes the code between the MX record and your storage. In 3 the vendor parses the message and posts you an event, and your code begins at the webhook. In 4 your code runs inside the mail path, as an Email Worker or a Lambda behind an SES receipt rule, and parsing, storage and retention are yours outright. They stay separate because they fail differently, not because they store differently.

A fifth candidate was tested and rejected: managed-OAuth intermediaries such as Composio and MCPEmails. They change who handles the tokens, not whose mailbox it is, so they sit inside architecture 2.

Agent-owned inboxes provisioned by API

An agent-owned inbox is an address created for software by an API call, with its own threads, messages and credentials, held by the vendor. This is the most crowded of the four. Most products below provision by API today; Hostinger’s API is still “coming soon”, and InboxAPI provisions through MCP and a CLI:

• AgentMail calls itself “the email inbox API for AI agents”, and its docs describe an inbox as “a fully loaded, programmatically accessible API resource”. Its free plan is 3 inboxes and 3,000 emails a month.
• Robotomail: “One POST creates a mailbox.”
• OpenMail gives “any agent its own email address with one API call”; its FAQ says to “call POST /v1/inboxes and get a live address back”. Its free plan is 3 inboxes and 3,000 emails a month.
• Zoho AgentInbox provisions agents with a POST to /api/v1/agents, and its free plan “includes 5 inboxes, 2,000 emails per month”. The page offers both “Get started” and “Join waitlist”, so general availability could not be confirmed.
• InboxAPI gives an agent “a personal @inboxapi.ai email address in seconds”, set up with “One command” and used over MCP, with “no API keys to manage”. Its page does not mention a REST API.
• AgenticEmail describes “programmatic inboxes, REST API, webhooks, real-time events, and an MCP server”.
• Hostinger Agentic Mail sells an “Isolated inbox per agent” from $0.39 a month on a 48-month term, renewing at $1.59. Its FAQ says “Full API access and an MCP server are also coming soon”, and until then “webhooks and prebuilt skills” cover automation. The same page’s comparison table lists a “Clean REST API” and an “MCP server”, so it disagrees with itself; we go by the FAQ.
• Email for Agents, which is us; see the last section.

This architecture is best at identity isolation at scale. Each agent is its own principal, so you can revoke one without touching a person, and the hundredth inbox costs the same call as the first. Zoho’s page puts the argument in one line: “Every agent that borrows a human’s mailbox inherits that human’s keys, history, and liability.” Because the vendor owns the inbox resource, it can also hang agent-specific controls on it. AgentMail documents Drafts for “Human-in-the-Loop Review” and Lists “to control which email addresses and domains your agents can send to or receive from”.

The structural weakness is that the identity is new. A fresh address has no sending history, no correspondents and no place in any existing conversation, and three consequences follow for every vendor in the list.

Reputation has to be earned. AgentMail’s own warming guide says “A brand new domain has zero reputation”, and on a shared vendor domain that reputation is pooled across tenants. The second consequence is less discussed. An API that mints sending addresses on a shared domain is exactly what an abuser wants, so the vendor has to restrict who a new inbox may write to. The free tiers show it. Robotomail’s free plan allows “10 sends and 10 receives per month, only between your agent and your verified email address”. InboxAPI enforces “addressbook-based recipient limits (5 slots, LRU eviction after 5 days of inactivity)”. That is the architecture defending itself. The third consequence: the agent cannot see mail it was never sent. A customer that began in a person’s inbox is invisible to it until someone forwards or copies it in.

Borrowed human mailboxes over OAuth

A borrowed mailbox means the agent works inside an inbox that already belongs to a person, through delegated OAuth into the Gmail API or Microsoft Graph, either directly or through an intermediary that manages the tokens.

Above the providers, Nylas “uses OAuth 2.0 to create grants” over Google, Microsoft, Yahoo and iCloud accounts, and connects any IMAP server with app passwords. Composio provides “a managed OAuth app for Gmail, so you sign in with your normal Gmail account and approve access”, with token refresh handled for you. MCPEmails runs a hosted MCP server that “gives AI agents read and send access to your inbox, without ever storing the email it reads”, using OAuth for Gmail and Outlook and app-specific passwords for Fastmail, iCloud and others.

What it is best at is context and trust that already exist. The agent sees the full history, replies inside threads a person started, and sends from an address the recipient already knows. There is nothing to warm up. For an assistant acting for one named person, this is the right architecture, and no agent-owned inbox can reproduce it.

The structural weakness is that the permission model belongs to the mailbox provider, and it was designed for apps acting for people, not for software acting instead of them. The sharpest example is Gmail. The method that creates a draft, drafts.create, accepts three scopes, and Google’s scope table describes every one of them as including send: gmail.compose is “Manage drafts and send emails”, gmail.modify is “Read, compose, and send emails from your Gmail account”, and https://mail.google.com/ is “Read, compose, send, and permanently delete all your email from Gmail”. No Gmail API scope that can create a draft withholds send. Microsoft draws the line elsewhere: Graph’s Mail.ReadWrite “Does not include permission to send mail”, and Mail.Send is a separate permission. So whether “draft, but never send” can be expressed as a credential depends on which provider the human happens to use, not on anything the agent’s developer decides.

Reading costs something too. gmail.readonly is a restricted scope, and Google states that “If you store restricted scope data on servers (or transmit), then you must go through a security assessment”. That assessment runs under the CASA framework, and “All applications must be revalidated every year.” Intermediaries absorb it: Nylas’s Google Shared App lets customers “avoid the Google Cloud setup, the OAuth verification, and the CASA assessment entirely”, on the annual Pro plan with the Accelerator add-on, or as an add-on to Enterprise. That moves the cost. It does not change what the scopes mean, because Google defines them.

The blast radius is shared as well. When a Workspace account hits a sending limit, “users can’t send new messages for up to 24 hours.” An agent that loops on a borrowed Workspace mailbox silences the person whose mailbox it is.

Send-first platforms with inbound as a webhook

A send-first platform is a transactional sending provider that also accepts mail for your domain, parses it, and notifies your endpoint. There is no per-agent inbox resource. The unit is a domain or a routing rule.

Resend receives mail “at a verified domain, or at your account’s Resend-managed <id>.resend.app subdomain”, and “You will receive emails sent to any address at your Resend domain.” Postmark lets you “send inbound emails (hash@inbound.postmarkapp.com) to Postmark, which we then process and deliver to you via a webhook in nicely formatted JSON.” Mailgun routes can forward a message to a URL, or store() it, which “temporarily stores the message (for up to 3 days)”.

What it is best at is outbound quality and addressing freedom. Any local part at your domain works without provisioning, which suits one address per ticket or per customer. The sender reputation you have already built on your domain carries over.

The structural weakness is that the application is the mailbox, so conversation state is yours. Resend’s docs are candid about it. To reply in thread you set In-Reply-To to the received message_id, and “If you’re replying multiple times within the same thread, make sure to also append the previous message_ids to the References header.” Carrying that chain across turns, for every conversation, is your code’s job, and the failure modes are set out in email threading for agents. Resend’s webhooks “do not include the email body, headers, or attachments, only their metadata”, so every inbound message is an event plus a fetch, and an event you never processed is mail your agent never read unless you reconcile against the receiving API. Mailgun’s stored copy lasts up to three days. A Resend API key is either full_access or sending_access, and a sending key can be restricted “to send emails only from a specific domain”. No key is scoped to one address, so nothing in the architecture knows which agent an address belongs to. Per-agent scoping is something you build, and so is dedup when the same event arrives twice, covered in duplicate webhook events.

Primitives you assemble yourself

The fourth architecture is routing, storage and compute from an infrastructure provider, wired by you into something that behaves like a mailbox.

Amazon SES receiving is the long-standing example. Its receipt rules “can do advanced processing such as deliver incoming mail to an Amazon S3 bucket, publish it to an Amazon SNS topic, send it to Amazon WorkMail”, and receiving works only in AWS Regions where SES supports it. Cloudflare’s post “Email for agents”, by Thomas Gauvin and Eric Falcão on 16 April 2026, put Cloudflare Email Service into public beta and pointed to the Agents SDK’s “first-class onEmail hook for receiving and processing inbound email”. Cloudflare also open-sourced Agentic Inbox, which its README calls “A self-hosted email client with an AI agent, running entirely on Cloudflare Workers”, under Apache 2.0.

What it is best at is control and data locality. Every byte sits on infrastructure you contract for, any policy you can write in code is available, and the marginal cost is the infrastructure’s.

The structural weakness is that every control is yours to write, so every omission is yours too. Cloudflare’s README is precise about its own reference app: “Any user who passes the shared Cloudflare Access policy can access all mailboxes in this app by design. This includes the MCP server at /mcp […] There is no per-mailbox authorization; the Cloudflare Access policy is the single trust boundary.” That is fair for a reference app, and it illustrates the pattern. The per-agent authorization layer that architecture 1 sells is the first thing a self-assembled system does not have.

The platform’s mail rules also become your agent’s behaviour. Cloudflare’s reply() throws unless the inbound message has “a valid DMARC result”, allows one reply “per EmailMessage event”, requires the reply recipient to “match the sender of the incoming email”, and rejects messages with “more than 100 entries in its References header”. Each is a sensible rule an agent developer did not choose and must design around.

Straddlers, and what our own research got wrong

Several vendors sit in two architectures at once.

• Nylas spans 2 and 1 on one grant model. Its connected accounts are borrowed mailboxes. Its Agent Accounts are “owned by your software, not borrowed from a person”, “hosted by Nylas”, with “Same grant_id. Zero new endpoints.” That is the clearest evidence that the line between 1 and 2 is identity and mailbox ownership, not API shape.
• Mailtrap is a sending company whose Agent Inbox is architecture 1 delivered in the style of 3. Inboxes are hosted, “persistent or disposable”, but “The webhook delivers event IDs and key metadata; your agent fetches the full parsed message from the Messages API.” Unlike Resend, it says “Mailtrap handles headers and sender address” when an agent replies in thread.
• Resend is architecture 3 with one step toward 1. The <id>.resend.app subdomain removes the DNS step, but there is still no inbox resource per address.
• Hosted mailboxes with a human client attached blur 1 and 2 from the other side. AgentMail supports “standard IMAP and SMTP protocols”. Shipmail sells business email you can read in “Apple Mail, Outlook, or any email app” over “IMAP · SMTP · CalDAV”, with “the official MCP server” for agents. The agent owns the mailbox, and a person can open it too.
• Cloudflare Agentic Inbox is architecture 4 assembled into an architecture 1 product that you deploy and operate yourself.

Checking our own research file

How far to trust any roundup, ours included, depends on its notes. Our leads came from an internal competitor research file this site recorded on 21 September 2026. The rule: every statement in it that gives a price, a numeric plan limit, a launch status or a deployment model for a vendor named in this piece, excluding figures the file attributes to third parties and compliance claims. Fourteen statements qualified. Each was checked on 25 September 2026 against the vendor’s own page, linked in the sources below.

Three of fourteen failed. For Robotomail we cannot tell whether the tier changed or was recorded wrong. The Hostinger mailbox row holds as worded, but the file went on to call it “fatal for agent fleets”; the page quotes each price per mailbox and does not say whether more can be added, so that conclusion could not be checked. Fourteen statements from one file is a small sample and supports no error rate for the category. What it does show is where the errors sat: a launch status, a deployment model and a free-tier limit. Treat a figure of any of those kinds that was not read at source recently as unverified, including the ones in this piece once it is a few months old.

What the taxonomy predicts

Each prediction below is about the architecture, so it should hold for every vendor in it, including ones that do not exist yet.

1. Agent-owned inboxes will keep fighting cold identity and abuse. Every vendor that mints addresses on a shared domain has to cap who new inboxes can reach and earn reputation per domain. Expect free tiers to tighten rather than loosen, and custom domains to stay the price of real sending volume. No implementation gives an agent history for mail it was never sent.
2. Borrowed mailboxes will keep inheriting permission semantics they do not control. gmail.compose will mean drafts and send until Google says otherwise, read access will carry an annual assessment for anyone storing data server-side, and sending limits will stay shared with the human. Intermediaries will move these costs without removing them, and holds on send will live in their code. MCPEmails already lets you “Turn on per-inbox approval to hold sends” for dashboard review. Its messages “go through Gmail, Outlook, Fastmail, or your own SMTP server”, so the Gmail grant beneath the hold must still carry send. The hold is real, and it is a property of MCPEmails’ code, not of the credential.
3. Send-first platforms will keep making the application the mailbox. Threading helpers and dashboards will improve. Per-agent identity, per-agent authorization and a durable conversation record will stay application code, because the unit of the architecture is a domain, not an agent.
4. Self-assembled systems will keep shipping without an authorization layer between agents and mailboxes until their builders write one, and platform mail rules will keep surfacing as agent behaviour nobody specified.

One cross-cutting prediction follows from those four. A credential can enforce human approval of a send only where one system holds both the draft and the transmit path and can refuse to transmit, or where the provider’s scopes separate the two, which Graph does within architecture 2. Architecture 1 vendors are placed to offer the first. In architecture 4 you can build it, by giving the agent a credential with no send permission and transmitting only from the approval path, but nothing provides it until you do. Whether a given vendor in architecture 1 actually binds the send to an approval is a separate question, and the AgentMail alternatives shortlist shows the answer varies. On a Gmail-backed agent and in architecture 3, a held send is enforced by code, yours or an intermediary’s, not by the credential. Our treatment of what that enforcement has to cover is in human approval before an agent sends.

The predictions are falsifiable. If Google ships a Gmail scope for drafts without send, prediction 2 weakens. If a send-first vendor ships per-address inboxes with their own credentials, it has moved into architecture 1 rather than refuted 3.

Where Email for Agents sits, and what that costs us

We are architecture 1, one of four, with its trade-offs intact. An agent gets its own address on agents.emailforagents.ai, reads, drafts and sends over remote MCP or a REST API, and a human console shows every thread. Our documented surface does not include IMAP or SMTP access.

Inside architecture 1 we chose to compete on the permission boundary rather than on quota. A read-and-draft grant yields an MCP session in which send_message is not in the tool list at all, and create_draft cannot transmit mail on any grant; the mechanics are in the MCP tool surface as a permission boundary. A held send becomes an approval, and this build emits approval.requested and approval.rejected. Our event catalogue also declares approval.approved and approval.invalidated, and this build never fires either. Test inboxes use non-routable .mail.invalid addresses and a simulated transport, so they cannot reach an internet recipient.

We inherit every weakness of the architecture, and some vendor-specific ones on top. Our addresses are new and sit on a shared domain. Our agents cannot see threads that live in a person’s mailbox. Custom domains require a paid plan and paid plans are not purchasable yet, while AgentMail’s $20 Developer plan lists 10 custom domains today. Our free tier is one live inbox and 100 email units a month, against 3 inboxes and 3,000 emails at AgentMail and at OpenMail, and 5 inboxes and 2,000 emails at Zoho. AgentMail and Shipmail offer IMAP; we do not. We hold no third-party security certification.

So the recommendation is by architecture, not by vendor. If the agent acts for one named person with existing correspondents, borrow the mailbox. If you need any address at a domain that already has sending reputation, use a send-first platform and build the state. If the data must stay on infrastructure you contract, assemble the primitives and write the authorization layer first. If each agent needs its own identity and you want the send path withheld by the credential rather than by your code, that is architecture 1, and the vendor-by-vendor trade-offs are on our comparison pages. The wider picture of what an agent inbox has to do is on the Email for Agents home page.

Sources

All pages read on 2026-09-25.

• AgentMail home
• AgentMail pricing
• AgentMail docs: Inboxes
• AgentMail docs: Drafts
• AgentMail docs index (Lists)
• AgentMail docs: IMAP & SMTP
• AgentMail docs: Warming Up
• Robotomail home
• Robotomail pricing
• OpenMail home
• Zoho AgentInbox
• InboxAPI home
• AgenticEmail on GitHub
• Hostinger Agentic Mail
• Nylas Agent Accounts
• Nylas blog: Introducing Nylas Agent Accounts
• Nylas docs: Authentication
• Mailtrap Agent Inbox
• Shipmail home
• Shipmail pricing
• Composio Gmail toolkit
• MCPEmails home
• MCPEmails pricing
• Gmail API scopes
• Gmail API: users.drafts.create
• Google Cloud: Security Assessment
• Gmail sending limits in Google Workspace
• Microsoft Graph permissions reference
• Resend API reference: Create API key
• Resend docs: Receiving Emails
• Resend docs: Get Email Content
• Resend docs: Reply to Receiving Emails
• Postmark: Inbound processing
• Mailgun: Route actions
• Amazon SES: Email receiving
• Cloudflare blog: Email for agents
• Cloudflare Email Service docs
• Cloudflare Agentic Inbox README
• Cloudflare Email Service: email handler and reply()

research inboxes permissions foundations

Keep reading

All guides · Documentation · Email for Agents