Your Agent's Outbox Is Your Next Deliverability Incident

The first time it happens, the on-call engineer is staring at a Gmail Postmaster dashboard that has gone solid red, the support inbox is on fire because customer password resets are landing in spam, and the agent that did this is still running. It sent eighty thousand "personalized follow-ups" between 4 a.m. and 9 a.m. local time, all from the company's primary sending domain, all signed with the same DKIM key the billing system uses. By the time anyone notices, the domain reputation that took three years to build is gone, and so are the next six weeks of inbox placement on every transactional message the company depends on.

Sending email from an agent looks like a one-line tool call. send_email(to, subject, body) is the canonical demo, and every framework ships it as a starter integration. But email is not like other tools. A bad database query rolls back. A bad API call returns an error. A bad batch of email lowers the deliverability of every other email your company sends, for weeks, and there is no transaction to roll back because the messages are already in flight to recipient mailservers that are now writing your domain's reputation history.

The discipline that experienced email teams have built up over twenty years — separate sending streams, dedicated subdomains, per-stream DKIM keys, careful warm-up curves, automatic suppression on bounce-and-complaint feedback — was not built for adversarial scenarios. It was built for the reality that email reputation is a slow-moving, organization-wide shared resource. Agent teams discover this the hard way the first time their sending domain hits a Gmail penalty box, and they discover it because nobody asked deliverability whether agents should be allowed to send email at all.

Email Reputation Is Org-Wide and Hard to Rebuild

A useful first principle: email reputation belongs to the domain, not the application. When your marketing platform sends a campaign from acme.com and gets too many spam complaints, your transactional service sending password resets from acme.com pays the price. Inbox providers like Gmail and Yahoo evaluate reputation at the sending domain (and IP) level, and since 2024 they have enforced that bulk senders — anyone sending five thousand or more messages per day to consumer inboxes — keep spam complaint rates under 0.3% with a recommended target of 0.1%. Cross that threshold and messages stop arriving, not just slow down.

Agent fan-out turns a 0.1% complaint rate into a survivable signal or a domain-killing one depending entirely on how you isolated the sending. If your agent sends from the same domain as your password resets, an agent that earns 1% complaints on its eighty-thousand-message morning has just contributed eight hundred complaints to the shared reputation pool. The transactional system that has been running at 0.05% for years is now bundled with that 1% in the eyes of every receiver. The penalty applies to everything sent from the domain.

This is the part that humans-shipping-email naturally got right and that agent teams systematically get wrong. A marketing operations team would never send a cold-outreach campaign from the same subdomain as account verification emails — that mistake is folkloric. Agent teams, optimizing for "let's just call the SendGrid API," ship that mistake on day one because the agent's send tool points at whatever credentials happened to be on hand. The infrastructure was inherited, not designed.

The Architectural Separation Agents Need Before Their First Send

Before any agent gets a send_email permission, the sending infrastructure should already look like this:

• A dedicated subdomain per agent surface. If your support agent emails customers and your sales agent emails prospects, they should not share mail.acme.com. Use support-bot.acme.com and sales-bot.acme.com. When one of them poisons reputation, the blast radius is contained. The transactional subdomain (the one carrying password resets and receipts) should be off-limits to any agent that doesn't own that exact use case.
• Distinct DKIM key pairs per subdomain. Never share DKIM keys across services. Each subdomain gets its own selector and its own private key, with two selectors maintained per signing domain so you can rotate without downtime. This sounds like ceremony until the day you need to revoke a compromised agent's signing capability without nuking your entire mail flow. With distinct keys, revocation is a DNS change. With shared keys, it's an outage.
• Per-recipient-domain rate limits enforced at the agent boundary. Inbox providers throttle per sender, but they do it silently — your messages just start landing in spam. Enforce the limits yourself before the provider does. A sales agent that wants to email five hundred prospects at gmail.com in the same minute should be rate-limited at fifty per minute by your gateway, queued up, and trickled out. The agent doesn't get to opt out.
• Bounce-and-complaint feedback loops that suspend the agent before the provider does. Subscribe to the provider's webhooks (SendGrid, Mailgun, SES, Postmark all expose them). When the rolling complaint rate for a given agent crosses a tight internal threshold — say 0.05%, well under the 0.3% Gmail enforcement line — auto-suspend that agent's send permission. The agent finds out from a tool error, not from your CEO.

None of this is novel email engineering. It's the playbook every senior deliverability engineer has internalized. The novelty is that agent teams need to build it before the first agent ships, not after the first incident.

Rate Limits Are an Agent Safety Feature, Not Just a Cost Control

Most discussions of agent rate limiting frame it as a cost or runaway-loop concern. For email-as-tool, it's a deliverability concern with a much shorter feedback loop than the CFO's inference bill.

The mental model that helps: every recipient-domain has its own rate budget, and the budget refills on a timescale measured in hours. Forty messages to gmail.com in five minutes is fine. Four thousand in five minutes is a one-way trip to the spam folder for that sender, possibly that subdomain, possibly the parent domain. The receiver decides, and the decision can be sticky for weeks.

