Resend for AI Agents: Sending API vs Agent Inbox

7 min read · Reviewed by Email for Agents Engineering · Resend checked September 21, 2026

Resend is an excellent transactional sending API that now also stores inbound mail for the whole team. Email for Agents is a mailbox per agent, with scoped grants, a filtered MCP tool surface and an approval gate. Pick Resend for volume and deliverability, pick this for a constrained agent identity.

At a glance

Dimension	Email for Agents	Resend
Mailbox identity Resend's own OpenClaw guide suggests creating a separate team to sandbox an agent, which is the workaround for a missing per-agent boundary.	The inbox is the object. Each one has an id on agents.emailforagents.ai and a credential can be pinned to specific inbox_ids.	Receiving is team-level: a Resend-managed <id>.resend.app subdomain that accepts any username, or your own domain with an MX record.
Inbound storage and query	Threads and messages are REST resources under /projects/{id}/inboxes/{id}/threads and .../threads/{thread_id}/messages.	GET /emails/receiving lists mail received by the team, paginated with limit, after and before only. No recipient filter, no conversation id in the response.
Threading a reply	A reply is sent against a message id, over REST or the send_message MCP tool.	Documented as manual: set In-Reply-To to the received message_id, append earlier ids to References, and prefix the subject with Re: yourself.
Credential granularity	32 named scopes. A credential cannot request a scope its creator's role lacks, and environment is fixed in the efa_live_ or efa_test_ key prefix.	Two API-key permissions, full_access and sending_access, plus an optional domain_id that applies only to sending_access.
MCP tool surface	tools/list is filtered by the grant and tools/call re-checks it, so a read-and-draft grant yields a session with no send_message tool present.	Hosted at mcp.resend.com/mcp with OAuth or an API-key bearer token, plus a local stdio server. No per-tool scoping is documented.
Approval gate	An API resource with its own events and a seven-day expiry, and a drafts:submit credential without messages:send cannot transmit at all.	Human approval appears as a recommended security level in the Agent Email Inbox skill, not as an API resource with its own events.
Free allowance Resend wins this row outright.	One live inbox and 100 email units a month per verified owner identity.	3,000 emails a month, 100 a day, 3 verified domains, 30-day data retention, inbound included.
Attestations Resend wins this row outright.	None. Scoped grants, an approval gate, an audit trail and idempotency are shipped controls, not certificates.	Security page states a SOC 2 Type II audit by Vanta and Advantage Partners, GDPR handling, TLS 1.3 in transit, encryption at rest, and third-party penetration testing at least annually.

Choose Resend if

You send transactional mail at real volume and want deliverability engineering, a dedicated IP add-on and a domain ceiling in the thousands.
Procurement wants a SOC 2 Type II report and a documented penetration testing cadence before the contract is signed.
You need a verified sending domain of your own today, which Resend gives you on the free plan and this product keeps behind a plan that cannot be bought yet.
Your agent only ever sends and never reads, so a sending_access key pinned to one domain already is the whole security model.
You want templates, broadcasts, contacts and automations living in the same account as the agent's mail.

Choose Email for Agents if

A read-and-draft session must not contain a send tool at all, rather than contain one the model is instructed not to call.
Outbound mail needs human sign-off as an API resource, with approval.requested and approval.rejected on the event stream to build on.
You want to ask for one agent's threads directly instead of paging a team-wide received list and filtering by recipient in your own code.
You run several agents and want each credential pinned to specific inbox ids with scopes narrower than full access.
You need the whole inbound loop rehearsed against a non-routable test inbox that cannot reach a real recipient.

What the “Email for agents” headline actually ships

Resend’s agents page leads with the headline “Email for agents” and the subline “Give your agents the tools they need to send and receive email. MCP, CLI, SDKs, REST. No matter the interface, all you need is an API key.” Read the last clause literally, because it is the architecture rather than the marketing. In Resend the unit of identity is the team, and the key is the thing that proves you are it. Here the unit of identity is the inbox, and the credential is a grant over some subset of inboxes held by a human who can be de-provisioned.

Everything below follows from that one difference. It is not a quality gap. Resend built the best-liked transactional sending API of the last five years and the receiving side they shipped on top of it is real, stored and queryable, not a webhook you have to catch and persist yourself.

Where the inbound mail lives, and who it belongs to

Resend’s receiving product gives every account a <id>.resend.app subdomain that accepts mail at any username, or you point an MX record at them from a domain you verify. Inbound is then available three ways: the email.received webhook, the dashboard, and a Receiving API. That API matters, and a lot of comparison pages get it wrong: received mail is not fire-and-forget. GET /emails/receiving returns a stored list, and there are companion endpoints for the body and for attachments.

The constraint is what the list is a list of. It is every email received by the team, paginated with limit, after and before, capped at 100 per page. There is no recipient filter and the list objects carry no conversation identifier. So if you run three agents at billing@, support@ and recruiting@ on the same <id>.resend.app subdomain, every one of them reads from the same stream and you reconstruct ownership in your own code, on every poll, forever. Resend’s own OpenClaw guide is candid about where that leads: it suggests creating a separate team for the agent if you want to sandbox it. Creating a whole tenant to get one boundary is a reasonable workaround and it is also the clearest evidence that the boundary is not in the data model.

On this side the inbox is the addressable object. Threads hang off an inbox and messages hang off a thread, so “what has this agent been talking about” is a request rather than a reduction you write. That is a smaller product with a narrower job, and on the axis of raw sending it is not close.

