How every send works. And every reply.
Resend-shape transactional API with agent-native features baked in: structured reply events as the primary primitive, per-agent reputation graph, native prompt-injection scanning, and deliverability infrastructure that auto-suspends bad actors before AWS sees them.
API → behavioral classifier → SES → recipient.
Every agent.send()hits a behavioral classifier before it leaves our system — rules plus a lightweight LLM call to score the send for compliance signals (disclosure header, unsubscribe link, business-context match, cold-prospecting pattern). Senders matching cold-prospecting patterns get auto-throttled to 50/day until reputation builds. The classifier is invisible to your code — deliverability infrastructure, not a product axis you choose between.
Cleared sends flow through AWS SES on shared IPs by default. Customers on Scale+ can request a Dedicated IP add-on ($50/mo per IP) for reputation isolation — available on request, provisioned per request, with SES configuration sets, ~14-day auto-warmup, and monitoring.
A per-sender complaint and bounce cron runs every 15 minutes. Any sender crossing 0.3% complaint rate auto-pauses before AWS's 0.5% threshold trips. Your agent's deliverability isn't affected by someone else's behavior. AWS SES underneath; a documented multi-vendor failover runbook (Postmark / SparkPost / Brevo, with a ~4-hour DNS swap path) lands in Phase 2 so a single-provider outage doesn't take your agent offline.
Replies arrive screened, scored, and structured.
Every inbound runs a six-category prompt-injection scan and a reputation check before reaching your agent. You write code against a structured event — injection score and sender reputation always present, intent and entities added when you enable classification.
injection_scoreAlways on. 0–1 prompt-injection risk. Refuse to act on high-score events before reading them.
sender_reputationAlways on. Network-wide reputation graph score for the sender's domain + identity.
intentOpt-in classification. Classified action — schedule_demo, request_pricing, unsubscribe, abuse_attempt, …
entitiesOpt-in classification. Structured data extracted from the body — dates, amounts, names, URLs.
urgencyOpt-in classification. 0–1 score. Threshold for paging your agent vs queueing for batch.
{
"id": "rep_01H8...",
"agent": "sarah",
"from": "lead@example.com",
"subject": "Re: Demo",
"body": "Tuesday at 10am ET works...",
"injection_score": 0.02,
"sender_reputation": 0.91,
// Only present when classification is enabled on this agent:
"intent": "schedule_demo",
"entities": {
"date": "2026-05-14",
"time": "10:00",
"timezone": "America/New_York"
},
"urgency": 0.8
}Per-agent reputation graph.
Every agent on Mails.ai has its own reputation score — built from real engagement signals (reply rate, bounce rate, complaint rate, suppression hits, recipient sender-reputation lookups). The score is workspace-scoped today and designed to propagate across the network as it grows, so bad agents lose verified-agent status network-wide rather than in just one account.
An agent's reputation score is queryable via the mails.get_reputationMCP tool — customers see what we see for their own agents. The reputation score is also baked into the inbound structured reply event (event.sender_reputation), so your agent can refuse to act on senders with low scores even before content scanning kicks in.
Suppression is workspace-scoped today — a complaint or unsubscribe suppresses the sender in your workspace — and the graph is designed to propagate that signal network-wide as the cohort grows. Receiver-side verification API + browser extension ship in Phase 2 so recipients can confirm a sender is a real verified agent.
The technical questions.
How do you handle prompt injection in inbound email?
Every inbound runs a six-category injection scanner (boundary manipulation, system prompt override, data exfiltration, role hijacking, tool invocation, encoding tricks) BEFORE reaching your agent. Output: an injection_score (0–1) on the inbound event. Your agent code refuses to act on high-score events. Microsoft published RCE vulnerabilities via prompt injection in agent frameworks in May 2026. This is no longer optional infrastructure — included on every inbound at the base price.
Can I use my own domain instead of yourcompany.mails.ai?
Phase 2 — Phase 1 ships with subdomains under mails.ai (yourcompany.mails.ai). Custom-domain support is scaffolded in the schema today; the verify-DNS pipeline (DKIM CNAMEs, SPF + DMARC TXT, MX for inbound, SES Identity creation, dashboard wizard) ships with Phase 2. Multi-region rolls out by Phase 3.
What stops a customer from abusing the API to send spam?
Architectural protections, not identity gates. (1) Free tier hard-capped at 3,000 events/month with email verification required. (2) Per-tier hourly + daily send caps in the billing layer. (3) Behavioral classifier auto-throttles cold-pattern senders. (4) Per-sender complaint cron auto-suspends anyone crossing a 0.3% rate — well before AWS's 0.5% threshold. (5) Per-agent reputation graph designed to propagate suppression network-wide as cohort 1 grows — a banned sender loses verified-agent status across every account that has joined. No KYC, no government ID upload — the same friction floor as Resend and the rest of the transactional category.
What if AWS suspends your SES account?
Multi-vendor failover is documented as a launch-hardening requirement — a runbook to stand up backup senders (Postmark, SparkPost, Brevo) with a ~4-hour DNS swap path. The auto-suspend system already monitors per-sender complaint and bounce continuously, pausing anyone crossing 0.3% before AWS sees 0.5%, so reputation damage is contained well before a vendor escalates.
Built for agents.
Self-serve at every volume.
Public API opens Q3 2026. Drop ~6 lines into your agent and ship.
$ npm install @mailsai/sdk