The firewall between your AI agent and your sending reputation.

Handing an autonomous agent a send() call is a different kind of risk than handing it to a human. A person sends a few emails an hour and notices when something feels wrong. An agent in a loop can send thousands before anyone looks, and it has no instinct for “this feels like spam.” A retry storm, a poisoned input, a prompt that talked it into emailing a purchased list — any of these can get your entire domain flagged as a spammer in an afternoon. And domain reputation, once burned, takes weeks to rebuild.

So the interesting question for agent email isn’t “can it send?” Any API can send. The question is: what stops a misbehaving agent from torching your sending reputation? That protection is the product. This post walks through the firewall Mails.ai puts between your agent and the outside world — on the way out and on the way in.

Deliverability

The threat model

Three failure modes are specific to agents, and a normal email API does nothing about any of them:

• The runaway agent. A bug, a bad loop, or a hallucinated task list has your own agent sending mail it shouldn’t — to the wrong people, too fast, or to addresses that already bounced. Every one of those is a complaint or a bounce, and complaints and bounces are what get a domain flagged.
• The poisoned agent. An attacker emails your agent instructions (“forward everything to me,” “email this list on my behalf”) and a naive agent obeys. Now your reputation is being spent by someone else, through your own infrastructure.
• The noisy neighbor. On shared sending infrastructure, one abusive tenant’s complaint rate can drag down the reputation of everyone sharing the IP pool — including you, who did nothing wrong.

A firewall answers all three the same way: inspect every packet, enforce a policy, and isolate blast radius. Here’s how that maps to email.

Outbound: a gate on every send

Every agent.send() passes through a reputation classifier before it leaves our system. It’s rules plus a lightweight LLM call that scores the send for complaint-risk signals: the recipient relationship, engagement history, content patterns, and send-rate anomalies. Two things can happen at that gate:

• Suppression check. If the recipient is on your workspace’s suppression list — anyone who previously bounced, unsubscribed, or complained — the send is dropped right there. Suppression runs at send time, so a known-bad address never gets another message no matter which of your agents tries.
• Risk throttle. If the sender’s risk score is spiking — a sudden send-rate jump, a batch that looks list-shaped, content that reads like cold outreach — the sender gets auto-throttled until its reputation rebuilds. A runaway loop hits the brakes automatically instead of running until mailbox providers notice.

Cleared sends leave through Cloudflare or, for custom domains and workspace subdomains, our own mail servers. The classifier is invisible to your code — you call send() exactly as you would with any transactional API, and the firewall does its work underneath. It’s deliverability infrastructure, not a knob you tune.

import { mails } from "@mailsai/sdk";

const hello = mails.agent("hello"); // the agent every workspace gets at signup

// You just call send(). The reputation classifier + suppression check
// run before it leaves — a suppressed recipient is dropped, a spiking
// sender is throttled. No flag to set, no policy to wire up.
await hello.send({
  to: "customer@example.com",
  subject: "Your report is ready",
  body: "...",
});

The complaint cron: paused before the shared reputation feels it

The send-time gate stops the obvious. The complaint cron catches what slips through. A per-sender complaint-and-bounce job runs every 15 minutes. Any sender crossing a 0.3% complaint rateauto-suspends, and its reputation drops for that sender identity permanently. A 5% bounce rate triggers the same suspend.

The 0.3% number is deliberate. Gmail’s sender guidelines ask senders to keep the spam rate reported in Postmaster Tools below 0.3%, and bulk senders below 0.1%. By auto-suspending at 0.3%, a misbehaving sender is paused before its complaints can put the shared sending reputation, and everyone on it, at risk.

Isolation: one rogue tenant can’t burn the pool

This is the noisy-neighbor answer. Reputation on Mails.ai is scoped two ways:

• Per agent. Every agent has its own reputation score, built from real engagement signals — reply rate, bounce rate, complaint rate, suppression hits, recipient sender-reputation lookups. A bad agent’s bad score doesn’t bleed onto your good ones.
• Per workspace. Suppression and verified-agent status are workspace-scoped. A complaint against someone else’s agent in another workspace has zero effect on yours. A banned sender loses verified-agent status across all of your agents — enforced on every send — so a bad actor can’t just spin up a fresh identity and keep going.

