MultiMail records every hard bounce on a per-tenant suppression list and refuses the next send to that address — so one bad address can't keep costing you reputation.
High-volume AI agents sending to stale or invalid addresses accumulate bounces rapidly. Repeated hard bounces trigger ISP throttling and can damage your sending domain's reputation within days. The damage is not isolated — in a shared infrastructure environment, one agent's bounce spike degrades deliverability for every tenant on the platform. Traditional approaches let an agent re-send to a known-bad address again and again. By then the reputation hit has already landed, and unwinding a blacklisting takes weeks of remediation that no agent can automate away.
When a message hard-bounces, MultiMail records the recipient address on your tenant's suppression list automatically and fires an email.bounced webhook with the SMTP diagnostic code. The next send to a suppressed address is refused at the API layer — the send endpoint returns HTTP 400 before the message enters the queue, so a known-bad address never burns more reputation. Your agent lists the current suppression set with GET /v1/suppression and prunes it before building a send list, and can remove a non-permanent suppression with DELETE /v1/suppression/{address} when a contact confirms a working mailbox.
Before queuing a message, MultiMail checks the recipient against your tenant's suppression list. If the address was previously hard-bounced or unsubscribed, the send endpoint returns HTTP 400 before the message is queued — the check is transparent to your agent for any address that is not suppressed.
A suppressed recipient never reaches the mail server. POST /v1/mailboxes/{mailbox_id}/send returns a 400 with an error explaining the address is on the suppression list (bounced or unsubscribed), so a known-bad address contributes zero additional bounce volume to your sending reputation.
When a hard bounce occurs (SMTP 5xx, invalid mailbox, domain not found), MultiMail fires an email.bounced webhook to your registered endpoint and adds the address to your tenant's suppression list. Subsequent sends to that address return a 400 before consuming send quota.
Hard-bounce suppressions are permanent — DELETE /v1/suppression/{address} returns 403 for them, because the failure signal stays valid until the contact proves a working mailbox. Unsubscribe and soft suppressions can be removed once the contact confirms a deliverable address.
Your agent calls GET /v1/suppression to retrieve the current per-tenant suppression set and prunes those addresses while preparing a send list — rather than discovering suppressions one 400 at a time mid-campaign.
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.
A suppression check runs before the send endpoint queues a message. A previously hard-bounced or unsubscribed address is refused with a 400 and never reaches the mail server, contributing zero additional bounce volume to your sending domain's reputation.
When a recipient hard-bounces, MultiMail records the address on your tenant's suppression list automatically and fires an email.bounced webhook. You do not maintain a suppression list by hand — the platform builds it from real delivery outcomes.
Subsequent sends to a suppressed address return HTTP 400 before the request enters the queue, consuming no send quota. Your agent prunes the contact instead of burning attempts on an address that will never deliver.
GET /v1/suppression returns each entry's reason (e.g. hard_bounce, unsubscribe) alongside the address, mailbox, and timestamp. The send-time 400 names the suppression list explicitly. Your agent routes, logs, or escalates on a stable signal.
Hard-bounce suppressions are permanent — they protect you from re-sending to a dead mailbox until the contact proves a working address. Unsubscribe and soft suppressions can be lifted via DELETE /v1/suppression/{address} once the contact confirms a deliverable mailbox.
Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.