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 key tied to your API credential before handing it to the sending infrastructure. This signature travels as an RFC 822 header alongside standard DKIM. Recipients and auditors can verify it independently of the ESP. The signature covers the agent identifier, oversight mode, approval reference (if any), and a hash of the message body. 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 authorization.
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 signs a canonical representation of the message using an ECDSA-P256 key bound to your API credential. The signed payload includes: your tenant ID, the agent identifier passed in the X-MM-Agent header, the active oversight mode, any approval_code if the send went through a gated flow, and a SHA-256 hash of the message body. The resulting signature is attached as X-MM-Identity-Sig.
Any party with access to your public key — your compliance team, an audit system, a counterparty — can verify the X-MM-Identity-Sig header without contacting MultiMail. The public key is retrievable from the MultiMail API. Verification confirms the message was authorized by a specific API credential, sent by a named agent identifier, and that the body has not been altered since signing.
When MultiMail receives inbound email, it runs DKIM verification on arrival and attaches the authentication result to the message object. read_email returns dkim_result (pass/fail/none), dkim_domain, and dkim_selector so your agent can inspect sender authentication before acting on message content. This lets you build policies that treat unauthenticated inbound differently from DKIM-verified senders.
Every send logged in MultiMail's audit trail records the DKIM signature status, the X-MM-Identity-Sig value, the oversight mode active at send time, and the agent identifier. This gives forensic investigators a complete chain: domain authentication via DKIM, agent attribution via ECDSA signature, and authorization state via oversight mode — all correlated to a single message ID.
import multimail
client = multimail.Client(api_key="$MULTIMAIL_API_KEY")
response = client.send_email(
from_address="[email protected]",
to=["[email protected]"],
subject="Contract summary — Q2 review",
body="Attached is the automated summary generated from the Q2 dataset.",
agent_id="contract-summarizer-v2", "cm"># included in ECDSA-signed payload
oversight_mode="monitored"
)
print(response.message_id) "cm"># mm_msg_01HXYZ...
print(response.identity_sig_id) "cm"># identity signature reference
print(response.dkim_domain) "cm"># domain DKIM will sign underPass an agent identifier on every send. MultiMail includes this in the ECDSA-signed payload so the identity layer can attribute the message to a specific software actor, not just a tenant.
import multimail
client = multimail.Client(api_key="$MULTIMAIL_API_KEY")
"cm"># Fetch a specific inbound message
message = client.read_email(
mailbox="[email protected]",
message_id="mm_msg_01HXYZ_inbound"
)
"cm"># Check DKIM before trusting sender claims
if message.dkim_result != "pass":
print(f"DKIM failed or absent: {message.dkim_result}")
print(f"Sender domain: {message.from_domain}")
"cm"># Route to human review rather than automated processing
client.tag_email(
message_id=message.message_id,
tags=["dkim-unverified", "manual-review"]
)
else:
print(f"DKIM verified via {message.dkim_domain} (selector: {message.dkim_selector})")
"cm"># Proceed with automated handlingInspect the DKIM result MultiMail attached on inbound delivery. Use this before acting on sender claims in the message body.
import base64
import hashlib
import json
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import hashes, serialization
import multimail
client = multimail.Client(api_key="$MULTIMAIL_API_KEY")
"cm"># Retrieve your tenant's public key for offline verification
pubkey_pem = client.get_identity_public_key() "cm"># returns PEM string
public_key = serialization.load_pem_public_key(pubkey_pem.encode())
def verify_identity_sig(raw_message_headers: dict, body: str) -> bool:
sig_header = raw_message_headers.get("X-MM-Identity-Sig")
if not sig_header:
return False
"cm"># Parse the structured header
parts = dict(field.split("=", 1) for field in sig_header.split("; "))
signature_bytes = base64.b64decode(parts["sig"])
"cm"># Reconstruct the signed payload MultiMail hashed
signed_payload = json.dumps({
"tenant": parts["tenant"],
"agent": parts["agent"],
"oversight": parts["oversight"],
"body_hash": hashlib.sha256(body.encode()).hexdigest()
}, sort_keys=True).encode()
try:
public_key.verify(signature_bytes, signed_payload, ec.ECDSA(hashes.SHA256()))
return True
except Exception:
return False
"cm"># Example usage against an audit copy
headers = {
"X-MM-Identity-Sig": "tenant=ten_01HX; agent=contract-summarizer-v2; oversight=monitored; sig=BASE64SIGHERE"
}
print(verify_identity_sig(headers, "Attached is the automated summary..."))If your system receives a copy of an outbound message (BCC, forwarded audit copy), verify the X-MM-Identity-Sig header to confirm agent attribution without calling back to MultiMail.
import multimail
client = multimail.Client(api_key="$MULTIMAIL_API_KEY")
"cm"># Poll the inbox for new messages
messages = client.check_inbox(
mailbox="[email protected]",
unread_only=True
)
for msg in messages:
thread = client.get_thread(thread_id=msg.thread_id)
"cm"># Build a structured audit record
audit_record = {
"message_id": msg.message_id,
"thread_id": msg.thread_id,
"received_at": msg.received_at,
"from": msg.from_address,
"dkim_result": msg.dkim_result,
"dkim_domain": msg.dkim_domain,
"original_agent": thread.messages[0].agent_id if thread.messages else None,
"original_oversight": thread.messages[0].oversight_mode if thread.messages else None,
}
print(audit_record)
"cm"># Tag with authentication outcome for downstream filtering
client.tag_email(
message_id=msg.message_id,
tags=[f"dkim:{msg.dkim_result}", "agent-origin-recorded"]
)When processing inbound replies to agent-sent messages, record the DKIM verification result and original agent attribution together for your audit log.
If you switch ESPs, rotate DKIM keys, or change sending domains, the ECDSA identity signature remains valid because it is bound to your MultiMail API credential, not your mail infrastructure. Your audit trail stays intact across infrastructure migrations.
MultiMail verifies DKIM on inbound delivery and exposes dkim_result, dkim_domain, and dkim_selector as first-class fields on every message object. Your agent does not need to parse Authentication-Results headers — it reads structured data and can branch logic on authentication outcome without string parsing.
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 that ECDSA signing covers — agent attribution, oversight mode binding, approval reference linkage — 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 50-tool MCP server. Formally verified in Lean 4.