Email for Agents
Create an inbox
Sign in Create an inbox

Mailtrap for AI Agents: Agent Inbox vs Test Inbox

9 min read · Reviewed by Email for Agents Engineering · Mailtrap checked

Mailtrap is a mature sending, sandbox and inbound platform, and its Agent Inbox is a real routable mailbox with parsed JSON and threads. Pick it for volume, deliverability and email QA. Pick Email for Agents when a test must never cross a transport and the agent's own authority must be narrower than the account's.

At a glance

Dimension Email for Agents Mailtrap
Agent mailbox An inbox per agent on agents.emailforagents.ai, with threads and messages as REST resources and six MCP tools. Agent Inbox: an inbox created in a folder with a generated @inbound-mailtrap.io address, or a catch-all on your own domain. Parsed JSON, threads, reply and forward endpoints.
Test inbox addressing Non-routable .mail.invalid address with no DNS answer, so nothing can be delivered to it. Test sends use a simulated transport. Routable addresses: the Agent Inbox address, or a per-sandbox @inbox.mailtrap.io address from the Basic sandbox plan up.
How inbound reaches a test Mailtrap's SMTP route exercises real MIME from a real client; ours cannot. POST /projects/{project_id}/test/inbound writes the message straight into the agent's own test inbox. Requires test:simulate and messages:read. A message is sent to a routable Mailtrap address by SMTP, or into a sandbox through the Sandbox send API, then read back through the API.
Outbound in test Same send endpoint, a test project and an efa_test_ key. The transport is simulated and test mail is never charged. Email Sandbox, a fake SMTP server with its own credentials and a separate send endpoint. Hosted Agent Inbox replies are live sends capped at 20 in total.
Email QA tooling Mailtrap wins this row outright. None. No HTML check, spam scoring, device previews or bounce emulation. HTML check, SpamAssassin scoring, blacklist check, bounce emulation, load testing via the Sandbox API, forwarding to real inboxes, device previews as a Business or Enterprise add-on.
MCP Remote at mcp.emailforagents.ai/mcp. OAuth connection grants only, API keys rejected. tools/list is filtered by the grant. Local Node.js server run with npx mcp-mailtrap and a Mailtrap API token. The README documents more than 100 tools, inbound included, and describes no filtering of the tool list.
Free allowance Mailtrap wins this row outright. One live inbox and 100 email units a month per verified owner identity. Three test inboxes. 4,000 emails a month (150 a day) on Email API, inbound included in that quota. Sandbox free tier: 50 test emails, 1 sandbox.
Attestations Mailtrap wins this row outright. None. Scoped grants, an approval gate and an audit trail are shipped controls, not certificates. Plans page lists GDPR, ISO 27001 and SOC 2 Type II coverage on all plans, Free included.

Choose Mailtrap if

  • You want one vendor for transactional sending, bulk sending, marketing campaigns, inbound parsing and email QA, with 4,000 free emails a month that inbound shares.
  • Your tests are about the email itself: HTML client support, SpamAssassin scores, blacklist checks, device previews, bounce emulation or load testing.
  • You need the agent's address on your own domain today. Mailtrap supports custom-domain catch-all inboxes; this product keeps custom domains behind a plan that cannot be bought yet.
  • Procurement asks for SOC 2 Type II and ISO 27001 coverage, which Mailtrap's plans page lists on every tier, Free included. This product holds no certification.
  • You want real MIME from a real sending client to hit your parser, headers and attachments included, rather than a synthetic message written through an API.
  • QA, designers and developers share sandboxes, forward captured mail to real clients, and need seats for dozens of people.

Choose Email for Agents if

  • Your CI must prove the agent's inbound loop with no SMTP hop, no routable address and no chance that a reply reaches a real person.
  • The test message has to land in the agent's own inbox and fire the same message.received event your production consumer handles, flagged simulated.
  • An agent that reads and drafts must get an MCP session in which send_message is not listed, rather than a full tool catalogue behind an API token.
  • Outbound mail needs a held approval as an API resource, with approval.requested and approval.rejected on the event stream.
  • You want test and live separated by the credential itself, so an efa_test_ key cannot reach a live inbox whatever the code does.

Searches for Mailtrap for AI agents usually start from an old mental model: Mailtrap is the fake SMTP server you point staging at, it catches outbound mail, and nothing comes in. That model is out of date. Mailtrap now ships Agent Inbox, a routable hosted mailbox that receives real email, parses it into JSON, groups it into threads and lets the agent reply in one call. It also still ships the sandbox, and a 100-plus tool MCP server that spans both.

So the useful comparison is not “sandbox versus inbox”. Both vendors have an inbox and both have a way to test. This page settles the narrower question that actually decides a CI pipeline: whether a test message must cross a transport, and whose mailbox it lands in. If you want the testing workflow itself rather than the vendor choice, testing agent email without sending walks through it end to end, and the comparisons hub has the other vendors.

