Machine-Readable AI Disclosure for Every Email Your Agent Sends

ECDSA P-256 signed identity headers that let any recipient programmatically verify an email was AI-generated, who operated the agent, and what oversight was in place.


Why this matters

Regulators worldwide are mandating AI disclosure in communications, but there is no standard way to make that disclosure machine-readable. A footer saying "This email was sent by AI" is easy for humans to read but impossible for downstream systems to parse reliably. Email providers, compliance tools, and receiving agents need a structured, cryptographically verifiable signal — not a line of prose buried in the body. Without a machine-readable header, organizations cannot build automated AI-email filtering, cannot prove disclosure compliance to auditors, and cannot verify that a disclosure claim is authentic rather than spoofed.


How MultiMail solves this

MultiMail attaches two headers to every AI-sent email. X-AI-Generated: true is an unsigned convenience header for simple filtering. X-MultiMail-Identity is the real payload: an ECDSA P-256 signed, base64url-encoded JSON claim containing ai_generated, operator, oversight mode, capabilities, reputation hash, and timestamps. Anyone can verify the signature against the public key published at /.well-known/multimail-signing-key. Unlike DKIM — which cannot sign custom headers and breaks on forwarding — the MultiMail identity claim is independently verifiable, carries richer metadata, and survives DKIM breakage. AI disclosure is gateway-enforced per mailbox: the ai_disclosure setting is locked on and cannot be disabled, so every agent-originated message carries the disclosure.

1

Agent Sends Email via MultiMail API

Your AI agent calls POST /v1/mailboxes/{mailbox_id}/send. AI disclosure is gateway-enforced — the mailbox's ai_disclosure setting is locked on — so MultiMail always prepares the identity claim for agent-originated mail.

2

Identity Claim is Constructed

MultiMail builds a JSON payload with ai_generated, operator, oversight mode, capabilities, verified_operator status, service identifier, creation timestamp (iat), and a reputation_hash. Keys are sorted for canonical JSON serialization to ensure deterministic signing.

3

Payload is Signed with ECDSA P-256

The canonical JSON is signed with MultiMail's ECDSA P-256 private key. The signature and payload are base64url-encoded and attached as the X-MultiMail-Identity header. A plain X-AI-Generated: true header is also added.

4

Body Disclosure Block is Appended

A human-readable sig block — including 'This email was sent by an AI agent.' — is appended to the email body, satisfying text-based disclosure requirements alongside the machine-readable header.

5

Recipient Verifies the Claim

Any recipient or intermediate system fetches the public key from multimail.dev/.well-known/multimail-signing-key, decodes the base64url header, and verifies the ECDSA signature. The verification page at multimail.dev/verify provides a browser-based tool for manual checks.


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 Microsoft 365, use Power Automate with the Outlook connector trigger “When a new email arrives in a shared mailbox” for the support, sales, or operations mailbox you want the AI agent to handle. 3. For each qualifying inbound message, classify intent, draft a reply using the customer’s name, thread context, account details available in Microsoft 365, and the company’s approved disclosure wording, then skip messages that require legal, security, billing, or executive approval. 4. Send routine replies through MultiMail in monitored mode, schedule follow-ups for unanswered threads after 2 business days, and keep the Microsoft 365 conversation updated with the sent-message summary. 5. Before going live, ask me only for Microsoft 365 access, the mailbox to monitor, approved brand voice, escalation rules, and the verified sender details.

What you get

Cryptographically Verifiable Disclosure

ECDSA P-256 signatures let any recipient prove an email was AI-generated without trusting the sender. The public key at /.well-known/multimail-signing-key makes verification independent of MultiMail's API.

Survives DKIM Breakage

DKIM only signs From, Date, Subject, MIME-Version, Content-Type, Content-Transfer-Encoding, To, and Message-ID — it cannot sign custom headers. The MultiMail identity claim is self-contained and verifiable even when DKIM breaks on forwarding.

