mails.ai

How every send works. And every reply.

Every send goes through a classifier, and every reply your agent receives comes back as a structured object. Here is how both work, and why.

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 early, at a 0.3% complaint rate.

Send pipeline

Sends leave checked, scored, and routed

Every agent.send() is checked before it leaves our system, in two steps:

  • Fixed rules refuse the clear cases outright: prohibited content, text written to steer the classifier, phishing links that warn of a locked or lost account, and cold or spam phrases stacked in one message.
  • An LLM judge then reads the whole message against our cold and bulk policy, more strictly on a first message than on a reply to one the recipient sent.

Suppression runs at send time too, for every recipient in to, cc and bcc, so known-bad recipients never get a message. None of it is hidden from your code: every send’s answer carries classifier_score, and a refused send answers 422 with what it was classified as, and with what confidence.

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 rent 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. Your agent isn’t paused for someone else’s behavior. Running the second rail ourselves is the point: if the shared upstream ever refuses us, mail keeps leaving on servers we rent and run.

Structured inbound

Replies arrive screened, scored, and structured

Every inbound within your plan’s limits 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 to first-contact mail when you enable classification on a paid plan.

  • injection_score

    Always on. 0–1 prompt-injection risk. Refuse to act on high-score events before reading them.

  • sender_reputation

    Always on. 0–1 trust score for whoever sent the message: the classifier’s estimate, or a preset such as 0.3 for a sender that failed authentication.

  • intent

    Opt-in on paid plans, for first-contact mail. A free-form label for what the message asks, such as schedule_demo or request_pricing.

  • entities

    Opt-in on paid plans, for first-contact mail. Key–value data read from the body, such as dates, amounts and names.

  • urgency

    Opt-in on paid plans, for first-contact mail. 0–1 score. Threshold for paging your agent vs queueing for batch.

reply.received.jsonscreened
{
  "id": "evt_01H8...",
  "type": "reply.received",
  "agent_id": "agt_01H8...",
  "thread_id": "thrd_01H8...",
  "injection_score": 0.02,
  "sender_reputation": 0.85,
  "quarantined": false,
  "data": {
    "from": { "address": "user@example.com", "name": "Dana" },
    "subject": "Re: Demo",
    "extracted_text": "Tuesday at 10am ET works..."
  },

  // A reply is never read for intent. Only first-contact
  // mail (message.received) is, for intent, entities and
  // urgency, when the agent's classify_inbound is on.
  "intent": "general_reply"
}

Reputation

Per-agent reputation graph

Every agent on Mails.ai has its own reputation score — built from real engagement signals: its reply, bounce and complaint rates over the last 30 days. Pauses are workspace-scoped too: when a workspace’s mail as a whole crosses the bounce or complaint line, every agent in it pauses, so bad sending can’t slip through on a fresh identity.

An agent’s reputation score is queryable via the mails_get_reputation MCP tool — customers see what we see for their own agents. Inbound events carry a different score, event.sender_reputation: how far to trust whoever wrote in, so your agent can weigh a message by its sender before acting on it.

Suppression is checked on every send. A hard bounce or a spam complaint suppresses the address for every sender on the platform, and an unsubscribe suppresses it for your workspace. Receiver-side verification API + browser extension ship in Phase 2 so recipients can confirm a sender is a real verified agent.

Architecture FAQ

The technical questions

How do you handle prompt injection in inbound email?
Every inbound within the plan’s limits runs a six-category injection scanner (boundary manipulation, system prompt override, data exfiltration, role hijacking, tool invocation, jailbreaks) 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 the shared mails.ai address?
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 shared mails.ai address 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 emails and 3,000 inbound replies a 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. (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 through mail servers we run ourselves (KumoMTA on dedicated servers we rent), not through a third party’s sending API. 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 cron pauses anyone whose complaints cross 0.3% or bounces cross 5%, so reputation damage is contained long before an upstream escalates.

Related

What to read next

Give your first agent an inbox

Free covers 3,000 emails and 3,000 inbound replies a month, with no card. Upgrade when your agents get busy.

Get your API key