AgentMail Alternative: Control Plane, Not Quota

7 min read · Reviewed by Email for Agents Engineering · AgentMail checked September 22, 2026

AgentMail wins on quota, audit reports and custom domains, and you should pick them for any of those. Pick Email for Agents when the permission boundary has to live in the MCP tool surface, when approval must be a resource and not a label, and when the inbound loop must run against a non-routable inbox.

At a glance

Where AgentMail is ahead, and it is not close

Three of the rows above go to them without argument, so deal with those first.

Their free tier is 3 inboxes and 3,000 emails a month, with a 100-a-day ceiling and 3 GB of storage. Ours is one live inbox and 100 email units a month, where an email unit is one message received or one recipient sent to. That is a thirtyfold difference in monthly volume. If you are evaluating on headroom, stop reading and go sign up with them.

They state SOC 2 Type II compliance, with an observation window running August to November 2025 and 93 controls across all five trust services criteria. They do not publish the report: their trust centre offers Type I and Type II to current and prospective customers under NDA, and their pricing table lists the SOC 2 row against Startup and Enterprise only, so on the $20-a-month Developer plan you get the controls without the paper. We hold no report of either type, and we say so on our security page rather than gesturing at a roadmap.

Custom domains are theirs too. Developer includes 10, Startup includes 150. Here, custom domains need a paid plan and paid plans are not purchasable yet, which means live mail runs on agents.emailforagents.ai and nowhere else. Add IMAP and SMTP access, multi-tenant Pods, WebSockets alongside webhooks, and dedicated IPs at the enterprise tier, and the surface-area comparison is not a contest.

Two more of their things deserve credit because they are well built rather than merely present. Their Lists model has six types, allow and block crossed with receive, send and reply, evaluated most-specific-first across organisation, pod and inbox scope. That is a more complete recipient guardrail than our per-inbox policy. And their send idempotency is properly done: an Idempotency-Key header, a replay that returns the original message ID without sending again, a 409 Conflict when the same key arrives with a different body, a 400 on an explicitly empty key rather than a silent downgrade, and a 24-hour expiry. We do the same thing on sends. Nobody should pick a vendor on that row.

The permission boundary sits somewhere different

Here is the architectural difference, and it is the only reason this page exists.

AgentMail’s permission model is a whitelist on the API key. Their permissions page lists roughly thirty-five strings, message_send, draft_create, inbox_delete and so on, intersected with the key’s scope, with child keys unable to exceed their parent. That is a sound design and it closely matches our own rule that a credential cannot exceed its creator.

Then look at where that model stops. Their MCP documentation describes a hosted server at mcp.agentmail.to/mcp exposing a fixed catalog, and the runtime contract they publish as mcp-manifest.json names 37 tools, more than the 24 their MCP page describes. Each entry in that manifest carries name, title, description, inputSchema, outputSchema, annotations, execution, oauthOnly and apiKeyOnly. There is no permission field, and no scope field. The only thing that varies the catalog is which kind of credential you used, not what that credential is allowed to do.

So an agent connected with a read-only AgentMail key still sees send_message, reply_to_message, forward_message and send_draft in its tool list. The key stops the call. Nothing stops the model from choosing it.

Ours is the other arrangement. visibleTools() filters tools/list by the grant before the response is built, and tools/call re-checks the same predicate before dispatch. send_message requires messages:send. A grant of read plus draft produces a session in which send_message is not in the catalog at all, and the model has nothing to select. We cover the mechanics in the MCP tool surface as a permission boundary, and the scope vocabulary, all 32 strings of it, in agent email permissions and scopes.

This matters for exactly one threat, and it is the threat that defines this category. A hostile email body is untrusted text that lands inside the model’s context. It can argue, impersonate and instruct. What it cannot do is invoke a tool the session never advertised. A denied call is an audit line after the fact; an absent tool is a thing that never had a name to be talked into.

One related detail. Their MCP server accepts an API key over an x-api-key header for clients that do not implement the OAuth flow. Ours rejects API keys at /mcp outright, so the only way to call a tool is an OAuth connection grant tied to a human who authorised it. Theirs is the more compatible choice and they are right that Cursor and Windsurf need it. Ours is the more restrictive one, and it is deliberate.

An approval is a resource here and a convention there

Their human-in-the-loop guide is honest and practical. It gives you four patterns: CC or BCC a human on every send, create a draft and have a person call drafts.send, apply a needs-human-review label and poll for it, or constrain recipients with a send allowlist. Their drafts also do scheduled sending through send_at, which is genuinely useful.

