A Defensible Answer to Every AI Email Security Question

MultiMail gives security teams cryptographic agent identity, formally verified oversight policies, and a complete audit trail — built for AI email risk, not retrofitted from generic ESPs.


Why this matters

When an AI agent sends email on behalf of your organization, security teams face four hard questions: Who authorized it? What controls prevented unauthorized sends? Can you prove the sending agent is who it claims to be? And if something goes wrong, can you reconstruct exactly what happened and why? Generic ESPs were built for human senders. They have no concept of agent identity, policy-enforced oversight, or action-level auditability. AI agents operating through conventional email infrastructure create an accountability gap that regulators — including under the EU AI Act — increasingly expect to be closed before deployment.


How MultiMail solves this

MultiMail addresses the CISO evaluation checklist with four concrete controls. Cryptographic identity: Every outbound message carries ECDSA-signed headers identifying the sending agent, tenant, and oversight policy in effect at send time. Recipients and auditors can verify these headers without contacting MultiMail. Formally verified oversight: Oversight mode policies are specified and verified in Lean 4. The gated_send guarantee — that no message is delivered without human approval — is not a test result; it is a machine-checked proof that holds for all possible API call sequences. Pre-send domain intelligence: Before any email leaves the system, MultiMail evaluates each recipient domain against DNS signals — MX, SPF, DMARC presence and policy, Spamhaus listing, disposable-domain detection — plus platform bounce history, assigning a green/yellow/red tier. Red-tier domains are blocked before reaching the approver queue; the gate fails open on DNS errors. Immutable audit trail: Every action — read, compose, send request, approval, rejection, cancellation — is logged with agent ID, policy state, and timestamp. Each entry is tied to the cryptographic identity of the actor.

1

Inspect Identity Headers

Every outbound message 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 in effect at send time, the agent's capabilities, and the AI-generated flag. Any recipient or auditor verifies the claim against the public key published at https://api.multimail.dev/.well-known/multimail-signing-key — no round-trip to MultiMail required, and without trusting the From header.

2

Review Policy Controls

Oversight modes are configured per mailbox and enforced at the API layer, not in application code. Under gated_send, the POST /v1/mailboxes/{mailbox_id}/send endpoint queues messages for human approval rather than delivering them, regardless of how the API call is constructed. The agent has no code path to force delivery — the enforcement is in MultiMail's infrastructure.

3

Trace Audit Events

The audit trail captures every action the agent takes: emails read, drafts composed, sends requested, approvals granted or denied, and messages cancelled. Each event is linked to the agent's cryptographic identity and the oversight policy active at the time. Events are queryable via the REST API and streamable to a SIEM via webhooks.

4

Validate Domain Intelligence

Pre-send checks run before every outbound message, evaluating recipient domains against DMARC presence and policy, MX and SPF records, Spamhaus listing, disposable-domain detection, and platform bounce history. Each domain resolves to a green, yellow, or red tier. Red-tier domains are blocked before the message reaches the approver queue, limiting the blast radius of a compromised or misbehaving agent.

5

Approve Deployment

