Standard DKIM tells you an email left through a trusted mail server. It says nothing about which AI agent authored it, what oversight applied, or whether a human approved the send.
When an AI agent sends email through a standard ESP, DKIM signs the message with the ESP's private key — not yours, not your agent's. A passing DKIM check confirms the message transited infrastructure you configured. It does not confirm which agent generated the content, which oversight mode was active, or whether the send was authorized by your access control policy. For most consumer email this distinction doesn't matter. For agentic systems operating at high volume with real business consequences, it does. An auditor asking 'which software actor sent this email and was it authorized?' cannot answer that question from DKIM alone. Neither can your incident response team.
MultiMail signs every outbound message with an ECDSA P-256 key before handing it to the sending infrastructure. This signature travels as the X-MultiMail-Identity header alongside standard DKIM. Recipients and auditors can verify it independently of the ESP, against the public key at /.well-known/multimail-signing-key. The signed claim covers the operator and mailbox identity, the oversight mode, the agent's capabilities, and the AI-generated flag. Standard DKIM remains in place for MTA-level authentication. MultiMail's identity layer answers the question DKIM was never designed to answer: which accountable software actor sent this, and under what oversight.
When MultiMail delivers your message, the outbound MTA applies a standard DKIM signature using a key published in your DNS records. Receiving MTAs verify this signature to confirm the message was not tampered with in transit and originated from infrastructure authorized to send on behalf of your domain. This is table stakes — it stops spoofing at the infrastructure layer.
Before the message reaches the MTA, MultiMail builds a signed claim using an ECDSA P-256 key. The base64url claim payload covers the operator and mailbox identity, the active oversight mode, the agent's capabilities, and the AI-generated flag, plus an issued-at timestamp inside the payload. The resulting payload-plus-signature is attached as the X-MultiMail-Identity header.
Any party — your compliance team, an audit system, a counterparty — can verify the X-MultiMail-Identity claim without contacting MultiMail. The signing public key is published at /.well-known/multimail-signing-key. Verification confirms the message was sent from a specific operator and mailbox, under a stated oversight mode, and that the claim has not been altered since signing.
When MultiMail receives inbound email, it stores the message and preserves its headers. Your agent fetches it via GET /v1/mailboxes/{mailbox_id}/emails/{email_id} and, for mail from another MultiMail sender, verifies the X-MultiMail-Identity claim before acting on the content. This lets you build policies that treat mail carrying a verifiable agent-identity claim differently from unauthenticated inbound.
Every send logged in MultiMail's audit trail records the oversight mode active at send time alongside the message identity. This gives forensic investigators a complete chain: domain authentication via DKIM, agent attribution via the signed X-MultiMail-Identity claim, and authorization state via oversight mode — all correlated to a single message id.
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.
If you switch ESPs, rotate DKIM keys, or change sending domains, the signed X-MultiMail-Identity claim remains verifiable because it is signed by MultiMail's own key, independent of your mail infrastructure. Your audit trail stays intact across infrastructure migrations.
For inbound mail from another MultiMail sender, your agent verifies the X-MultiMail-Identity claim against one public key and reads the operator, mailbox, and oversight mode straight from the signed payload. It can branch logic on a cryptographically verified sender identity rather than trusting the From header or parsing Authentication-Results.
The ECDSA signature covers the oversight mode active at send time, not just the message content. An auditor can verify that a given message was sent under monitored mode — not autonomous — without relying on a mutable database record. The proof is in the message itself.
MultiMail's oversight and identity models are proven correct in Lean 4. The properties the signed X-MultiMail-Identity claim covers — agent attribution and oversight mode binding — are verified to hold for all valid inputs, not just tested on sampled cases.
Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.