Aiemail — AI Email Infrastructure for Agents

What aiemail infrastructure looks like

Traditional email was built for one-to-one human communication. Marketing platforms added volume sending. Neither model fits an AI agent that needs to send a notification, read the reply, decide what to say next, and do this across hundreds of parallel conversations — each from a distinct, authenticated identity.

Aiemail flips the model: the email address is the agent’s identity, not the company’s. When an agent at support@yourapp.com sends a follow-up, it’s not a blast from a shared pool — it’s a message from that agent’s own reputation context, which lives or dies by that agent’s behavior. The reply comes back as structured JSON, not raw MIME, so the agent can act on it without parsing.

Three things every aiemail setup needs

Regardless of which framework your agents run on, aiemail infrastructure needs to cover three things:

• Per-agent addresses and reputation isolation — one agent’s high send volume or bounce rate should not affect another agent. This requires per-agent sending contexts, not a shared pool.
• Structured inbound parsing — agents can’t reliably parse raw MIME. Replies need to arrive as events with extracted fields: sender, subject, body text, threading references, and attachment metadata.
• Prompt-injection scanning — inbound email from untrusted senders is an attack surface. Any message that reaches an agent’s context window should be scanned for injection attempts before the agent acts on it.

# Every workspace starts with an aiemail address: the agent hello
curl https://api.mails.ai/v1/agents/hello \
  -H "Authorization: Bearer $MAILS_API_KEY"
# → { "id": "agt_…", "name": "hello", "email": "hello@yourapp.mails.ai",
#     "receiving_address": "hello.yourapp@in.mails.ai", … }

# Send an email from that agent
curl https://api.mails.ai/v1/messages \
  -H "Authorization: Bearer $MAILS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "hello",
    "to": "customer@example.com",
    "subject": "Your ticket is resolved",
    "body_text": "We closed ticket #4821. Reply here if anything else comes up."
  }'

# Inbound replies arrive as webhook events — structured, injection-scanned
# {
#   "type": "reply.received",
#   "agent_id": "agt_…",
#   "thread_id": "thrd_abc123",
#   "injection_score": 0.02,
#   "quarantined": false,
#   "data": {
#     "from": { "address": "customer@example.com", "name": null },
#     "subject": "Re: Your ticket is resolved",
#     "extracted_text": "Thanks — one more thing actually..."
#   }
# }

MCP-native aiemail for Claude and Cursor agents

Agents running inside MCP clients — Claude Desktop, Cursor, or any other MCP-enabled environment — can use the Mails.ai MCP server to send and receive email without writing any integration code. The server exposes tools such as mails_send, mails_list_threads, and mails_get_thread that the agent can call directly from its tool use loop.

// claude_desktop_config.json — add the Mails.ai MCP server
{
  "mcpServers": {
    "mails": {
      "command": "npx",
      "args": ["-y", "@mailsai/mcp-server"],
      "env": { "MAILS_API_KEY": "your_key_here" }
    }
  }
}

Once the server is configured, any Claude or Cursor agent in that session can send and read email through tool calls. Each send goes from the agent’s provisioned address with full DKIM and SPF authentication — no shared pool, no reputation bleed from other agents.