Giving AI agents their own email inboxes: why reciprocal reply karma failed and inline classification worked

If you give an autonomous agent an email address, you run into an immediate infrastructure problem: domain reputation.

If you give every agent its own custom domain, setup is painful (DNS, SPF, DKIM, DMARC, warming up IPs). If you let agents share a common domain, a single rogue script sending cold outreach or abusive emails will get the domain blacklisted on major providers within hours.

When we started building AgentMail, the initial defense was a reciprocal karma system. The thesis seemed clever on paper: 1. Sending an email costs karma. 2. Receiving a reply from a trusted personal provider (Gmail, Outlook, iCloud) earns karma back. 3. An agent that has genuine two-way conversations sustains itself forever. An agent that blasts unsolicited cold emails runs out of credits and gets shut off.

In production, this broke down in three specific ways:

First, legitimate agents don't always get replies. An agent sending daily server health digests, user onboarding summaries, or market briefs does valuable work, but nobody replies to an automated status report. It constantly ran out of karma unless users artificially emailed it back.

Second, karma was blind to initial damage. Giving a new user 100 free credits meant an attacker could still send 100 deceptive emails before hitting zero. In email deliverability, 100 bad emails from a shared domain is plenty to get flagged.

Third, people immediately found gaming vectors on the inbound side. We had users spinning up temporary addresses just to receive verification codes and password resets for services like Discord or retail loyalty programs, collecting inbound karma without doing any real conversation.

The fix was stripping out the reciprocal earning game and replacing it with two simpler primitives: 1. Flat send quotas. 2. Synchronous inline classification on every outbound message.

Before any email leaves the queue to Resend, we pass the subject, body, and recipient through a lightweight classification model (we use JEV, a sub-second decision model). It checks whether the email is genuine communication or abusive bulk outreach. If flagged, the send is rejected at the API level with an explicit 400 error.

The latency overhead is negligible compared to SMTP transit times, but the difference in domain health is night and day.

The takeaway for anyone building agent comms: don't rely on economic feedback loops (like reciprocal reply credits) to govern safety. Malicious behavior happens in the first few turns, and legitimate bot behavior is often asymmetrical. Synchronous payload inspection at the tool boundary is much more reliable.