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.
Every email you send goes through a classifier. Every reply your agent receives comes back as a structured object. This page explains both pipelines and why they work the way they do.
API → behavioral classifier → our own mail servers → recipient.
Every agent.send()hits a reputation classifier before it leaves our system — rules plus a lightweight LLM call to score the send for complaint-risk signals (recipient relationship, engagement history, content patterns, send-rate anomalies). Senders whose risk score spikes get auto-throttled until reputation builds, and suppression runs at send time so known-bad recipients never get a message. The classifier is invisible to your code — deliverability infrastructure, not a product axis you choose between.
Cleared sends leave on one of two rails. By default they go out over shared infrastructure that is already warm, so an agent's first message inherits a real sending record instead of starting cold. Mail from a custom domain goes over mail servers we own and operate, DKIM-signed with a keypair generated for that domain. Customers on Scale can request a dedicated IP for reputation isolation — worth it at volume, and a handicap below it, since an IP only earns standing from sustained traffic.
A per-sender complaint and bounce cron runs every 15 minutes. Any sender crossing 0.3% complaint rate auto-pauses well inside the 0.5% the industry treats as the red line. Your agent's deliverability isn't affected by someone else's behavior. Owning the second rail outright is the point: if the shared upstream ever refuses us, mail keeps leaving on hardware nobody can switch off for us.
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. Per-agent reputation 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": "user@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: a bad agent loses verified-agent status across all your agents, enforced on every send rather than slipping through on a fresh identity.
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 — a complaint or unsubscribe suppresses the sender across your workspace, enforced on every send. 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?
Yes — on any paid plan. Add your domain in the dashboard and we return the DKIM, SPF and DMARC records to create at your own registrar. Records only: no nameserver move, and if you already publish SPF or DMARC we tell you to merge rather than replace, so your existing mail keeps working. Verify, then create agents on that domain and they send as agent@yourcompany.com, DKIM-signed with a key generated for your domain. One current limitation: custom-domain sends cannot yet reach Outlook and Hotmail recipients — mail from your workspace subdomain is unaffected.
What stops a customer from abusing the API to send spam?
Open signup is not open sending. (1) Signup is self-serve and sending starts immediately — there is no approval queue. What is gated is the CONTENT: every send is classified before it leaves, and cold outreach and bulk marketing are refused at the API with a 422 cold_email_prohibited, with a one-shot independent appeal for false positives. (2) Free tier hard-capped at 3,000 events/month with email verification required. (3) Per-tier hourly + daily send caps in the billing layer. (4) A per-agent reputation classifier scores every send and suppression runs at send time. (5) Per-sender complaint cron auto-suspends anyone crossing a 0.3% rate — well before AWS's 0.5% threshold. (6) Per-agent reputation, isolated per workspace, enforced on every send.
What if your upstream email provider cuts you off?
This is the reason we run our own mail servers as well as a shared upstream rail: custom-domain mail already leaves on hardware we own, which nobody can switch off for us. For the shared rail, a documented failover runbook to stand up backup senders with a roughly four-hour DNS swap is launch-hardening work. And the per-sender complaint and bounce cron pauses anyone crossing 0.3%, well inside the 0.5% the industry treats as the red line, so reputation damage is contained long before an upstream escalates.
Built for agents.
Self-serve in minutes.
The API is live and self-serve. Drop ~6 lines into your agent and ship.
$ npm install @mailsai/sdk