The CISO evaluation package includes: the identity signing model and the public key endpoint (https://api.multimail.dev/.well-known/multimail-signing-key), Lean 4 proof artifacts for the oversight model, audit log schema and retention policy documentation, and domain intelligence coverage summary. This provides a documented, attestable evidence set for internal governance and regulatory reporting under the EU AI Act.


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 ServiceNow, watch for a new or updated Security Incident, Risk, or Change Request record using Flow Designer’s record-created or record-updated trigger, and treat records labeled for AI-agent email review as the workflow trigger. 3. Draft the required CISO-facing email with the record number, business owner, sending agent identity, requested recipient group, risk rationale, and a concise summary of the approval, rejection, or remediation needed. 4. Use MultiMail in gated_send mode so every outbound message waits for human approval before delivery, and preserve the ServiceNow record number in the message context for audit reconstruction. 5. Ask me only for my ServiceNow credentials, approved brand voice, sender domain, and the go-live approval list before enabling the workflow.

What you get

Cryptographic Agent Identity

ECDSA-signed headers on every outbound message prove which agent sent it, under which tenant, and which oversight policy applied. Verification is offline — recipients and auditors use the tenant's published public key and do not need to call MultiMail. This provides non-repudiation suitable for legal and regulatory proceedings.

Mathematically Verified Oversight

Oversight mode policies are specified in Lean 4 and formally verified. The gated_send guarantee — no message delivered without human approval — holds for all possible API call sequences, not just tested ones. Proof artifacts are available for independent review as part of the CISO evaluation package.

Pre-Send Domain Intelligence

Every recipient domain is evaluated before delivery against DMARC presence and policy, MX and SPF records, Spamhaus listing, disposable-domain detection, and platform bounce history, resolving to a green/yellow/red tier. Red-tier domains are blocked before they reach the approver, reducing the blast radius of a compromised or misbehaving agent.

Action-Level Audit Trail

Every read, compose, approval request, approval decision, and cancellation is logged with agent ID, oversight mode, and timestamp. The log is append-only and each entry is cryptographically attributed to the acting agent. Webhook streaming delivers events to your SIEM in real time.

EU AI Act Readiness

The EU AI Act requires traceability (Article 13), human oversight (Article 14), and transparency for systems interacting with humans (Article 52). MultiMail's audit trail, gated_send enforcement, and ECDSA identity signing address these requirements directly for AI systems that send email on behalf of organizations.


Recommended oversight mode

Recommended
gated_send
gated_send is the appropriate starting point for enterprise AI email deployments under CISO review. The agent can read inbox and gather context autonomously — reducing friction on non-risky operations — but no message is delivered without a designated human approver acting first. This gives security teams full visibility into outbound send patterns during initial deployment without blocking the agent from functioning. The enforcement is server-side: the agent cannot bypass it through any API call sequence, and this property is formally verified in Lean 4. For environments subject to EU AI Act Article 14 human oversight requirements, gated_send provides the clearest compliance posture. Once the agent's send behavior is well-characterized through the audit trail, organizations can evaluate whether monitored or autonomous mode is appropriate for specific mailboxes.

Common questions

How does MultiMail prove which agent sent a given email?
Every outbound message carries a single X-MultiMail-Identity header: an ECDSA P-256 signed claim — a base64url payload plus a base64url signature — that covers the operator and mailbox identity, the oversight mode in effect at send time, the agent's capabilities, and the AI-generated flag. Any recipient can verify the claim against the public key published at https://api.multimail.dev/.well-known/multimail-signing-key, or paste the header value into https://multimail.dev/verify#<header-value>. Verification is fully offline — no round-trip to MultiMail is required, and the From header is never trusted. There are deliberately no identity-lookup endpoints (a lookup API would be an enumeration oracle); identity is the signed claim carried in the message plus the one public-key endpoint. This provides non-repudiation: a verified claim is evidence that the identified mailbox sent the message under the stated oversight policy.
What prevents an agent from bypassing gated_send and delivering a message directly?
Oversight mode is enforced at the API layer, not in the agent's code. When a mailbox is configured with gated_send, the POST /v1/mailboxes/{mailbox_id}/send endpoint queues the message for approval rather than delivering it, regardless of how the agent constructs the request. There is no parameter the agent can pass to force immediate delivery. This enforcement is also what the Lean 4 formal proof covers: the proof verifies that no sequence of valid API calls can transition a gated_send mailbox to delivery without a prior approval event from a credentialed approver.
What does the Lean 4 formal verification actually prove, and how can we review the proofs?
The Lean 4 proofs verify the formal model of MultiMail's oversight and identity systems. Specifically: (1) under gated_send, the system cannot deliver a message without a prior approval event — proven for all possible API call sequences; (2) identity header generation is deterministic given the agent credentials — no two distinct agents can produce the same valid signature for the same message; (3) oversight mode transitions require explicit tenant-level authorization and are recorded in the audit trail. Proof source files are available in the MultiMail repository under Proofs/ and can be independently checked using a standard Lean 4 toolchain. The CISO evaluation package includes compiled proof artifacts and a walkthrough of the theorem statements.
Can we audit which humans approved or rejected sends, and when?
Yes. Every approval and rejection event is recorded in the audit trail with the approver's identity, the decision timestamp, and the message ID. Human approvals via the approval UI or email are attributed to the approver's email address. Programmatic approvals via POST /v1/oversight/decide are attributed to the API key used. The audit log is append-only and queryable via GET /v1/audit-log; pending items are listed via GET /v1/oversight/pending and individual messages read via GET /v1/mailboxes/{mailbox_id}/emails/{email_id}. All events are also available via webhook for real-time SIEM ingestion.
How does pre-send domain intelligence work, and what signals does it evaluate?
Before any message is queued for delivery, MultiMail evaluates the recipient domain against: DMARC presence and policy, MX and SPF records, Spamhaus listing, disposable-domain detection, and platform bounce history. The result is a green, yellow, or red tier. Red-tier domains are blocked at the gateway before the message reaches the approver. Domain intelligence runs at the infrastructure level on every send attempt — it is not dependent on the agent's implementation, and it fails open on DNS errors so a transient resolver outage does not silently halt sending.
How does MultiMail handle EU AI Act Article 14 human oversight requirements?
EU AI Act Article 14 requires that high-risk AI systems allow humans to intervene and override automated decisions with appropriate tools and understanding. MultiMail's gated_send mode implements this directly for email: no outbound message is delivered without a human decision, and the approver reviews the full message content before approving. The audit trail addresses Article 13 traceability requirements. ECDSA identity signing and the gateway-enforced X-AI-Generated disclosure support Article 52 transparency requirements for AI systems interacting with humans. If your AI system is classified high-risk under Annex III and email is part of its operation, gated_send with audit logging and identity signing provides a defensible compliance posture for regulatory review.
Can audit events be streamed to our SIEM in real time?
Yes. Configure a webhook endpoint to receive all audit events — send requests, approval decisions, rejections, cancellations, and reads — as they occur. Each webhook payload includes the full event record: agent ID, oversight mode, message ID, decision, reason, and timestamp. The payload structure is stable and documented, making it suitable for ingestion into Splunk, Datadog Security, or any SIEM that accepts JSON webhooks. Webhook delivery is retried on failure with exponential backoff, and a delivery log is queryable via the API.

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.