MultiMail signs every outbound agent email with an ECDSA identity header. Decode the X-MultiMail-Identity header to confirm agent origin, model metadata, and disclosure state — without relying on sender logs.
When an AI agent sends email on behalf of a user or organization, downstream systems, security teams, and recipients have no reliable way to confirm the message is authentic. Application logs can be tampered with. Claimed sender identities can be spoofed. There is no standard mechanism to cryptographically bind an email to the specific AI agent that generated it, the model version it ran, or the oversight mode it operated under at send time. This gap creates audit failures, compliance exposure under the EU AI Act's transparency requirements, and opens the door to spoofed automation masquerading as legitimate agent output.
MultiMail attaches a signed X-MultiMail-Identity header to every email dispatched through the API. The header is a base64url-encoded JSON payload — operator and mailbox identity, oversight mode, capabilities, the AI-generated flag, and an issued-at timestamp — followed by an ECDSA signature using the P-256 curve. MultiMail publishes the corresponding verification public key at the /.well-known/multimail-signing-key endpoint so any recipient system can independently verify the signature without calling back into your application. Verification is purely cryptographic: no trust is placed in the sending application's claims alone, and there are no identity-lookup endpoints — identity is the signed claim in the message plus the one public key.
Call GET /v1/mailboxes/{mailbox_id}/emails/{email_id} to fetch the full email record. The response includes a `headers` object containing X-MultiMail-Identity alongside standard fields like Message-ID and Date. For inbound emails that need verification, the same header is preserved when MultiMail receives and stores the message.
The X-MultiMail-Identity header value is a dot-separated structure: base64url(payload).base64url(signature). Decode the payload to a JSON object containing fields: operator, oversight, capabilities, ai_generated, verified_operator, service, and an iat (issued-at) timestamp. These fields describe the exact agent state at send time.
Retrieve the signing public key from GET /.well-known/multimail-signing-key. The endpoint returns a JWK object with the P-256 public key — one service key, with no per-tenant or per-agent lookup. Cache it with a 24-hour TTL on the verifier side to avoid per-message roundtrips, and re-fetch on any verification failure.
Reconstruct the signed message as base64url(payload) and verify the signature bytes against the public key using ES256 (ECDSA with P-256 and SHA-256). A valid signature confirms the payload has not been tampered with and was produced by MultiMail's signing infrastructure using the tenant's key at the stated timestamp.
After signature verification, assert that the decoded fields match your policy: operator matches the expected sender, oversight is not `autonomous` if your policy requires human review, ai_generated is true if EU AI Act disclosure is required, and the iat timestamp falls within an acceptable time window to prevent replay attacks.
Write the verification outcome — pass/fail, operator, oversight, and the claim's iat timestamp — to your audit log. This record satisfies EU AI Act Article 13 transparency requirements and provides evidence for security incident investigations. The signed X-MultiMail-Identity header is itself the portable receipt: re-verify it later against the public key, or have a recipient check it in a browser at https://multimail.dev/verify#<header-value>.
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.
The ECDSA signature in X-MultiMail-Identity is verifiable by any party with the public key. You do not need to query the sending application's logs or database to confirm authenticity — the header is self-contained evidence.
The identity payload includes the ai_generated flag, the operator and mailbox identity, and the oversight mode, giving recipients the information required under EU AI Act transparency obligations for automated decision-making systems. The signed header is itself a storable audit artifact.
Each identity claim includes an iat (issued-at) timestamp. Verifiers can reject claims outside an acceptable time window so a replayed header from an old message is not accepted as fresh verification evidence.
Verification depends on a single service signing key published at /.well-known/multimail-signing-key. Cache it with a short TTL and re-fetch on any verification failure — there is no per-tenant or per-agent key to track, which keeps verifier-side key management trivial.
Identity headers are attached regardless of whether the email was sent under gated_all, monitored, or autonomous oversight. Security teams can verify not just that an agent sent a message but what constraints it was operating under at send time.
Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.