Email infrastructure for Mastra agents

Mastra gives you the primitives to build agent workflows. MultiMail adds the email delivery controls those workflows need — including graduated oversight when agents send customer-facing messages.


Mastra is a TypeScript framework that treats agents, tools, workflows, and memory as first-class application primitives. It's designed to make production AI systems feel like ordinary application code — typed, testable, and deployable alongside your existing stack.

Email is a natural fit for Mastra workflows: outreach sequences, notification pipelines, customer support drafts, and approval chains all involve sending or reading messages on behalf of a user or product. But Mastra itself doesn't provide email infrastructure — it expects you to wire in the services your workflow needs.

MultiMail fills that gap. You expose the MultiMail REST API as Mastra tools, and your agents call `send_email`, `check_inbox`, `read_email`, or `decide_email` the same way they call any other tool. If the workflow touches customer-facing messages, you configure oversight modes so humans approve sends before they leave.

Built for Mastra developers

Oversight built for autonomous workflows

Mastra workflows can run without a human in the loop. When those workflows draft emails, MultiMail's `gated_send` mode routes sends to an approval queue before delivery. Your workflow continues; the message waits. When the human approves via the MultiMail dashboard or API, the send completes and a webhook fires back to your workflow.

Real mailboxes, not SMTP relay

MultiMail provisions actual mailboxes — your own domain or `@multimail.dev`. Inbound email arrives as structured JSON via webhook, so your Mastra agent can call `check_inbox` or receive push events without parsing raw MIME. Threads, metadata, and attachment references are all first-class fields.

Tool-shaped API

Every MultiMail operation maps cleanly to a Mastra tool: `send_email`, `reply_email`, `read_email`, `get_thread`, `set_tags`, `search_contacts`. Each takes a JSON input and returns a JSON result, which is exactly what Mastra's tool executor expects. No adapters, no glue layers.

Graduated trust as workflow state

You can set oversight mode per mailbox or per API call. Start a new agent workflow in `gated_all` mode — every action requires approval — then promote to `gated_send` or `monitored` as confidence grows. The mode is a parameter you control in code, not a global setting you change in a dashboard.

Formally verified security model

MultiMail's authorization and oversight models are proven correct in Lean 4. That means the invariants you rely on — an agent cannot send without approval in `gated_send` mode, a `read_only` agent cannot call `send_email` — are machine-checked, not just documented.


Try it with your agent

No code, no dashboard. Paste this to your AI agent — it connects MultiMail, creates an inbox, and builds the flow for you.

1. Get MultiMail ready: read https://multimail.dev/llms.txt, use the MCP server configuration it publishes, connect that server to this project, create a free inbox for the Mastra agent, and set up a verified sending domain for outbound mail. 2. Wire it into Mastra using Mastra’s real MCP integration: install and use @mastra/mcp, create an MCPClient for MultiMail, then make the MultiMail tools available to the Agent through await client.listTools() in the Agent tools field. If this app needs per-user credentials, use await client.listToolsets() and pass the toolsets into the Agent generate or stream call instead. 3. Give the agent email capabilities through those MCP tools only: it must be able to check its inbox, draft a reply for review, and compose, send, or schedule email. Do not add a custom MultiMail API client, webhook, endpoint, or invented helper. 4. Send one test email from the verified sender to my developer address. The message should identify the Mastra agent, confirm that inbox access and outbound sending are connected, and ask me to reply so the agent can verify the inbox-check and draft-reply path. 5. Keep the inbox in gated_send before testing and in the final configuration, so every outbound email requires developer review before it sends. Do not switch to monitored or autonomous unless I explicitly ask for that later.

Step by step

1

Create a MultiMail account and get an API key

Sign up at multimail.dev. Your API key starts with `mm_live_` for production or `mm_test_` for sandbox. Set it as an environment variable in your Mastra project.

2

Install Mastra and scaffold your project

Mastra has a CLI that generates a project with agents, tools, and workflows pre-wired. No separate SDK install is needed for MultiMail — you call the REST API directly from your tools.

3

Define MultiMail tools

Create a `src/tools/multimail.ts` file that wraps the MultiMail REST endpoints as Mastra tools with Zod schemas. Export the tools you need: `sendEmailTool`, `checkInboxTool`, `readEmailTool`, `decideEmailTool`.

4

Attach tools to an agent

Import your MultiMail tools into a Mastra Agent definition. The agent's system prompt should explain what oversight mode to expect so it handles `pending_scan` responses (held for approval) correctly.

5

Configure a webhook for inbound mail

In the MultiMail dashboard, set your inbound webhook URL to your server's `/webhooks/multimail/inbound` endpoint. MultiMail will POST structured JSON for each received message, which you can use to trigger Mastra workflow runs.


Common questions

Does MultiMail have an official Mastra integration package?
No. You define MultiMail as Mastra tools by wrapping the REST API with `createTool` and Zod schemas. This is the idiomatic Mastra pattern for external services — it keeps the integration in your codebase and gives you full control over which endpoints you expose to the agent.
How does `gated_send` mode interact with a Mastra workflow?
When `send_email` is called on a mailbox in `gated_send` mode, MultiMail returns a 202 with `{ id: '...', status: 'pending_scan', ... }` immediately and holds the message for approval. Your workflow receives that response and can poll `GET /v1/oversight/pending` until the message is no longer queued, or suspend the run until the approval arrives. The message does not leave MultiMail until a human approves it in the dashboard or via `POST /v1/oversight/decide` with `{ email_id, action: 'approve' }`.
Can I use MultiMail's MCP server with Mastra instead of the REST API?
Mastra is a tool-calling framework that integrates with MCP servers via its tool system. MultiMail's MCP server exposes 51 tools including `send_email`, `check_inbox`, and `decide_email`. If your Mastra setup already uses MCP tool discovery, you can connect to `https://mcp.multimail.dev/mcp` and get all MultiMail capabilities without writing individual tool wrappers.
How do I handle inbound email in a Mastra workflow?
Configure a MultiMail webhook pointing to your server. When MultiMail receives mail for your mailbox, it POSTs a JSON event with `type: 'email.received'` and the full message in `data`. Your server handler calls `mastra.getWorkflow('...').createRun()` to start a workflow run with the email payload as input. This is the standard pattern for event-triggered Mastra workflows.
Do I need to provision mailboxes through the MultiMail dashboard?
You can provision mailboxes programmatically via `POST https://api.multimail.dev/v1/mailboxes` (admin scope), with a body like `{ "address_local": "agent", "oversight_mode": "gated_send" }`. This is useful if your Mastra workflow needs to create a per-tenant or per-session mailbox at runtime. The call returns the mailbox and lets you set the oversight mode at creation time.
What oversight mode should I use during development?
Use `gated_all` during development so every action — reads, sends, replies — requires explicit approval. This gives you a complete audit trail while you're still debugging tool behavior. Promote to `gated_send` when reads are reliable, and to `monitored` only when you've validated the full workflow in staging with real message content.

Explore more

The only agent email with a verifiable sender

Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.