What Mailtrap for AI agents ships today

Mailtrap’s agent story is three products, and most pages about it blur them.

Agent Inbox is the inbound product. You create a folder, create an inbox inside it, and get back an address such as demo-inbox-62fedace@inbound-mailtrap.io. Or you pass a domain_id and get a catch-all, *@your-domain.com, after adding their MX record. Messages arrive as parsed JSON with sender, recipients, headers, text, HTML and attachment URLs, and Mailtrap groups replies into threads. A webhook fires inbound.message_received, signed with HMAC-SHA256 in a mailtrap-signature header, retried every five minutes for up to 40 attempts. The docs note that the inbound UI is “coming soon”, so today it is API-first. Inbound is included on every Email API plan, Free included, and shares the sending quota.

Email Sandbox is the testing product. The docs call it “a fake SMTP server that traps all emails sent from your application.” It has its own SMTP credentials at sandbox.smtp.mailtrap.io and its own send endpoint, and it is where the HTML check, spam score, blacklist report, bounce emulator and device previews live. From the Basic sandbox plan up, each sandbox also gets a routable @inbox.mailtrap.io address so you can send mail into it and test parsing. So even the sandbox is not outbound-only.

The MCP server is a Node.js command-line utility launched with npx mcp-mailtrap, authenticated by MAILTRAP_API_TOKEN. Its GitHub README documents 117 tools under “Available Tools”, from send-email and get-sandbox-message-spam-score to list-inbound-threads, reply-to-inbound-message, create-api-token and bulk-update-permissions. Inbound is reachable over MCP.

That is a broad, capable platform. None of what follows argues otherwise.

The distinction that survives: transport and ownership

On Mailtrap, an inbound test message is sent. It goes over SMTP to a routable Mailtrap address, or through the Sandbox send API into a sandbox, and it lands in a Mailtrap inbox that stands in for the agent’s mailbox. Your agent then reads that stand-in, either because it is the production Agent Inbox or because your test harness points it at a sandbox.

Here, a test inbox has a non-routable address on .mail.invalid, a name RFC 6761 reserves so that it can never resolve. Nothing can be delivered to it. Instead, you inject the message through the API into the agent’s own test inbox:

curl -X POST "https://api.emailforagents.ai/v1/projects/$EFA_PROJECT_ID/test/inbound" \
  -H "Authorization: Bearer $EFA_TEST_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inbox_id": "ibx_...",
    "from": {"email": "dana@example.org", "name": "Dana Okafor"},
    "to": [{"email": "billing@example.invalid"}],
    "subject": "Invoice 4471 looks wrong",
    "text": "The October line item appears twice."
  }'

The call requires both test:simulate and messages:read, and it refuses with test_mode_required unless the project and the inbox are both test. It writes a thread, a message and its recipients through the same storage the live path uses, then emits message.received with "environment": "test" and "simulated": true. The agent reads it with the same list_threads and get_message calls it uses in production. There is no second address, no second credential set and no SMTP hop to fail in CI.

Two questions separate the approaches, and they are the whole comparison:

QuestionMailtrapEmail for Agents
Does the test message cross a transport?Yes, SMTP or a send APINo, API write into the inbox
Whose mailbox does it land in?A Mailtrap inbox standing in for itThe agent’s own test inbox
Can a reply from the test reach a person?Depends on which product you usedNo, test sends use a simulated transport
Is real MIME parsed?Yes, on the SMTP routeNo, the message is synthetic

The last row is a real cost on our side and it should be read as one.

Where the agent’s reply goes during a test

This is where the split between Mailtrap’s products starts to matter for agents specifically. An agent does not just receive. It replies, and the reply is the thing you most want to test without consequences.

Agent Inbox’s reply endpoint, POST /api/inbound/inboxes/{inbox_id}/messages/{id}/reply, threads the reply to the original, prefixes Re:, and sends it through the Email API. From a hosted inbox it always sends from the inbox’s generated address. Agent Inbox’s own page says that on a hosted inbox replies “are capped at 20 in total”, and that connecting a custom domain removes the limit. The response returns the UUIDs the Email API assigned, and a 403 is documented for when the inbox’s monthly sending limit is reached. That is a live send. The pages read for this comparison do not document a sandbox mode on the reply endpoint itself.

Mailtrap’s answer is to test replies in the sandbox: the Agent Inbox FAQ says to point the agent’s outgoing replies at Email Sandbox during development. The sandbox catches outbound through a different path: separate SMTP credentials, or the SDK’s sandbox flag with an inbox id, or the sandbox.api.mailtrap.io/api/send/{inbox_id} endpoint. So a full-loop test on Mailtrap means the agent receives on one product and replies on another, and your harness decides which. That is workable, and many teams do exactly that. It is also a place where a misconfigured environment variable produces a real email.