Every one of those is a convention you assemble and maintain. There is no approval resource, and their webhook catalog confirms it. The events they document are message.received with its .spam, .blocked and .unauthenticated variants, message.sent, message.delivered, message.bounced, message.complained, message.rejected, message.opened, and domain.verified. Eleven events, all of them about mail. None about a decision.

Ours is a row with a lifecycle rather than a field you set. A held send writes an approvals record in state pending with expires_at seven days out and emits approval.requested. A refusal moves it to rejected and emits approval.rejected. A yes marks the record consumed and the send resumes, so it is observable as message.queued. Two further names, approval.approved and approval.invalidated, are declared in the catalogue and never emitted by this build, so instrument the pair that fires.

The event names are not the point; what hangs off the record is. The decision binds to exactly what was reviewed: the canonical payload — inbox, recipients, subject, body, attachment IDs — is hashed with SHA-256 onto both the approval and the draft version, and a mismatch at decision time is refused with version_conflict instead of sent. Authority is re-read at that same moment, so revoking the agent’s key or blocking the recipient while its draft waits makes the approval fail rather than go out. Approving carries its own idempotency key, so a double-clicked button cannot produce two emails. And an approval nobody acts on expires rather than waiting indefinitely for someone to remember it.

A label has nowhere to put any of that. needs-human-review is a string on a record: it does not bind to a version of the body, it does not expire, and nothing re-checks the sender’s authority at the moment somebody clicks send. Their four patterns work, and for one agent with one operator watching it they may be everything you need. The gap opens when the reviewer is not the person who built the agent. The details are on controls and in human approval for agent email.

Testing: whose mailbox does the message land in

The narrow claim, and the one that survives checking. Both approaches to inbound testing exist in this market and neither is unique. What differs is whether a test message has to cross a transport, and whose mailbox receives it.

Our test inboxes use a non-routable .mail.invalid address and a simulated transport. You inject inbound mail with the test:simulate scope through POST /v1/projects/{project_id}/test/inbound, and it appears in the agent’s own mailbox. The inbox cannot reach an internet recipient, so a bug in the agent’s send path cannot email a real person. Environment is carried in the key prefix: an efa_test_ key resolves only to test projects and test inboxes, and no flag crosses it. The allowances are small and stated: 3 active test inboxes per workspace, the last 100 messages, 10 MB, and content expiring after 7 days. The CI pattern is in testing agent email without sending.

On AgentMail’s side, no test mode, sandbox inbox or non-routable address appears anywhere in their published documentation index, which we read in full today. Their inboxes are real and routable from the moment they are created, which is the point of the product. The consequence is that a CI run either sends real mail from a real address, or you stand up a third-party catcher and test against someone else’s mailbox instead of your agent’s. Their own comparison writing points at MailSlurp for exactly that job.

What could not be verified

Two things, stated rather than papered over.

Their Startup plan’s monthly email allowance is inconsistent across their own pages. Their pricing comparison table leaves the emails-per-month cell blank for Startup and gives 15,000 emails a day, while their rate-limits article gives 150,000 emails a month for the same plan. We have not worked out which governs, so treat the monthly number as unconfirmed. Their API rate limits are described as generous and plan-dependent without published figures, so there is nothing to compare there either.

Second, the security overview their SOC 2 page links to, at agentmail.to/security, returned a 404 when we fetched it today. That is almost certainly a broken link rather than a missing programme, given how specific the SOC 2 page is about controls, but it means the control detail behind their audit reports could not be read first-hand.

If quota, certification or custom domains decide it for you, the decision is already made and it is not us. If what decides it is whether an injected instruction can reach a tool that was never in the session, start with sending controls and the free tier, and measure the two against the same hostile email.

Sources

Everything stated above about AgentMail was read from these pages on September 22, 2026 . Products change; if a claim here is stale, it is a bug worth reporting.

• https://agentmail.to/pricing
• https://docs.agentmail.to/llms.txt
• https://docs.agentmail.to/integrations/mcp.md
• https://docs.agentmail.to/permissions.md
• https://docs.agentmail.to/events.md
• https://docs.agentmail.to/knowledge-base/human-in-the-loop.md
• https://docs.agentmail.to/knowledge-base/rate-limits.md
• https://docs.agentmail.to/idempotency.md
• https://docs.agentmail.to/lists.md
• https://docs.agentmail.to/documentation/resources/security-privacy/soc-2-compliance.md
• https://github.com/agentmail-to/agentmail-mcp/blob/main/mcp-manifest.json

Related comparisons

• Resend for AI Agents: Sending API vs Agent Inbox
• Gmail API for AI Agents vs a Dedicated Agent Inbox