Two API-key permissions versus thirty-two scopes

Resend’s create-API-key reference lists exactly two values for permission: full_access, described as “Can create, delete, get, and update any resource”, and sending_access, “Can only send emails”. A domain_id can restrict a key, and the reference is explicit that this restriction is only used when the permission is sending_access.

Work through what that means for a reading agent. The moment an agent needs to list received mail, sending_access is insufficient, so the key becomes full_access, and full_access can also create domains, mint further API keys, edit contacts and delete resources. There is no documented middle setting. The blast radius of a prompt injection that reaches a tool call is therefore the whole account, not the mailbox.

The comparison is thirty-two named scopes, with messages:read and drafts:write separable from messages:send, and a key restricted to specific inbox_ids. Two enforcement rules do more work than the scope count. A credential cannot exceed its creator, so requesting a scope your own role lacks fails at creation with permission_denied rather than at use time. And authority is re-read per request against current state, intersected with the grant of the human who authorised it, so removing that person’s project assignment narrows every key they minted on the next call. The permission model for agent email goes through the full list.

The tool surface an agent can actually see

Resend hosts a remote MCP server at mcp.resend.com/mcp that authenticates by OAuth browser login or, for headless clients, an API key as a bearer token, and publishes the same server as a local stdio package. The catalogue is wide: emails, received emails, templates, contacts, broadcasts, automations, domains, API keys, webhooks, request logs. Inboxes, which adds threads, drafts, labels and replies, is documented as beta, remote-server-only, and gated behind contacting them for access.

Nothing in that documentation describes filtering the tool list by permission. The surface an agent sees is the surface the server has. Guardrails then live in the prompt and in the key, which is exactly the arrangement the Agent Email Inbox skill addresses with a five-level ladder of advice ending in requiring human approval for untrusted senders. That advice is good. It is advice.

Here visibleTools() filters tools/list by the connection grant and tools/call re-checks the same predicate, so a grant holding inboxes:read, threads:read, messages:read and drafts:write produces a session where send_message is not in the catalogue at all. An injected instruction cannot talk a model into calling a tool that was never enumerated. create_draft goes further and strips messages:send from the acting principal for the duration of the call, so a draft cannot become a transmission by argument shape. An API key is rejected at the MCP endpoint by design, with the error “Only connection grants may invoke MCP tools”, which removes the headless-bearer-token path Resend offers. That is a real ergonomic cost, and it is the price of the boundary. The reasoning is in the MCP tool surface as a permission boundary, and the runtime controls are on the controls page.

Threading, and the header work that falls to you

Resend documents replying in the same thread as a header exercise. Set In-Reply-To to the message_id of the received email, append earlier ids to References when you reply more than once, and start the subject with Re: so clients group it. That is correct RFC behaviour and it is a genuinely honest piece of documentation, but it is state your application owns. An agent that forgets one References entry forks the conversation in the recipient’s client, and the failure is invisible from your side because your send succeeded. Threading for agents covers why this breaks in practice and what the reply-by-message-id alternative buys.

The approval story diverges the same way. Here a held send is an API resource, not a rung on a ladder of advice: it writes an approvals row in state pending that expires after seven days, emits approval.requested, and emits approval.rejected when a reviewer refuses. The decision binds to a SHA-256 digest of the canonical payload stored on both the approval and the draft version, so a send that no longer matches what the reviewer read is refused with version_conflict, and the grant of the principal that asked is re-read before anything leaves — revoke its key while the draft waits and approving fails. Events are pollable or delivered to a signed webhook, documented under events and webhooks, and the design rationale is in human approval for agent email.

What Resend does better, without qualification

Deliverability and developer experience are theirs. The free plan carries 3,000 emails a month at 100 a day across 3 verified domains with 30-day retention, and inbound is included in it. Free here is one live inbox and 100 email units a month. Paid tiers run from $20 a month for 50,000 emails to $1,150 for 2.5 million, with per-thousand overage that falls as volume rises, a $30 dedicated IP add-on and a domains add-on. Accounts start at 10 requests per second and must hold bounces under 4% and spam complaints under 0.08%, which is a vendor that actively polices its own sending reputation rather than one that lets you burn it.

Their security page states a SOC 2 Type II audit completed by Vanta and Advantage Partners, GDPR handling, TLS 1.3 in transit, encryption at rest, backups retained 30 days, and third-party penetration testing at least annually. Email for Agents holds no certification of any kind, and the honest framing of that gap is set out in evaluating agent email security without certificates. If your buyer needs a report, they need Resend.

When Resend for AI agents is the right call

The recommendation flips on one question: does the agent’s authority need to be narrower than the account’s? If the answer is no, because the agent only sends notifications, or because one engineer runs one agent and owns the key, the extra structure here buys nothing and Resend’s quota, domains and reputation win on every axis that remains.

The answer becomes yes at the point where a model reads mail from outside your company and can also act. Then the difference is whether the tool was absent from the session or merely discouraged, whether the mail an agent can read is its own inbox or the team’s stream, and whether sign-off is a record the system enforces or a paragraph in a prompt. Those are the three things worth paying an ergonomic cost for, and if none of them describe your workload, keep the key and keep sending. Rehearsing the loop first is cheap: a test inbox that cannot reach a real recipient will tell you which side of the line you are on before you commit a domain to either.

Sources

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