The Email API Built for AI Agents

Generic email APIs weren't designed for agents. MultiMail provides cryptographically signed agent identity, graduated oversight controls, and compliance built in — not bolted on.


Why this matters

When an AI agent sends email through a generic SMTP relay or transactional API, three things are missing: recipients have no way to verify the message came from an agent rather than a human, your organization has no mechanism to review or gate what the agent sends, and you have no audit trail that satisfies EU AI Act Article 50 disclosure requirements. These aren't edge cases — they're the default failure mode when you wire an LLM to a generic email API.


How MultiMail solves this

MultiMail is a purpose-built email API for AI agents. Every sent message carries a cryptographic signature identifying the sending agent. Oversight mode controls whether sends go immediately or wait for human approval. The full audit trail — what the agent tried to send, who approved it, and when — is stored automatically. Access via the REST API at https://api.multimail.dev — call it directly with any HTTP client such as Python's requests — or the 51-tool MCP server that works directly inside Claude Desktop, Cursor, and Windsurf.

1

Create a mailbox and get your API key

POST to /v1/mailboxes to provision a mailbox on your domain or at @multimail.dev. Your API key (mm_live_... for production, mm_test_... for sandbox testing) authenticates every request. Each mailbox signs its outbound mail with an X-MultiMail-Identity claim — a signed payload carrying the operator and mailbox identity — so recipients can verify the message without trusting the From header.

2

Configure an oversight mode

Set oversight_mode on the mailbox. gated_send (the default) lets your agent read autonomously but holds outbound messages in a pending queue until a human approves. gated_all gates reads too. monitored lets the agent act freely while notifying a human. autonomous is available once trust is established. The mode is enforced server-side — the agent cannot override it.

3

Send and receive through the API

POST to /v1/mailboxes/{mailbox_id}/send to send. GET /v1/mailboxes/{mailbox_id}/emails to check incoming messages. Under gated_send, a send call returns immediately with status pending_scan and an id. The message sits in the approval queue until a human approves it via the dashboard or POST /v1/oversight/decide.

4

Handle approvals with webhooks

Register a webhook endpoint to receive real-time events: oversight.approved, oversight.rejected, message.delivered, message.received. Your agent subscribes to these events and continues its workflow once a human approves a draft — no polling required. Webhook payloads are signed with HMAC-SHA256 for verification.

5

Audit and compliance are automatic

Every send attempt, approval decision, and delivery event is written to an immutable audit trail. CAN-SPAM required headers are validated before delivery — missing unsubscribe links or physical addresses are rejected outright. EU AI Act Article 50 disclosure — the X-AI-Generated header plus a human-readable footer — is added automatically to every outbound message. It is gateway-enforced and cannot be disabled.


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 my OpenAI agent, detect outbound-email intent through tool calling in the Responses API: when the model requests a send, draft, follow-up, notification, or escalation email, route that tool call to this workflow. 3. Build the email from the conversation state: identify the recipient, purpose, urgency, relevant account or ticket context, and whether this is a first touch, reply, reminder, or final notice. 4. Compose the message through MultiMail with clear agent disclosure, brand voice, recipient-specific context, and a concise next step; schedule follow-ups only when the user has not replied after the chosen cadence. 5. Run every send in MultiMail gated_send mode, keep the audit trail attached to the OpenAI run or thread record, and ask me only for OpenAI credentials and final brand/sender details before going live.

What you get

Cryptographic agent identity on every message

Every email sent through MultiMail carries an X-MultiMail-Identity claim — an ECDSA P-256 signed payload covering the oversight mode, capabilities, the AI-generated flag, and the operator plus mailbox identity. Recipients verify it at https://multimail.dev/verify without trusting the From header. Combined with the gateway-enforced X-AI-Generated header, this satisfies EU AI Act Article 50 disclosure without any additional instrumentation.

Oversight that scales with trust

Start with gated_send — your agent reads freely but all outbound messages hold for human review. Promote to monitored once you've validated the agent's judgment on your specific use case, then to autonomous when full trust is established. The mode is enforced server-side and cannot be bypassed by the agent.

Built-in CAN-SPAM and EU AI Act compliance