Here the reply goes to the same send endpoint in test as in live. The project’s environment is fixed at creation, the key prefix carries it, and an efa_test_ key resolves only to test projects and inboxes. Sends leave through a simulated transport, and a test inbox cannot reach an internet recipient. The limits are deliberately small: up to 3 active test inboxes per workspace, the last 100 messages retained, up to 10 MB of content, and content expires after 7 days. Test mail is never charged. The CI version of this, asserting received, parsed, threaded and replied, is in testing the inbound loop in CI.

What the simulated path cannot tell you

Say this plainly, because it is where Mailtrap is the better test.

A message written through /test/inbound never passed through a mail client, a relay or a MIME encoder. It has no SPF or DKIM result, no odd charset, no nested multipart, no forwarded attachment with a broken filename. If your agent’s failure mode is “chokes on what Outlook actually sends”, our simulator will not find it and a real message sent to a Mailtrap address will.

The simulator also has a documented gap: every simulated message opens a new thread. The request body has no parent or thread field, so a reply landing on an existing conversation is not something the endpoint can produce. Mailtrap threads real replies because they are real replies.

And there is no email QA here at all. No HTML check, no spam scoring, no device previews, no bounce emulator. If the question is “will this render in Gmail and pass SpamAssassin”, Mailtrap’s sandbox answers it and this product does not try.

The recommendation flips on what you are testing. If it is the agent’s behaviour, which message it acts on, which recipient it picks, whether it retries safely, whether it waits for approval, the simulated path is faster and cannot leak. If it is the email as an artefact, the parser’s robustness or the rendering, send real mail into Mailtrap.

Credentials and the tool surface an agent sees

Mailtrap tokens carry permissions on resources. The MCP README’s create-api-token tool takes resource types account, project, inbox, domain and billing, each at access level 100 (admin) or 10 (viewer), with expiry defaulting to one year. The receiving tutorial notes you need an account-level token to create an inbound inbox. That is a real permission model. What the pages read do not describe is a split inside inbound between reading, drafting and sending, or any filtering of the MCP tool list by what the token allows. The catalogue the README documents includes token creation and permission editing alongside sending.

Here the MCP endpoint accepts only OAuth connection grants; an API key is rejected at /mcp by design. tools/list is filtered by the grant and tools/call re-checks it, so a grant holding inboxes:read, threads:read, messages:read and drafts:write yields a session in which send_message is not present. There are six tools in total, and create_draft cannot transmit mail. A credential cannot request a scope its creator’s role lacks. That fails at creation with permission_denied. The reasoning behind treating the tool list as the boundary is in the MCP tool surface as a permission boundary, and the REST side is covered on the developers page.

Held sends are an API resource too. A send that needs review creates an approval, emits approval.requested, and emits approval.rejected if a reviewer refuses. Mailtrap lists human-in-the-loop review as a use case, routing mail to an agent first and escalating to a person, but none of the pages read describe a held-reply resource or approval events for Agent Inbox replies.

What Mailtrap does better, without qualification

Scale and price. The Email API free plan is 4,000 emails a month at 150 a day, inbound included in the same quota. Paid tiers run from $15 a month for 10,000 emails to $1,250 for 2.5 million, with dedicated IPs and automated warm-up on higher tiers. Free here is one live inbox and 100 email units a month.

Email QA. HTML checks, SpamAssassin scoring, blacklist checks, a bounce emulator, load testing through the Sandbox API, forwarding to real inboxes, device previews across more than 100 client configurations as an add-on on the Business and Enterprise sandbox plans, and the open-source Mailtrap Local for offline capture. Nothing here competes with that.

Teams. Sandboxes and projects are shared across users, with seat counts from 3 on Basic and no seat cap listed on Enterprise, and SDKs in Node.js, PHP, Python, Ruby, Java, Go and .NET.

Domains and attestations. Custom-domain inbound inboxes work today. The plans page lists GDPR, ISO 27001 and SOC 2 Type II coverage and two-factor authentication on every plan, Free included. This product holds no certification, keeps custom domains behind plans that cannot be bought yet, and says so; the honest version of that gap is in evaluating agent email security without certificates.

Choosing between them

Most teams asking about Mailtrap for AI agents need one of two things, and they are different enough that the answer is often both.

If the agent sends mail your company would send anyway, receipts, notifications, replies on your domain, at volume, Mailtrap is the platform, and its sandbox is the right place to check what those emails look like. Agent Inbox gives the agent a real address today, on your domain if you want it.

If the risk you are managing is the agent itself, a model reading mail from strangers and deciding what to do, then the questions change. Can it reach a real person during a test? Is the send tool absent from a session that should only draft? Does sign-off exist as a record the system enforces? That is what this product is built around, and it is narrow on purpose. The fastest way to find out which side you are on is to run the loop: the quickstart gets a test inbox answering the simulate call, and nothing a test project does can reach a real recipient.

Sources

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