MultiMail monitors bounce rates, complaint rates, and domain health so your agent sends from clean infrastructure — without manual intervention.
Email deliverability breaks quietly. New mailboxes get throttled by ISPs before they've built reputation. Domains on shared IP ranges inherit bad neighbors' spam scores. A single campaign with a 0.5% complaint rate can trigger a block that takes weeks to reverse. Most AI agents have no visibility into these signals — they keep sending until the damage is done, at which point the remediation window has already closed.
MultiMail enforces deliverability guardrails at the infrastructure layer. New mailboxes have gradually increasing daily send limits that prevent fresh senders from hitting volume thresholds before ISPs trust them; exceeding the current limit returns HTTP 429 rather than silently dropping the send. Custom domains are verified for SPF, DKIM, MX, and return-path alignment via GET /v1/domains/{id} before they can send. Every outbound message carries a signed X-MultiMail-Reputation header, and any recipient can look up that reputation at the public GET /.well-known/reputation/{hash} endpoint. Sustained bounce and complaint problems lower a mailbox's standing and tighten its limits automatically — protecting the shared sending commons without requiring operator intervention in the critical path.
MultiMail enforces per-mailbox daily send limits during the warmup period. New mailboxes ramp from 50 to 500 to 5,000 emails per day over 30 days, matching the volume curve ISPs expect from legitimate senders. Exceeding the limit returns HTTP 429 with a Retry-After header — the send is not silently dropped.
Before sending from a custom domain, your agent queries GET /v1/domains/{id} to confirm SPF, DKIM, MX, and return-path alignment. The response includes the per-record verification flags (dkim_verified, spf_verified, mx_verified, return_path_verified) and the dns_records you must publish. A domain that has not reached verified status cannot send.
The mailbox send endpoint (POST /v1/mailboxes/{mailbox_id}/send) sends from a mailbox on a verified domain. MultiMail signs outbound messages with DKIM, attaches the signed X-MultiMail-Identity claim, and enforces alignment on the sending domain. The sender is the mailbox in the path plus your bearer key — there is no from field to spoof, so a different domain cannot be impersonated.
Every outbound message carries a signed X-MultiMail-Reputation header — a hash that any recipient can resolve at the public GET /.well-known/reputation/{hash} endpoint to see the sender's standing without trusting the From header. Reputation is computed from real delivery outcomes (bounces, complaints, and spam-trap hits), so building a clean send history directly raises how recipients and ISPs treat your mail.
Google and Yahoo's 2024 bulk-sender requirements cap complaint rate at 0.1% and bounce rate at 2%. As an account's bounces and complaints accumulate, MultiMail lowers its reputation score and raises its enforcement tier — which tightens send limits and gates higher-trust actions like provisioning additional mailboxes. Sustained abuse degrades standing automatically, no operator action required.
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.
MultiMail applies daily send limits at the API layer during warmup. New mailboxes ramp volume automatically over 30 days without manual scheduling. Attempts to exceed the limit return a 429 — the send is never silently dropped or queued past the safe window.
Google and Yahoo enforce a 2% bounce and 0.1% complaint ceiling for all bulk senders. As an account's bounces and complaints accumulate, MultiMail lowers its reputation score and raises its enforcement tier — tightening send limits and gating higher-trust actions automatically. Your agent does not need to poll for these conditions; enforcement is a platform-level guarantee.
Every outbound message carries a signed X-MultiMail-Reputation header derived from real bounce and complaint outcomes. Any recipient can resolve it at the public GET /.well-known/reputation/{hash} endpoint without trusting the From header — so a clean send history is reputation any party can verify, not a private score.
SPF, DKIM, MX, and return-path alignment is verified per domain via GET /v1/domains/{id} and POST /v1/domains/{id}/verify. A domain that has not reached verified status cannot send, so misconfigured domains never reach ISPs and damage sender reputation across the shared pool.
MultiMail enforces unsubscribe processing, opt-out honoring, and suppression list management as infrastructure constraints under CAN-SPAM. Your agent does not need to implement these requirements in application logic — non-compliant sends are rejected before delivery.
Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.