Email infrastructure for agents that talk to other agents

Each agent gets a mailbox whose outbound mail carries a signed X-MultiMail-Identity claim. Any receiving agent can verify identity against the public key at /.well-known/multimail-signing-key — no shared secrets, no central registry.


Why this matters

Multi-agent systems increasingly operate across organizational and framework boundaries. When Agent A at company X needs to notify Agent B at company Y, most inter-agent protocols fail: they require a shared runtime, a shared message bus, or trust that collapses at the org boundary. Email is the only federated, authenticated messaging protocol that already works across every domain. But standard email has no mechanism for agents to assert or verify identity. Without that, a receiving agent cannot distinguish a legitimate pipeline notification from a spoofed instruction or prompt injection delivered via email. The EU AI Act requires traceable, auditable interactions between AI systems in high-risk categories. Without signed identity and a tamper-evident audit trail, agent-to-agent communication is unverifiable — a compliance liability as multi-agent deployments scale.


How MultiMail solves this

MultiMail gives each agent its own mailbox. Every outbound message automatically carries an X-MultiMail-Identity header — an ECDSA P-256 signed claim (a base64url payload plus a base64url signature) covering the operator and mailbox identity, the oversight mode, the agent's capabilities, and the AI-generated flag. Because the claim is signed, tampering with any field is detectable without trusting the From header. The /.well-known/multimail-signing-key endpoint publishes MultiMail's signing public key, so any receiving agent — regardless of framework or organization — can verify the sender's identity claim with a single HTTP GET and no pre-shared secret. A recipient can also paste the header into https://multimail.dev/verify#<header-value> to check it in a browser. Monitored oversight mode is the default recommendation for agent-to-agent flows: agents send without blocking, human account owners receive notifications, and every exchange is logged to the immutable audit trail. Tighten to gated_send for pipelines that trigger irreversible downstream actions.

1

Provision a mailbox for each agent

Create one mailbox per agent via POST /v1/mailboxes. Use your own domain ([email protected]) or a multimail.dev subdomain. The MultiMail signing public key is published at /.well-known/multimail-signing-key and is resolvable by any HTTP client, so receivers can verify the identity claim on this agent's mail without any pre-shared secret.

2

Send with automatic identity signing

POST to /v1/mailboxes/{mailbox_id}/send from the sending agent's mailbox. MultiMail attaches the signed X-MultiMail-Identity header before delivery. No signing code is required in the agent — the gateway builds and signs the claim. The operator, mailbox, oversight mode, capabilities, and issued-at timestamp all live inside that one signed claim.

3

Receiving agent verifies the sender

The receiving agent fetches the MultiMail public key from /.well-known/multimail-signing-key and verifies the X-MultiMail-Identity claim's ECDSA P-256 signature, reading the operator and mailbox from inside the signed payload rather than trusting the From header. Messages whose claim fails verification are rejected before processing, blocking spoofed instructions and email-delivered prompt injection.

4

Process and reply with attribution

After verification, the receiving agent reads the full message via GET /v1/mailboxes/{mailbox_id}/emails/{email_id} and acts on it. Replies via POST /v1/mailboxes/{mailbox_id}/reply/{email_id} carry the receiving agent's own signed X-MultiMail-Identity claim, creating a bidirectional verified conversation. Both sides of the exchange appear in the audit trail with full identity metadata.

5

Human oversight via notifications

In monitored mode, the account owner receives a notification for every send without blocking agent throughput. The full audit trail — sender, recipient, timestamp, signature status — is queryable at any time and satisfies EU AI Act Article 13 traceability requirements for high-risk deployments.


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. Read https://multimail.dev/llms.txt, connect the MCP server, create a free inbox, and set up a verified sender for the agent mailbox. 2. In Zapier, create a Zap that starts with Webhooks by Zapier using the Catch Hook trigger, and use that hook as the notification target for Agent A whenever it needs to contact an external agent. 3. Map the incoming webhook fields into a clear agent-to-agent email: receiving agent address, originating agent name, operator organization, event type, required action, confidence, relevant record links, and a concise plain-language summary. 4. Use MultiMail to compose and send the message in monitored oversight mode by default; switch only to gated_send when the email can trigger irreversible downstream actions. 5. Prepare the Zap end to end with test data, but ask me only for the Zapier credentials, receiving agent mailbox list, brand voice, and final go-live approval.

What you get

Federated across organizations

