Email infrastructure for agents that talk to other agents

Each agent gets a mailbox with an Ed25519 signing key. Any receiving agent can verify identity via /.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 with an Ed25519 signing key pair generated at creation time. Every outbound message automatically carries X-MultiMail-Agent-Id, X-MultiMail-Signature, and X-MultiMail-Timestamp headers. The signature covers the timestamp and message body, making tampering detectable in transit. The /.well-known/multimail-signing-key endpoint publishes each mailbox's public key, so any receiving agent — regardless of framework or organization — can verify the sender's identity with a single HTTP GET and no pre-shared secret. 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

Call create_mailbox once per agent. Each mailbox receives a unique Ed25519 key pair on creation. Use your own domain ([email protected]) or a multimail.dev subdomain. The public key is published immediately to /.well-known/multimail-signing-key and is resolvable by any HTTP client.

2

Send with automatic identity signing

Call send_email with the sending agent's mailbox in the from field. MultiMail attaches X-MultiMail-Agent-Id, X-MultiMail-Signature, and X-MultiMail-Timestamp headers before delivery. No signing code is required in the agent — the API handles it.

3

Receiving agent verifies the sender

The receiving agent fetches the sender's public key from /.well-known/multimail-signing-key?mailbox=<agent-id> and verifies the X-MultiMail-Signature against the timestamp and body. Messages that fail 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 read_email and acts on it. Replies via reply_email carry the receiving agent's own identity headers, creating a bidirectional verified conversation. Both sides of the exchange appear in the audit trail with full signature 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.


Implementation

Agent A sends a signed notification
python
from multimail import MultiMailClient

client = MultiMailClient(api_key="$MULTIMAIL_API_KEY")

response = client.send_email(
    mailbox="[email protected]",
    to="[email protected]",
    subject="Data pipeline completion notification",
    body=(
        "Pipeline run #847 completed successfully.\n"
        "14,329 records processed. 0 errors.\n"
        "Output: s3://acme-data/runs/847/\n\n"
        "Sent by [email protected]"
    ),
    tags=["agent-to-agent", "pipeline-notification"],
)

print(f"Message ID: {response[&"cm">#039;message_id']}")
print(f"Signed: {response[&"cm">#039;signed']}")
print(f"Signature: {response[&"cm">#039;identity_headers']['X-MultiMail-Signature']}")

Send a pipeline completion notification from one agent mailbox to another. MultiMail handles signing automatically — no extra cryptography code required.

Verify sender identity before processing
python
import httpx
import base64
from cryptography.hazmat.primitives.serialization import load_pem_public_key

def verify_multimail_sender(headers: dict, body: str) -> bool:
    agent_id = headers.get("X-MultiMail-Agent-Id")
    signature_b64 = headers.get("X-MultiMail-Signature")
    timestamp = headers.get("X-MultiMail-Timestamp")

    if not all([agent_id, signature_b64, timestamp]):
        return False

    resp = httpx.get(
        "https://api.multimail.dev/.well-known/multimail-signing-key",
        params={"mailbox": agent_id},
        timeout=5,
    )
    resp.raise_for_status()
    public_key = load_pem_public_key(resp.content)

    signed_payload = f"{timestamp}\n{body}".encode()
    signature = base64.b64decode(signature_b64)

    try:
        public_key.verify(signature, signed_payload)
        return True
    except Exception:
        return False


"cm"># In your agent's email handler:
if not verify_multimail_sender(email["headers"], email["body"]):
    raise ValueError(f"Rejected: unverifiable sender for email {email[&"cm">#039;id']}")

Fetch the sender's public key from /.well-known/multimail-signing-key and verify the Ed25519 signature. Reject any message that fails — this is the injection guard.

Agent B reads inbox and replies
python
from multimail import MultiMailClient

client = MultiMailClient(api_key="$MULTIMAIL_API_KEY")

inbox = client.check_inbox(
    mailbox="[email protected]",
    unread_only=True,
)

for message in inbox["emails"]:
    full_email = client.read_email(email_id=message["id"])

    if not verify_multimail_sender(full_email["headers"], full_email["body"]):
        client.tag_email(email_id=message["id"], tags=["rejected-unverified"])
        continue

    result = run_analysis(full_email["body"])

    client.reply_email(
        email_id=message["id"],
        body=(
            f"Analysis complete for pipeline run #847.\n"
            f"Result: {result[&"cm">#039;summary']}\n"
            f"Anomalies detected: {result[&"cm">#039;anomaly_count']}\n\n"
            f"Sent by [email protected]"
        ),
    )

    client.tag_email(email_id=message["id"], tags=["processed"])

Poll for unread messages, verify each sender, process the payload, and reply with Agent B's own signed identity. Tags mark processed messages to prevent reprocessing.


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 is signed with Ed25519. The /.well-known/multimail-signing-key endpoint lets any receiver verify the sender without a 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-Signature header is a standard email header. Any agent or service that receives email can verify it by fetching the sender's public key from /.well-known/multimail-signing-key — a plain HTTP GET that returns a PEM-encoded public key. 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?
Ed25519. Each mailbox gets a unique Ed25519 key pair at creation time. The signature covers the concatenation of the X-MultiMail-Timestamp value and the message body. Public keys are published in PEM format at /.well-known/multimail-signing-key?mailbox=<address> and rotated annually with a 30-day overlap window so receiving agents can re-verify messages signed with the prior key.
Can I use this from a non-Python agent?
Yes. Use the REST API directly: POST to https://api.multimail.dev/v1/send with an Authorization: Bearer $MULTIMAIL_API_KEY... header and a JSON body containing mailbox, to, subject, and body fields. The response includes the signed message ID and the identity headers that were attached. 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?
MultiMail maintains a 30-day overlap window during key rotation. The /.well-known/multimail-signing-key endpoint always returns the current active key. If a receiving agent caches the public key, it should set a cache TTL of no more than 24 hours and re-fetch on any verification failure. The X-MultiMail-Key-Version header on each message identifies which key version was used, so a receiving agent can detect whether a cached key is stale without a full re-fetch on every message.

Explore more use cases

The only agent email with a verifiable sender

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