So the agent boundary needs three rate-limit dimensions, not one:

• Per agent run (a single user-initiated session). Cap how many messages a single execution can produce, full stop. If a user asks an agent to "follow up with my whole pipeline," ten thousand sends from one prompt should require explicit human confirmation, not happen silently.
• Per agent identity, rolling. A given agent surface should have an hourly and daily budget. When it's exhausted, queue or refuse. This catches the case where one orchestrator spawns many runs and each individual run looks reasonable.
• Per recipient domain. The hardest one to retrofit, because it requires bookkeeping the agent layer doesn't usually do. But it's the one that protects deliverability — the inbox provider rate-limits per domain whether you participate or not.

A good shape for the gateway is: every agent send goes through a single egress service, that service maintains the per-sender / per-recipient-domain counters, and the agent's tool call returns a queued, sent, or rate_limited outcome that the agent has to handle. If you let the agent talk directly to your ESP, none of this exists.

Disclosure, Consent, and the "An AI Sent It" Defense

There's a category of agent-emitted email where the technical deliverability story is fine but the legal one is not. CAN-SPAM (US) requires every commercial email to identify the sender, include a physical address, and offer an unsubscribe mechanism honored within ten business days. CASL (Canada) is stricter — opt-in required before the first message, with penalties up to CAD $10M per organization. GDPR (EU) requires a documented lawful basis. None of these laws have an "an AI sent it" exception.

Agent teams sometimes assume that "we ran an automated workflow" is a meaningful disclosure. Under the actual statutes, it's not. If the recipient acts on a claim made in the email — schedules a call, makes a purchase, signs a contract — the legal liability tracks to the entity whose domain sent it. The fact that no human typed the words is not a defense.

The practical implication is that some content classes need human-in-the-loop confirmation before the send tool fires:

• Outbound to recipients without prior consent (cold sales outreach). At minimum this needs a consent check that scopes who the agent is allowed to email, not just what it's allowed to say.
• Messages that make commitments on behalf of a person. "I've gone ahead and scheduled this for Tuesday" lands differently when a human signed it than when an agent did, and the dispute resolution surface is different too.
• Messages to recipients in jurisdictions with prior-consent regimes. If your recipient list isn't segmented by jurisdiction, the safe-by-default policy is to require consent everywhere.

Internal-only sends (notifications, summaries to authenticated users who opted in) are a different story. The line is whether the recipient is an unsuspecting third party who can't tell from the message that an automated system produced it.

Observability: Every Send Traces Back to a Tool Call, an Agent Run, and a User

When abuse happens — and at sufficient scale, abuse always happens — the question that matters is "who did this." The cheap answer is "the API key did." That's not useful. The investigation dead-ends, the fix is to rotate the key, and the next incident is identical.

The expensive but correct answer requires that every outbound message is enriched, before it leaves the gateway, with:

• The agent identity (which surface, which version of the prompt and tool definitions).
• The agent run ID (which session, which user-facing request triggered this).
• The originating user (the human whose action initiated the chain — even three hops removed).
• The tool call's parameters as the agent issued them, separately from what was actually sent (so you can see if the agent tried to send to a recipient list that the gateway then suppressed).

A common implementation is a custom header on outbound mail (X-Agent-Run-ID) plus a structured log entry in the mail event store keyed by message ID, agent ID, and run ID. When a complaint arrives via the provider's feedback loop, the message ID resolves back through that chain in seconds.

This pays for itself the first time a downstream team asks "did our agent send this customer a duplicate refund confirmation, or was that a human?" Without the trace, you guess. With it, you know.

The Org Seam Where This All Goes Wrong

The deepest failure mode isn't technical — it's structural. Deliverability lives on the messaging or marketing-ops team. Agent infrastructure lives on the platform or AI team. The product team that ships an email-sending agent feature usually talks to neither, because the integration is "just call the SendGrid API."

The fix is to treat email-as-tool the same way you'd treat any high-blast-radius capability: a permission that requires a sign-off from the team that owns the consequences. Before an agent surface gets a send-mail permission, deliverability reviews the subdomain isolation, the rate-limit configuration, the suppression list integration, and the content classes the agent will produce. They have veto power. They have it because they're the ones who answer the page when the domain reputation craters, and the page goes to them either way.

The infrastructure pieces — subdomains, DKIM keys, gateway, observability — are all things deliverability engineers have built before. What's new is the threat model: a non-deterministic actor with an API key, fanning out at machine speed, capable of producing content that looks plausibly human and might or might not respect the hints in your system prompt about volume. The defenses are old. The need for them, before the agent's first send, is new.

The unglamorous truth is that experienced email teams exist for reasons agent teams discover the hard way. The cheap version of this lesson is reading their playbook. The expensive version is the eighty-thousand-message morning, the red Postmaster dashboard, and the six weeks of degraded inbox placement that follow.