Send Your First Agent Email in 3 Minutes

MultiMail gives your AI agent a direct path from API key to delivered email — with gated approval built in so production sends go through human review by default.


Why this matters

Adding email to an agent workflow should take an afternoon, but the first integration typically stalls in three places: figuring out the correct authentication headers, getting the payload shape right, and deciding what happens when the agent sends something the human didn't expect. Teams often discover these gaps in production, after an agent has already sent an email that shouldn't have gone out.


How MultiMail solves this

MultiMail provides a REST API and an MCP server that share the same authentication model and mailbox primitives — call the REST endpoints directly with any HTTP client (curl, requests, httpx), or invoke the tools through an MCP-compatible client. The default oversight mode for new integrations is gated_send: your agent can read and draft emails autonomously, but sends are held in a queue until a human approves them. This means you can ship a first agent email integration without writing your own approval logic or review UI.

1

Create an API key

Generate a live or test API key from the MultiMail dashboard. Test keys (mm_test_...) route all sends to a sandbox and never reach real recipients, so you can exercise the full authentication, payload, and approval flow safely before going to production.

2

Connect your agent

Set the Bearer token in your agent's environment. For REST callers, add the Authorization header to every request. For MCP clients such as Claude Desktop, Cursor, or Windsurf, point the server config at https://mcp.multimail.dev/mcp with the same token.

3

Draft and queue the email

Call send_email with your mailbox_id (the sending mailbox you own on MultiMail), recipient, subject, and markdown body. Under gated_send, the API returns an id and status: pending_scan — the email is queued, not yet delivered.

4

Approve the send

MultiMail notifies the reviewer via webhook or email. The reviewer calls decide_email with action: approve to release the message, or action: reject to discard it. Only after approval does MultiMail hand the message off for delivery.

5

Confirm delivery

After approval, MultiMail delivers the email and emits a message.delivered webhook event. Your agent can subscribe to the webhook or poll read_email with the email's id to confirm delivery before proceeding to the next step in the workflow.


Try it with your agent

Pick your platform, copy the prompt, and paste it to your AI agent — it sets up MultiMail and builds the whole flow. Nothing to fill in.

1. Get MultiMail ready: read https://multimail.dev/llms.txt, connect the MCP server, create a free inbox, and set up a verified sender. 2. In Zapier, create a Zap that starts from the real event your agent workflow already uses, such as Webhooks by Zapier Catch Hook, Schedule by Zapier, a new HubSpot contact, a new Salesforce lead, or a new row in Google Sheets. 3. Add the AI step you already use in Zapier to turn the trigger data into a recipient, subject, send timing, and email draft; include the source record URL and the reason for sending in the draft notes so review is easy. 4. Use MultiMail to compose or schedule the message from the verified sender, keep the workflow in gated_send mode, and route every send for human approval before delivery. 5. Ask me only for the Zapier account connection, the source app credentials if they are not already connected, and the approved brand voice, sender name, and sending domain when it is time to go live.

What you get

Approval workflow included, no code required

gated_send holds every outbound message in a queue until a human approves it. You get the full review workflow — notification, approve/reject UI, and state tracking — without building any of it yourself.

Test keys that never reach real inboxes

mm_test_ keys exercise the complete send path — authentication, payload validation, approval flow, and delivery webhooks — against a sandbox. You can iterate on your agent without risking accidental sends to real users.

One auth model across REST and MCP

The same Bearer token works whether your agent calls the REST API directly or runs through an MCP-compatible client. No separate credentials or configuration per integration path.

Idempotent sends protect against duplicate delivery

Pass an idempotency_key in the send_email request. If your agent retries after a timeout or network failure, MultiMail returns the original id with status: already_sent and idempotent: true, without creating a second send — no duplicate emails reach recipients.


Recommended oversight mode

Recommended
gated_send
gated_send is the right default for a first integration. Your agent can read the inbox and draft messages autonomously, which keeps the workflow moving, but every outbound send goes through a human approval step before delivery. This catches misconfigured recipients, unexpected content, or runaway retry loops before they reach real inboxes. Once you've confirmed the agent sends correctly across a representative sample of production messages, you can migrate specific mailboxes to monitored or autonomous for the paths you trust.

Common questions

What is the difference between a test key and a live key?
Test keys (mm_test_...) route all sends to a sandbox. Emails never leave MultiMail's infrastructure, so you can test the full send and approval flow without reaching real recipients. Live keys (mm_live_...) deliver to actual email addresses. Use test keys during development and switch to live keys when you're ready for production traffic.
How does my agent know whether a send was approved or rejected?
Under gated_send, send_email returns immediately with status: pending_scan and an id. You can poll read_email with that ID to check for a status change, or register a webhook endpoint to receive an oversight.approved or oversight.rejected event the moment a human makes a decision.
Can I skip the approval step for certain emails?
Yes. You can set the oversight mode for a mailbox to monitored or autonomous if you want the agent to send without waiting for approval. This is appropriate for low-risk, high-volume paths where you've already validated the agent's behavior — for example, transactional confirmations where content is templated and recipients are known.
What happens if the agent tries to send to an invalid address?
MultiMail validates the to address format before queuing the message. If the format is invalid, send_email returns a 400 error immediately. If the address is syntactically valid but the recipient's mail server rejects delivery, MultiMail emits a message.bounced webhook event containing the rejection reason and SMTP status code.
Do I need a custom domain to start sending?
No. MultiMail provides @multimail.dev mailboxes you can use immediately after creating an API key via create_mailbox. For production use, you can verify your own domain (e.g., [email protected]) by adding DNS records in the dashboard. Custom domains improve deliverability and let recipients see your brand in the from address.
How do I list messages waiting for approval?
Call list_pending to retrieve all messages currently queued for human review. The response includes message IDs, recipients, subjects, and queue timestamps. You can pass these IDs to decide_email to approve or reject messages programmatically, or surface them in your own review UI.

Explore more use cases

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.