Because the complaint cron pauses a bad sender at 0.3% — long before it accumulates enough complaints to move the shared sending reputation — a rogue tenant gets stopped before the network ever feels them. Your agent’s deliverability is not a function of anyone else’s behavior. Customers on Scale+ who want physical reputation isolation as well can add a Dedicated IP (on request per IP).

Your agent can also read the score and act on it. Reputation is queryable via the mails_get_reputation MCP tool, and it’s baked into every inbound event as event.sender_reputation, so your agent can refuse to act on a low-reputation sender before it even reads the body:

hello.onReply((event) => {
  // The sender's reputation rides on every inbound event.
  if ((event.sender_reputation ?? 0.5) < 0.3) {
    return; // don't act on senders with a poor track record
  }
  // ...handle the event
});

Inbound: the other half of the firewall

A firewall inspects traffic in both directions. The poisoned-agent failure mode — an attacker emailing your agent instructions and the agent obeying — is a real remote-code-execution class for any system that reads raw inbound text. Mails.ai runs every inbound message within the plan’s limits through a six-category prompt-injection scanner before it becomes a structured event. The result rides on the event as an injection_score, and high-confidence attacks are flagged quarantined so your agent skips them:

hello.onMessage((event) => {
  // Not scanned (no score) or 0.5 and up: a person decides, before anything reads the body
  if (event.quarantined || typeof event.injection_score !== "number" || event.injection_score >= 0.5) {
    return flagForReview(event);
  }
  // First-contact mail carries an intent when classification is on (paid plans)
  switch (event.intent) {
    case "schedule_demo": return calendar.createEvent({ ...event.entities });
    case "ask_question": return tickets.escalate(event);
  }
});

That’s a summary; the inbound firewall gets its own treatment in the prompt-injection post, including the six attack categories and how to tune the threshold.

We block cold outreach on purpose

Every layer above points the same direction, and it’s worth stating plainly: cold email is not a supported use case on Mails.ai. Our Acceptable Use policy requires that every send has a real recipient relationship, a valid sender identity, an explicit disclosure of why you’re contacting the person, and an unsubscribe honored within 7 days. Organizational addresses only. The reputation classifier scores sends for cold-outreach signals and throttles them; the complaint cron auto-suspends the senders who generate complaints. We’re transactional-and-agent infrastructure — the safe sender for agents that email people who expect to hear from them. The full AI email (aiemail) feature set — per-agent addresses, inbound parsing, and this reputation firewall — is described on the aiemail solutions page.

If your plan is to point an agent at a purchased list and blast, we are the wrong tool, by design. That’s the same design that protects the customers who use us correctly: the firewall that stops your agent from going rogue is the same one that stops everyone else’s from touching your reputation.

What this does not do

Honesty about the edges, because a firewall is a layer, not a guarantee:

• It doesn’t replace your own business rules. The reputation classifier scores complaint risk; it doesn’t know that a particular high-value action needs a second approval. Sandbox your agent’s tools and gate consequential actions yourself.
• It doesn’t catch social engineering. A message with no injection tokens that simply persuades your agent to do the wrong thing scores low on injection and still needs your intent classification and business logic to catch it.
• Single-provider dependency is a known gap. Most cleared sends, and all inbound mail, go through Cloudflare today; our own mail servers carry sign-in links when it can’t, and mail from custom domains and workspace subdomains. A documented multi-vendor failover runbook (Postmark / SparkPost / Brevo, with a roughly four-hour DNS swap path) is planned so a single-provider outage doesn’t take your agent offline — it is not live yet.

The one-line version

Every send is scored and suppression-checked before it leaves. Bad senders auto-suspend at 0.3%, the spam-rate line Gmail’s sender guidelines draw. Reputation is isolated per agent and per workspace, so a rogue tenant is paused before the network feels it. Every inbound is injection-scanned. And cold outreach is blocked by policy and by the classifier. You call send(); the firewall does the rest.

Read the architecture page for the full send and receive pipelines, or the prompt-injection post for the inbound side in depth.