Transactional Email Infrastructure for AI Agents

Send order confirmations, receipts, and account notifications through AI agents at scale — with built-in CAN-SPAM compliance, DKIM signing, and delivery tracking.


Why this matters

Transactional emails — order confirmations, receipts, billing notifications, account alerts — need to reach inboxes reliably and comply with CAN-SPAM. When AI agents generate and send these emails, you need infrastructure that handles deliverability, identity authentication, and compliance automatically. Rolling your own SMTP pipeline means managing DKIM keys, handling bounces, maintaining sender reputation, and staying current with CAN-SPAM rules — all while ensuring your agent's output is accurate enough to send without manual review on every message.


How MultiMail solves this

MultiMail provides a single API that AI agents use to send transactional email with production-grade deliverability. DKIM signing, SPF alignment, bounce suppression, and CAN-SPAM footer compliance are built into the infrastructure — agents don't implement them. The monitored oversight mode lets agents send autonomously while giving your operations team a complete log of every message dispatched. Webhooks deliver real-time delivery, bounce, and complaint events back to your agent so it can update downstream systems without polling.

1

Trigger Event

A business event — order placed, payment received, account created — triggers your agent. The agent receives structured data: order ID, customer email, line items, or account details, and proceeds to compose the transactional message.

2

Generate and Send

The agent calls the mailbox send endpoint (POST /v1/mailboxes/{mailbox_id}/send) via the REST API or the MCP tool. MultiMail validates the payload, applies DKIM signing to the sending domain, enforces CAN-SPAM header requirements, and queues the message for delivery.

3

Track Delivery

MultiMail emits webhook events for delivered, bounced, deferred, and complained statuses. Each event carries the email id returned at send time, so you can correlate delivery outcomes with the business record you stored against that id.

4

Handle Bounces

Hard bounces are automatically suppressed at the infrastructure layer to protect sender reputation. Your webhook handler receives the bounce type and recipient address so downstream systems — CRM, order management — can be updated with accurate delivery status.

5

Monitor with Oversight

In monitored mode, every outbound transactional message is logged and visible to your team in real time. No approval gate delays delivery, but operators can review the full message history and intervene if the agent produces incorrect content — wrong totals, wrong recipient.


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. Read https://multimail.dev/llms.txt, connect the MCP server, create a free inbox, and set up a verified sender. 2. In Shopify, use Admin API webhook subscriptions for orders/create, orders/paid, orders/cancelled, refunds/create, and fulfillments/create so your agent is triggered by real store events. 3. For each event, fetch the order, customer, line items, totals, fulfillment status, refund details, and shop policies from Shopify, then compose the right transactional email: order confirmation, payment receipt, shipment update, cancellation notice, or refund confirmation. 4. Personalize each message with the customer name, order number, purchased items, amounts, shipping address, tracking details when available, and the store’s brand voice; do not add marketing copy unless the store already includes it in transactional templates. 5. Send through MultiMail in monitored mode, keep a dispatch log by Shopify order ID, and ask me only for Shopify access, MultiMail access, and the approved sender/domain and brand details needed to go live.

What you get

CAN-SPAM Compliance at the Infrastructure Layer

MultiMail enforces CAN-SPAM requirements automatically: physical mailing address in the footer, accurate from-address, working unsubscribe mechanism, and compliant headers. Transactional emails have narrower obligations than marketing email, but MultiMail handles both. Agents do not implement compliance logic — it is enforced on every send.

DKIM and SPF Identity Signing

Every email sent through MultiMail is signed with DKIM and aligned with your domain's SPF record. When you provision a custom-domain mailbox, MultiMail generates the DKIM keypair and provides DNS records to publish. After propagation, signing is automatic on every outbound message — no agent-side key management.

Real-Time Delivery Webhooks Keyed by Email ID

MultiMail delivers structured webhook events for delivered, bounced, deferred, and complained statuses. Every event carries the email id returned at send time, so your downstream systems correlate each outcome to the order or account you stored against that id.

Automatic Bounce Suppression

Hard-bounced addresses are automatically suppressed from future sends at the infrastructure layer, protecting your domain's sender reputation without any agent-side logic. Bounce details — type, recipient, and the email id of the bounced message — are available via webhook for your CRM or customer database.

Operator Visibility Without Delivery Gates

Monitored mode gives operations teams a complete audit log of every transactional email sent by your agents, with full message content, sender, recipient, and timestamp. Delivery is not gated — confirmations reach customers in under a second — but operators can identify and remediate incorrect agent output without waiting for a customer complaint.


Recommended oversight mode

Recommended
monitored
Transactional emails are time-sensitive — order confirmations and account alerts must reach customers within seconds of the triggering event. Approval gates (gated_send or gated_all) introduce latency that is unacceptable for high-volume transactional flows in SaaS, e-commerce, and finance. Monitored mode preserves autonomous delivery speed while giving operators complete visibility into every message sent. If an agent produces an incorrect transactional message — wrong order total, wrong recipient — the audit log enables fast identification and remediation without blocking the queue. For higher-stakes transactional emails in regulated contexts (e.g., wire transfer confirmations), consider gated_send where per-message latency is acceptable in exchange for human verification.

Common questions

Does MultiMail handle CAN-SPAM compliance for transactional emails?
Yes. MultiMail enforces CAN-SPAM requirements at the infrastructure layer: physical mailing address in the footer, accurate from-address, working unsubscribe mechanism, and header compliance. Transactional emails — receipts, confirmations, account alerts — have narrower CAN-SPAM obligations than commercial marketing email, but MultiMail applies the required protections to both categories. Opt-out requests are processed and honored within the 10-business-day window required by law.
How does MultiMail protect sender reputation when addresses bounce?
Hard-bounced addresses are automatically suppressed from future sends at the infrastructure layer — your agent does not need to maintain a suppression list. You also receive an email.bounced webhook event with the bounce type (hard or soft), recipient address, and the email id of the bounced message. Wire your webhook handler to flag invalid addresses in your CRM or customer database so your agent does not attempt future sends to those addresses.
What oversight mode should I use for high-volume order confirmations?
Monitored mode is the standard choice for transactional email at volume. It allows agents to send without approval gates — necessary for sub-second delivery of order confirmations — while logging every message for operator review. Use gated_send for lower-volume or higher-stakes transactional emails (e.g., wire transfer confirmations in fintech) where added latency is acceptable in exchange for per-message human verification.
How do I correlate delivery events back to my business records?
Every send returns an email id (the id field on the 202 response). Store that id against your order or account record, and key off the email_id carried on each webhook event — delivered, bounced, and complained — to update the matching record. Maintain the id-to-record mapping in your own datastore; MultiMail identifies the message by its id across the send response and every webhook for that message.
Is DKIM signing automatic or do I need to configure it per-send?
DKIM signing is automatic for all outbound sends. When you provision a mailbox on a custom domain, MultiMail generates a DKIM keypair and provides the DNS TXT record to publish. After DNS propagation, every message from that domain is signed at the infrastructure layer. Agents do not manage DKIM keys or signing logic — it runs transparently on every send.
Can I use the MCP server to send transactional email from Claude Desktop or Cursor?
Yes. The send MCP tool accepts the same parameters as the REST send endpoint — mailbox_id, to, subject, and markdown. This is useful for agents running interactively in MCP-compatible clients that need to send a transactional email as part of a longer workflow. For production high-volume transactional workloads, the REST API is the appropriate choice — MCP tools are optimized for interactive, lower-frequency agent workflows.

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.