Email works across every domain without a shared runtime, message bus, or pre-negotiated protocol. Any two agents with MultiMail mailboxes can communicate regardless of which framework, cloud, or organization they belong to.

Cryptographic sender attribution

Every message carries an ECDSA P-256 signed X-MultiMail-Identity claim. The /.well-known/multimail-signing-key endpoint lets any receiver verify the sender against one public key — no central directory or pre-shared secret. Spoofed sender addresses and prompt injection via email are detectable before the message reaches your agent's processing logic.

Immutable audit trail

Every send, read, reply, and tag is recorded with sender, recipient, timestamp, and signature verification status. The audit log is tamper-evident and queryable — sufficient for EU AI Act Article 13 transparency requirements in high-risk AI system deployments.

Framework agnostic

Use the REST API, Python SDK, or MCP server tools from any agent framework: LangChain, CrewAI, AutoGen, Semantic Kernel, or a raw HTTP client. The receiving agent does not need to use MultiMail — it only needs to understand email and HTTP to verify signatures.

Graduated oversight per mailbox

Oversight mode is set per mailbox, so different agents in the same pipeline can have different autonomy levels. A notification agent can run in autonomous mode while a contract-sending agent runs in gated_send — all within the same account.


Recommended oversight mode

Recommended
monitored
Agent-to-agent email flows are typically high-volume and time-sensitive. Blocking every send for human approval would negate the value of automation. Monitored mode lets agents communicate at full speed while giving human account owners complete visibility into every exchange. The cryptographic identity headers provide a separate trust layer: the audit trail records not just what was sent, but whether the claimed sender was cryptographically verified. Switch to gated_send for pipelines that trigger irreversible downstream actions — financial transactions, production deployments, or data deletion — where human confirmation provides meaningful protection that outweighs the latency cost.

Common questions

Does the receiving agent need to use MultiMail?
No. The X-MultiMail-Identity header travels as a standard email header. Any agent or service that receives email can verify it by fetching MultiMail's public key from /.well-known/multimail-signing-key — a plain HTTP GET that returns a JWK — and checking the claim's ECDSA P-256 signature. The receiving side only needs a MultiMail mailbox if it also wants to send signed replies with its own verified identity.
What signing algorithm does MultiMail use?
ECDSA on the P-256 curve (ES256). MultiMail signs each outbound message's X-MultiMail-Identity claim — a base64url payload plus a base64url signature — covering the operator and mailbox identity, oversight mode, capabilities, AI-generated flag, and an issued-at timestamp inside the claim. The signing public key is published as a JWK at /.well-known/multimail-signing-key. There is one service key, not a per-mailbox key, so a receiver fetches it once and can verify every sender.
Can I use this from a non-Python agent?
Yes. Use the REST API directly: POST to https://api.multimail.dev/v1/mailboxes/{mailbox_id}/send with an Authorization: Bearer $MULTIMAIL_API_KEY header and a JSON body containing to, subject, and markdown fields (the sending mailbox is the {mailbox_id} in the path — there is no 'from' field). The 202 response returns the message id and status; MultiMail attaches the signed X-MultiMail-Identity header at delivery. Any HTTP client in any language works.
What do EU AI Act requirements mean for agent-to-agent communication?
For high-risk AI systems under Annex III, Article 13 requires transparency and traceability sufficient to reconstruct decisions. MultiMail's audit trail covers sender, recipient, timestamp, and signature verification status for every exchange. You are responsible for determining whether your deployment falls under high-risk classification and for retaining audit logs for the required period — typically the system's operational lifetime plus 10 years for high-risk systems under Article 18.
Is email fast enough for agent coordination?
MultiMail delivers messages in 1–3 seconds end-to-end. That is sufficient for asynchronous pipeline notifications, handoff signals, approval requests, and status updates. For sub-second coordination — streaming tool calls, real-time bidding, tight feedback loops — email is the wrong transport. Use a message queue or direct API calls for latency-sensitive paths, and MultiMail for durable, auditable messages where delivery confirmation and identity attribution matter.
How does key rotation work without breaking receiving agents?
The /.well-known/multimail-signing-key endpoint always returns MultiMail's current signing public key as a JWK. If a receiving agent caches the key, it should set a cache TTL of no more than 24 hours and re-fetch on any verification failure — a claim that was valid when signed will verify again once the agent picks up the current key. Because verification reads the operator, mailbox, and issued-at timestamp from inside the signed claim, there is no separate per-message key-version header to track.

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.