Required CAN-SPAM headers — unsubscribe mechanism, physical address, honest From — are validated before delivery. Missing fields are rejected, not silently dropped. EU AI Act disclosure — the X-AI-Generated header and a human-readable footer — is appended automatically to every agent-originated message. It is gateway-enforced and locked on per mailbox.

51-tool MCP server for LLM-native access

Beyond REST, MultiMail ships an MCP server with 51 tools covering the full email lifecycle: send_email, reply_email, check_inbox, read_email, get_thread, set_tags, decide_email, add_contact, and more. Install once via npx @multimail/mcp-server and any MCP-compatible client gets full email access.

Immutable audit trail on every action

Every send attempt, approval decision, rejection, and delivery event is logged to an append-only audit trail. You can reconstruct exactly what an agent tried to send, who reviewed it, what they decided, and when — which matters when an enterprise customer or regulator asks.

Sandbox testing without a separate environment

mm_test_... keys validate the full request contract — auth, required fields, compliance checks — but discard the message before delivery. Switch to mm_live_... for real delivery. Both key types hit the same base URL. No separate test environment configuration, no mock servers, no delivery side effects during development.


Recommended oversight mode

Recommended
gated_send
For a general-purpose email API integration, gated_send is the correct default. Your agent needs to read incoming email without friction to be useful, but outbound sends warrant human review until you've verified the agent's judgment on your specific use case and data. The cost of an agent sending an incorrect, off-brand, or compliance-violating email is high; the cost of a human approving a pre-written draft is low. Promote to monitored once you have statistical confidence in output quality across a representative sample of sends.

Common questions

How is MultiMail different from a generic transactional email API?
Generic transactional email APIs are built for humans configuring transactional templates. They have no concept of an AI agent as the sender, no oversight controls, no pending queues for human review, and no agent identity verification. MultiMail is built specifically for the case where an LLM composes and sends email autonomously — with the identity, oversight, compliance, and audit machinery that requires.
What does 'formally verified security' mean in practice?
MultiMail's oversight model, identity verification logic, and authorization rules are specified and proven correct in Lean 4, a proof assistant. The proofs are machine-checked: if the implementation matches the specification, the security properties hold by construction. The Lean proofs live in the repo at Proofs/ and run in CI on every push. This is not a marketing claim — the proofs are publicly auditable.
What happens when an agent calls send_email under gated_send oversight?
The call returns HTTP 202 with status: pending_scan and an id. Nothing is delivered yet. A webhook fires to your registered endpoint with type oversight.pending. A human reviews the draft in the dashboard or approves it via POST /v1/oversight/decide with body { "email_id": "...", "action": "approve" }. On approval, delivery proceeds and an oversight.approved webhook fires. On rejection, an oversight.rejected event fires with an optional rejection_reason.
Can I use MultiMail with LangChain, CrewAI, or AutoGen?
Yes. The REST API works with any HTTP client, so you can call it directly from a LangChain, CrewAI, AutoGen, or Semantic Kernel tool. The MCP server works with any MCP-compatible client: Claude Desktop, Cursor, Windsurf, and others. There is no lock-in to a specific orchestration framework.
How does EU AI Act compliance work exactly?
EU AI Act Article 50 requires that recipients be notified when they are interacting with an AI system. MultiMail automatically marks every agent-originated message with the X-AI-Generated header and a human-readable disclosure footer — this is enforced at the send gateway per mailbox and cannot be disabled. The disclosure format follows guidance published by the European AI Office. You do not need to modify your message body or add custom headers.
Do mm_test_... API keys actually send email?
No. Keys prefixed mm_test_... run the full request through authentication, field validation, and compliance checks, then discard the message before delivery. This lets you build and test your integration without sending real email. Switch to mm_live_... when you are ready for live delivery. Both key types use the same base URL: https://api.multimail.dev.
What is the difference between the REST API and the MCP server?
The REST API is for programmatic integration in code you write — you call https://api.multimail.dev endpoints directly from your agent's backend. The MCP server exposes the same capabilities as 51 named tools that an LLM can invoke natively inside an MCP-compatible client without writing any integration code. Use the REST API when you are building the agent yourself; use the MCP server when you want an existing client like Claude Desktop to have email access.

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.