Richer Metadata Than Plain Headers

Beyond a boolean ai_generated flag, the signed claim includes the operator identity, oversight mode, agent capabilities, reputation hash, and timestamps — everything a receiving system needs for policy decisions.

Formally Verified Tamper Evidence

MultiMail's Lean 4 formal proofs include the tamper_evident_ai_generated theorem, which proves that modifying the ai_generated field invalidates the signature. This is not just tested — it is mathematically proven.

Disclosure Cannot Be Silently Suppressed

AI disclosure is gateway-enforced: the ai_disclosure setting is locked on per mailbox and cannot be disabled. A recipient can trust that the absence of the X-AI-Generated header and signed disclosure means the message was not sent as agent-originated mail through MultiMail — disclosure is never quietly turned off.


Recommended oversight mode

Recommended
monitored
AI disclosure headers are attached automatically by the system and do not alter email content. The disclosure is a factual, cryptographic assertion — not a creative decision. Monitored mode lets the human review the audit log without blocking every send, since the header content is deterministic and cannot misrepresent the sender.

Common questions

Can a sender fake the X-AI-Generated header?
The unsigned X-AI-Generated: true header is a convenience signal and can be spoofed. That is why the X-MultiMail-Identity header exists: it is ECDSA P-256 signed, and the signature can only be produced by MultiMail's private key. Verify the signature against the public key at multimail.dev/.well-known/multimail-signing-key to confirm authenticity.
Why not rely on DKIM to authenticate the disclosure?
DKIM signs only a fixed set of standard headers (From, Date, Subject, MIME-Version, Content-Type, Content-Transfer-Encoding, To, Message-ID). Custom headers like X-MultiMail-Identity are not covered. Additionally, DKIM signatures break on forwarding. The ECDSA identity claim is independently verifiable regardless of DKIM status.
What does the reputation_hash field contain?
The reputation_hash is a SHA-256 hash of the sending mailbox's reputation metrics at send time. It lets a verifier confirm that the reputation data has not been altered after the fact, without exposing the raw reputation scores in the header.
Can I disable AI disclosure for a mailbox?
No. AI disclosure is gateway-enforced: the ai_disclosure setting is locked on per mailbox and cannot be turned off. Every agent-originated message MultiMail sends carries the X-AI-Generated header, the signed X-MultiMail-Identity claim, and the human-readable disclosure footer. This is a deliberate trust guarantee — recipients can rely on disclosure being present rather than something a sender could quietly suppress.
What is canonical JSON serialization and why does it matter?
Canonical JSON means the keys are sorted alphabetically and serialized deterministically before signing. This ensures the same claim always produces the same byte sequence, so the ECDSA signature is reproducible and verifiable. Without canonical serialization, key ordering differences would produce different signatures for identical claims.
Does this satisfy EU AI Act email disclosure requirements?
The EU AI Act requires that AI-generated content be disclosed to recipients. MultiMail provides both human-readable disclosure (body sig block) and machine-readable disclosure (signed header). Together they satisfy the requirement for clear and conspicuous AI labeling. See the EU AI Act compliance use case for full regulatory detail.
What does the Lean 4 tamper_evident_ai_generated proof guarantee?
The formal proof mathematically demonstrates that any modification to the ai_generated field in the identity claim will cause signature verification to fail. This is stronger than test coverage — it holds for all possible inputs, not just tested cases.
How do MultiMail's identity headers relate to NIST agent identity standards?
NIST's AI Agent Standards Initiative identifies four requirements for agent identity infrastructure: federated, cryptographically verifiable, domain-anchored, and already deployed. MultiMail's X-MultiMail-Identity header satisfies all four — it's ECDSA P-256 signed (cryptographic), tied to the sender's domain (domain-anchored), verifiable via a public /.well-known/ endpoint (federated), and live in production today (deployed). Email authentication is the only existing system meeting all four NIST criteria simultaneously.

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.