DEV Community: Yopie Suryadi

Email API for AI Agents: What to Evaluate Before You Pick One

Yopie Suryadi — Mon, 30 Mar 2026 08:32:18 +0000

Hook

Most developers discover the limits of their email API only after something breaks in production. An agent sends a follow-up reply that lands outside the original thread. An inbound message arrives at a webhook endpoint and disappears with no way to replay it. A compliance audit asks for an audit log that was never generated. By then, migrating to a different provider is painful.

Choosing an email API for an AI agent is a different problem from choosing one for transactional email. A welcome email does not need to receive replies. An AI agent does. The decision criteria are not the same, and most comparison guides available today were written with transactional use cases in mind.

The Problem

The standard comparison framework for email APIs focuses on deliverability, latency, and price per message. Those things matter, but they answer the wrong question for agents. When an agent manages an ongoing support conversation, a sales sequence, or an approval workflow, the relevant questions are: can the agent receive the reply, does the reply arrive in the right thread context, and what happens if the event notification fails?

A billion-request benchmark by Knock found that SendGrid's median API response time is 22ms, Postmark's is 33ms, and Resend's is 79ms. Those numbers matter for transactional throughput. But an agent waiting on a human reply is not measuring latency in milliseconds. It is measuring reliability over minutes and hours.

The industry has also converged on a comparison model that treats inbound email as a secondary feature, something bolted on via webhook rather than designed as a core primitive. AgentMail's 2026 comparison of the top providers found that most handle inbound email through stateless webhook routing with no persistent storage or threading. For transactional email, that is fine. For an agent that needs to read a reply, correlate it with a prior message, and continue a conversation, it is a significant gap.

The Insight

The right question to ask before picking an email API for an agent is not "how fast is the send?" It is "can this API handle the full conversation loop?" That loop has seven distinct requirements, and providers differ on almost every one of them.

The Evaluation Framework

1. Two-Way vs. Send-Only

The most fundamental distinction. Send-only providers (AWS SES at its core, older SendGrid configurations) give you an endpoint for outbound email and nothing more. Two-way providers give you both a send path and a receive path.

The difference in architecture is significant. AgentMail's comparison found that SendGrid's inbound parse is stateless (no persistent storage, no threading) and Mailgun routes inbound email via webhook with no persistent inbox. Resend added inbound webhook support in 2025. AWS SES requires additional AWS infrastructure (S3, Lambda, SNS) to do anything useful with a received message.

For agents, the question is whether you want to build and maintain that additional layer yourself or use an API that treats two-way communication as a first-class primitive.

An API designed for the full conversation loop looks like this:

import { MailbotClient } from '@yopiesuryadi/mailbot-sdk';
const client = new MailbotClient({ apiKey: 'mb_test_xxx' });

// An email API for agents should handle the full cycle: send, receive, reply in thread
const inbox = await client.inboxes.create({ name: 'support-agent' });
const inbound = await client.messages.waitFor({ inboxId: inbox.id, direction: 'inbound', timeoutMs: 30000 });
await client.messages.reply({ inboxId: inbox.id, messageId: inbound.id, bodyText: 'Thanks for reaching out.' });

The waitFor method blocks until a reply arrives, which is exactly the pattern an agent running a turn needs.

2. MTA Ownership vs. Rented Infrastructure

Who controls the mail transfer agent matters for deliverability configuration and high-volume cost. AWS SES runs its own MTA and prices per message ($0.10 per 1,000 emails sent and $0.10 per 1,000 received, per AgentMail's pricing table). SendGrid and Postmark operate their own infrastructure. Resend routes through established MTAs.

Providers that own their MTA can offer dedicated IPs, custom warm-up, and more direct control over reputation. Providers that abstract the MTA away trade that control for easier onboarding. For agents sending at modest volume (under 50,000 messages per month), MTA ownership is less important than the API surface above it. In regulated industries, dedicated IP configuration and reputation isolation become meaningful.

3. Thread Handling

Email threading is governed by three headers: Message-ID, In-Reply-To, and References. RFC 2822 specifies that a reply's References field should include the parent's References plus the parent's Message-ID. When this chain is managed correctly, every major email client preserves the thread. When it breaks, replies land as new conversations.

Managing this manually in application code is straightforward for the first reply. It becomes error-prone after three or four turns when the References header needs to carry the full ancestry. An API that handles threading automatically removes this class of bug entirely.

AgentMail handles threading via built-in API support with automatic header management. SendGrid and SES do not manage thread state; the application is responsible for passing the correct headers on every reply. Resend's threading behavior is not documented as an automatic feature.

4. Event Notification Reliability

When an inbound message triggers an event, what happens if your endpoint is down? This is where providers diverge significantly.

Mailtrap's flexibility comparison found that retry windows vary considerably across providers:

Provider	Retry window
SendGrid	72 hours
Mailtrap	24 hours
Postmark	12 hours
Mailgun	8 hours
Resend	User-managed

Beyond retry duration, the question is whether you can replay a specific event after the window expires. For agents that need to recover from a missed notification without re-triggering the full workflow, event replay is a meaningful capability.

5. Custom Domains with Full DNS Setup

An AI agent sending from agent@support.yourcompany.com requires a custom domain with SPF, DKIM, and ideally DMARC records configured. The question is how much of that setup the provider automates.

All major providers support custom domains. The differences are in the verification flow, the time required, and whether the provider guides you through the full DNS record set or leaves gaps. AgentMail notes that SendGrid's time to first email is 10 to 15 minutes, Mailgun's is similar, and AWS SES requires sandbox approval that takes 24 to 48 hours for new users.

For agents deployed in enterprise environments, the ability to verify multiple domains and issue separate credentials per domain matters for tenant isolation.

6. Compliance Readiness

Enterprise buyers commonly ask for SOC 2 Type II, ISO 27001, or equivalent certifications. For agents handling customer communication, audit logs (who sent what, when, and to whom) are also relevant.

This criterion is often invisible until a procurement process or security review surfaces it. Checking compliance posture before you build is faster than retrofitting.

7. Pricing Model

Three pricing models exist: per-message, per-inbox (flat rate), and hybrid.

Per-message pricing (AWS SES at $0.10/1,000) is economical at high outbound volume but can become expensive if agents are also receiving large volumes. Per-inbox pricing (AgentMail's model, starting at $20/month for 10 inboxes and 10,000 messages) is predictable for deployments with a fixed number of agent inboxes. Flat-rate models (Postmark, Resend's Pro tier) are predictable up to a message ceiling, then require a tier upgrade.

For agents, the relevant calculation is the ratio of inbound to outbound messages. A support agent that receives 1,000 messages and sends 1,000 replies is doing 2,000 message operations. A per-message model bills both directions if the provider supports inbound; a per-inbox model does not change with message volume within the tier.

Comparison Table

The table below summarizes each provider across the seven criteria. "Native" means the feature is a first-class API primitive. "Webhook" means the feature requires your application to handle state and persistence.

Criterion	SendGrid	AWS SES	Resend	Postmark	AgentMail	mailbot
Two-way (inbound)	Webhook, stateless	Via S3/Lambda/SNS	Webhook (since 2025)	Limited	Native inbox	Native inbox
MTA ownership	Yes (Twilio)	Yes (AWS)	Abstracted	Yes	Abstracted	Yes
Auto thread handling	No	No	Not documented	No	Yes	Yes
Event retry window	72 hours	Not specified	User-managed	12 hours	Configurable	Configurable
Custom domains	Yes	Yes	Yes	Yes	Yes	Yes
Compliance docs	SOC 2	SOC 2, ISO 27001	SOC 2	SOC 2	Not published	In progress
Pricing model	Per-message	Per-message	Per-message tiers	Per-message tiers	Per-inbox tiers	Per-inbox tiers

A few notes on reading this table honestly. SendGrid's 22ms p50 latency is the best measured across any provider in the Knock benchmark, and its 72-hour retry window is the longest available for event notifications. AWS SES has the most consistent error rates of any provider measured, with most days below 0.01%. These are real advantages for high-volume transactional use cases.

The providers that score highest on the agent-specific criteria (two-way, auto threading, event replay) are the newer ones: AgentMail and mailbot. Both are earlier-stage than SendGrid or SES, which means a tradeoff: more agent-native features, less operational history.

Where mailbot Stands

mailbot is designed around the agent use case. Inboxes are programmable resources. Threads are tracked automatically with correct In-Reply-To and References headers on every reply. Event notifications include replay via client.events.replay(eventId). Compliance tooling is available via client.compliance.readiness() and client.auditLog.list(). Pricing is per-inbox, not per-message.

The honest caveat: mailbot is younger than SendGrid or Postmark, which means less operational track record at the top end of volume. If you are migrating an existing high-volume transactional email pipeline, that history matters. If you are building a new agent workflow from scratch, the agent-native API surface is a meaningful starting point advantage.

Close

Not every agent needs all seven criteria. A simple outbound notification agent only needs criteria 2 and 5. An agent managing multi-turn customer conversations needs all seven, and a gap in any one of them will surface as a bug in production.

The providers that dominated email in 2015 were built for a world where email was a one-way notification channel. Agent workflows are a different problem, and the evaluation should reflect that. The mailbot comparison page maps each criterion to a working implementation.

Sources

AgentMail, "5 Best Email API For Developers Compared [2026]" (2026-01-27): https://www.agentmail.to/blog/5-best-email-api-for-developers-compared-2026
Jeff Everhart / Knock via Dev.to, "We analyzed a billion email API requests: here's what we learned" (2026-03-12): https://dev.to/knocklabs/we-analyzed-a-billion-email-api-requests-heres-what-we-learned-j39
Ivan Djuric / Mailtrap, "5 Best Email APIs: Flexibility Comparison [2026]" (2026-03-13): https://mailtrap.io/blog/email-api-flexibility/
Postmark, "Best Email API" (2026-01-12): https://postmarkapp.com/blog/best-email-api
Reddit r/webdev, "Email API benchmarks for SendGrid, Amazon SES...": https://www.reddit.com/r/webdev/comments/1rrxxs5/email_api_benchmarks_for_sendgrid_amazon_ses/
IETF RFC 2822, "Internet Message Format": https://datatracker.ietf.org/doc/html/rfc2822

Why Your AI Agent Loses Context After Three Email Replies

Yopie Suryadi — Mon, 30 Mar 2026 08:32:13 +0000

Your AI email agent handles the first two replies flawlessly. It reads the original message, drafts a thoughtful response, and sends it on time. Then reply three arrives and something quietly goes wrong. The agent responds to the wrong topic. It asks a question the customer already answered. It loses the thread entirely.

This is not a reasoning failure. The underlying language model did not forget anything. The problem is infrastructure: the email headers that stitch a conversation together are either missing, truncated, or misread by the receiving client. By the time a thread hits three or more messages deep, the structural glue that email relies on has often already snapped.

How Email Threads Are Actually Built

Every email message carries a unique identifier called a Message-ID. When you reply to that message, your client adds two headers: In-Reply-To, which holds the parent message's Message-ID, and References, which holds the entire ancestry chain.

As defined by RFC 2822 (IETF), the References header must equal the parent message's own References field plus the parent's Message-ID appended at the end. Each new reply extends this chain. So by message four, the References header contains three Message-ID values, each pointing one step further back.

This chain is how email clients group messages into a visible thread. Without it, each reply appears as a disconnected new conversation. Different email clients handle threading differently: Gmail uses References together with In-Reply-To and subject matching, Outlook leans primarily on References, and Apple Mail follows RFC 2822 most closely. Omitting the References header outright breaks threads after three or more messages in every major client.

Why the Break Happens at Reply Three (Not Reply One or Two)

The first reply only needs In-Reply-To. Many email clients and APIs get that right automatically. The second reply needs both In-Reply-To and a short References chain. Most still manage this correctly. But the third reply requires your sending code to correctly read and forward the entire References chain from the previous message, append the previous message's Message-ID, and then set the new In-Reply-To to point at that same previous message.

If any step in that chain is wrong, not just the most recent one, clients diverge. According to Alibaba LifeTips research on Outlook threading, Outlook splits 31.4% of threads that Gmail preserves intact. Outlook's threading is folder-bound and more sensitive to subject-line changes, while Gmail treats subject-matching as a fallback rather than a primary signal. A thread that looks continuous in Gmail may already be fragmented in Outlook before your agent sees it.

This is the compound problem. Your agent does not receive a clean, continuous conversation object. It receives fragments: some messages grouped, some orphaned, some duplicated across quoted footers. As one developer put it in a discussion on r/AI_Agents, roughly 80% of the tokens in a real email thread are duplicate quotes and footers, not new information. The same thread "evolves into a substantial infrastructure project" once you try to use it reliably in production.

The Token Waste and Context Collapse Problem

Before the headers even matter, there is a tokenization problem. When your agent fetches a thread naively, it is likely reading the same content four or five times because each reply quotes the previous one in full. The new information in message five may be two sentences. The payload you are feeding your agent may be four thousand tokens of redundant history.

This is a practical, measurable problem. The developer thread on r/AI_Agents describes direct measurements: roughly 80% of tokens in a real email thread are duplicate quotes, signatures, and footers. Your agent is spending most of its context window processing information it has already seen.

Then, when the References chain is broken, your agent cannot reliably determine which message is the true root of the conversation, which messages have already been handled, or what the correct In-Reply-To value for its outgoing reply should be. At that point, even a perfectly capable reasoning engine will produce incoherent replies because the input it received was incoherent. The agent did not fail. The input pipeline failed.

According to the Composio 2025 AI Agent Report, integration failure rather than language model failure is the primary cause of AI agent production failures. Email threading is a textbook example of this pattern. The model is fine. The plumbing is broken.

The Wrong Way: Manual Header Construction

Many developers, when building email reply logic, reach for client.messages.send() with manually constructed headers. It looks like this:

import { MailbotClient } from '@yopiesuryadi/mailbot-sdk';
const client = new MailbotClient({ apiKey: 'mb_test_xxx' });

// WRONG: manually constructing threading headers
const response = await client.messages.send({
  inboxId: 'inbox_abc123',
  to: [{ email: 'customer@example.com' }],
  subject: 'Re: Your support request',
  bodyText: 'Thank you for your message...',
  headers: {
    'In-Reply-To': '<original-message-id@mail.example.com>',
    'References': '<original-message-id@mail.example.com>',
    // You are now responsible for reading and appending the full References chain
    // Get this wrong once and Outlook splits the thread. Forever.
  },
});

The problem with this approach is not that it is hard to write. It is that it requires you to correctly read the full References chain from the previous message, append the new Message-ID, and keep this logic accurate across every environment that may format or truncate headers differently. Miss it once on reply three, and your agent is now operating on a broken thread for every reply that follows.

The Right Way: client.messages.reply()

The client.messages.reply() method exists specifically to handle this. It reads the correct Message-ID from the parent message, builds the full References chain by reading the parent's own References header, and sets both In-Reply-To and References correctly before sending. You do not touch headers at all.

import { MailbotClient } from '@yopiesuryadi/mailbot-sdk';
const client = new MailbotClient({ apiKey: 'mb_test_xxx' });

// RIGHT: let the SDK handle threading headers automatically
const reply = await client.messages.reply({
  inboxId: 'inbox_abc123',
  messageId: 'msg_xyz789', // the specific message you are replying to
  bodyText: 'Thank you for following up. Here is what we found...',
});

That single call handles RFC 2822 compliance, correct References chain construction, and In-Reply-To assignment. No manual header management, no risk of chain truncation.

Fetching Full Thread Context Before You Reply

The other half of the problem is making sure your agent actually reads the full thread before composing a reply. The correct pattern is to call client.threads.get() first, which returns the complete message history for the thread as a structured object, then pass that context to your agent, and only then call client.messages.reply().

import { MailbotClient } from '@yopiesuryadi/mailbot-sdk';
const client = new MailbotClient({ apiKey: 'mb_test_xxx' });

// Step 1: Get the full thread so your agent has complete context
const thread = await client.threads.get(inboxId, threadId);

// Step 2: Extract message bodies in order (skip duplicate quoted sections)
const messages = thread.messages.map((msg) => ({
  from: msg.from,
  date: msg.date,
  body: msg.bodyText,
}));

// Step 3: Feed structured thread to your agent, get a reply draft
const replyDraft = await yourAgentLogic(messages);

// Step 4: Reply using the SDK so headers are handled correctly
const sent = await client.messages.reply({
  inboxId,
  messageId: thread.messages.at(-1)?.id, // reply to the most recent message
  bodyText: replyDraft,
});

This pattern gives your agent structured, deduplicated context rather than a raw chain of quoted bodies. It also ensures the reply is attached to the correct message in the thread, which is what determines whether Gmail, Outlook, and Apple Mail all show it in the right place. The deduplication step in particular matters: by passing only the unique message bodies in chronological order instead of four thousand tokens of repeated quoted text, your reasoning engine operates on clean input. Your agent processes less and produces more accurate output.

What Consistent Threading Actually Unlocks

When your agent maintains thread continuity reliably, several things improve at once. The conversation history your agent reads is accurate instead of fragmented. Reply rates from customers tend to rise because responses feel contextually aware rather than generic. Thread-level event history through client.events.list(threadId) becomes useful for auditing what the agent did and when.

More importantly, you stop debugging ghost threads in Outlook and wondering why a customer says "I already answered that." This much is clear: the clients that handle threading well do so because they construct headers by the spec. The ones that break threads do so because they take shortcuts. Your agent should not take shortcuts either.

Email is still the dominant communication channel for business workflows. An AI agent that loses thread context after three replies is not a production agent. It is a prototype that creates cleanup work for your team. Getting the infrastructure right is not optional, and as the r/AI_Agents community noted, most teams learn this the hard way after shipping.

You do not have to.

Start building thread-aware email agents at getmail.bot/docs/getting-started.

Sources

How to Give Your AI Agent a Real Email Inbox with MCP

Yopie Suryadi — Sun, 29 Mar 2026 16:55:58 +0000

Most email MCP servers let your AI client send email. That is the easy half. The harder half is letting it receive replies, track delivery events, and maintain conversation context across a thread. This tutorial shows you how to wire both halves together using the mailbot MCP server.

If you have searched for "MCP email server" or "email MCP server" and landed on tutorials that only cover outbound, you already know the gap. MailerCheck's roundup of 6 email MCP servers confirms that the only two-way option in the list is a Gmail relay through Zapier. For developers who want a purpose-built inbox that their AI agent can own end to end, that is a meaningful gap.

This tutorial fills it. By the end, your MCP-compatible AI client will be able to create an inbox, send email from it, read replies, and check delivery events.

What You Will Build

An AI agent workflow backed by a real mailbot inbox. Your AI client exposes 13 MCP tools that map directly to mailbot's API surface: inbox management, message sending, reply handling, thread reading, and delivery event inspection. You type a natural language instruction, and the client calls the right tool.

This is useful for agentic tasks like: send a follow-up to anyone who replied to yesterday's campaign, check whether my outbound message was delivered, or create a throwaway inbox for this test scenario and clean it up when done.

Prerequisites

Before you start:

Node.js 18 or later installed on your machine (the MCP server runs via npx)
An MCP-compatible AI desktop client that supports external MCP servers via a JSON config file
A mailbot account and API key from getmail.bot

No local build step required. The package ships prebuilt to npm.

Step 1: Understand How MCP Servers Work

MCP (Model Context Protocol) lets an AI client call external tools in the same way a developer calls an API. According to the official MCP documentation, servers expose tools as typed functions. When you send a message to your AI client, it inspects the available tools, decides which one matches your intent, and executes it. The result comes back as context for the next response.

For email, this means your AI client becomes a first-class email actor rather than a text generator that happens to mention email addresses. It can actually create inboxes, send messages, and read what comes back.

Step 2: Install the mailbot MCP Server

No manual install is required. The package runs on demand via npx, so your AI client fetches and executes it automatically on first launch.

The package is published at @yopiesuryadi/mailbot-mcp on npm. If you want to inspect the package before running it, you can pull it manually:

npx @yopiesuryadi/mailbot-mcp --help

This confirms the package resolves and prints the available tool list.

Step 3: Configure the MCP Server in Your AI Client

Your MCP-compatible AI client reads a JSON config file to discover external servers. The exact file location varies by client. Common locations:

OS	Typical config path
macOS	`~/Library/Application Support/<ClientName>/config.json`
Windows	`%APPDATA%\<ClientName>\config.json`

Add the following block to your client's MCP servers config:

{
  "mcpServers": {
    "mailbot": {
      "command": "npx",
      "args": ["-y", "@yopiesuryadi/mailbot-mcp"],
      "env": {
        "MAILBOT_API_KEY": "mb_test_xxx"
      }
    }
  }
}

Replace mb_test_xxx with your actual mailbot API key from your account dashboard.

Save the file and restart your AI client. If the client has a tools or connectors panel, you should see "mailbot" listed with its 13 available tools. That confirms the server is running and connected.

Note: the MCP server is at v1 and has not been tested across every AI client configuration. If your client does not surface the tools after restart, check that the config JSON is valid and that Node.js is accessible on your system PATH.

Step 4: Create an Inbox via MCP

Once the server is connected, you can talk to your AI client in plain language. To create a new inbox, try a prompt like:

Create a new mailbot inbox named "support-test"

Your AI client will call the create_inbox tool, which maps to client.inboxes.create in the mailbot SDK. The tool returns the inbox details including its assigned email address.

You can list existing inboxes with:

List my mailbot inboxes

And retrieve details for a specific one with:

Get the inbox with ID inbox_abc123

Step 5: Send Email via MCP

With an inbox created, sending is one instruction away:

Send an email from my support-test inbox to recipient@example.com with the subject "Hello from mailbot MCP" and a plain text body saying "This was sent by my AI agent."

The client calls the send_message tool under the hood. This is meaningfully different from send-only email MCP servers like Mailtrap's MCP integration, which only expose a single outbound send tool. With mailbot, the same session that sends can also receive and inspect.

You can also send HTML:

Send an HTML email from support-test to recipient@example.com. Subject: "Welcome". Body: a simple HTML welcome message with a bold heading.

Step 6: Receive and Read Email via MCP

When a reply arrives at your mailbot inbox, your AI client can read it:

List the latest messages in my support-test inbox

This calls list_messages and returns subject, sender, snippet, and thread ID for each message. To read a full message:

Get the full content of message msg_xyz789

To search across messages:

Search my support-test inbox for messages from sender@example.com

The search_messages tool accepts sender, subject keywords, date ranges, and label filters, so your agent can do targeted retrieval without reading the entire inbox.

If you are building an automated flow and need to wait for a reply before proceeding, the wait_for_message tool (backed by client.messages.waitFor) polls until a matching message arrives or a timeout is reached. This is useful for test flows where you send a message and need to assert on the reply.

Step 7: Check Delivery Events via MCP

Sending a message is the start, not the end. Your AI client can also inspect what happened to each message after delivery.

Check the delivery events for thread thread_abc123

This calls list_events for the thread, returning a timeline of events (queued, delivered, opened, bounced, and so on). You can also retrieve a single event:

Get event details for event evt_123

This is useful for agentic tasks like: "Send a follow-up only if the first message was delivered but not opened." Your agent can check the event timeline, make a conditional decision, and act without you writing any conditional logic manually.

Step 8: Organize with Labels and Threads via MCP

The 13 mailbot MCP tools also cover thread reading and label management. To view a full conversation thread:

Show me the full thread for thread_abc123

To label a message for downstream filtering:

Add the label "needs-followup" to message msg_xyz789

Labels work as lightweight state markers that persist on the message, so other tools or agents in your workflow can filter by them later.

What Is Next

This tutorial covered the core loop: create inbox, send, receive, inspect events. The mailbot MCP server exposes the same API surface as the SDK, so everything in the mailbot documentation applies to what your AI client can do.

A few directions to explore from here:

Event notifications: Set up a webhook to push inbound messages to your own endpoint, so your agent reacts in real time rather than polling.
Domain verification: Verify a custom sending domain so outbound messages use your own address.
Compliance checks: Use the compliance tools to run readiness checks before sending to a new list.

The MCP integration is v1. Feedback from real usage is how it improves. If you run into edge cases with your specific AI client configuration, the documentation is the right place to start: getmail.bot/docs/getting-started.

Sources

Building an AI Support Agent That Sends Real Email (Not Just Chat)

Yopie Suryadi — Sun, 29 Mar 2026 16:55:54 +0000

The Problem Is Not the AI

Most teams building AI support agents hit the same wall. The AI classification works fine in testing. The prompt responses look reasonable. But when they try to connect it to actual email, things fall apart fast. The inbox is shared with marketing sends. There is no way to listen for inbound messages without polling. Replies break the thread. Nobody knows whether the automated response was actually delivered.

As one developer put it in a thread on r/AI_Agents: "What begins as simple email context evolves into a substantial infrastructure project." That quote describes the experience of most teams within the first week of building a real support agent, not a demo.

The Composio AI Agent Report is direct about the root cause: integration failure, not model failure, is the number one reason AI agent pilots fail in production. The report identifies "brittle connectors" as a specific trap, where one-off integrations work in isolation but break the moment real email volume hits, or when email clients format messages differently than expected.

This post is a comprehensive walkthrough for building a support agent that avoids those failure modes. It covers everything from creating a dedicated inbox, to listening for inbound messages, to classifying intent, to confirming delivery, to escalating uncertain cases to a human reviewer. If you want the 30-minute quickstart version, the existing Build an Email AI Agent in 30 Minutes post covers the basics. This post is for teams who want something production-ready.

Why Dedicated Infrastructure Matters

A support agent needs its own inbox, its own event notification listener, and a reliable threading model. Sharing an inbox with other email processes introduces noise that defeats classification before the AI ever sees a message.

Instantly's email triage research found that 70 to 80 percent of routine support emails can be classified and responded to automatically, but only when the classification system has clean, well-scoped input. Routing all company email through one inbox and asking an agent to sort it out is not a clean input.

It is worth noting that we run mailbot's own support inbox this way. The architecture described in this post is not hypothetical. You can read about it in the mailbot dogfooding post, which covers how we use our own API to handle support at the company level.

Step 1: Create a Dedicated Inbox

Start by initializing the SDK and creating an inbox specifically for support:

import { MailbotClient } from '@yopiesuryadi/mailbot-sdk';

const client = new MailbotClient({ apiKey: 'mb_test_xxx' });

const inbox = await client.inboxes.create({ name: 'support-agent' });
console.log('Inbox created:', inbox.id, inbox.address);

This gives you an isolated address (something like support-agent@yourdomain.getmail.bot) that receives only inbound support email. No newsletter noise, no transactional sends from other systems. Your classifier gets a clean channel.

Step 2: Register an Event Notification Listener

Polling an inbox on an interval is the third failure trap identified in the Composio report, labeled the "Polling Tax." It wastes resources, introduces latency, and adds another surface where things can fail silently.

const hook = await client.webhooks.create({
  url: 'https://your-agent.example.com/inbound',
  events: ['message.inbound'],
});
// Note: Webhooks fire for all inboxes. Filter by inboxId in your /inbound handler.
console.log('Listener registered:', hook.id);

Your endpoint at /inbound will now receive a POST payload every time a new message arrives in the support inbox. No polling required.

Step 3: Receive and Read the Inbound Message

When your endpoint receives a notification, it includes the inboxId and messageId. Use those to fetch the full message and the thread context:

app.post('/inbound', async (req, res) => {
  const { inboxId, messageId, threadId } = req.body;

  // Fetch the individual message
  const message = await client.messages.get(inboxId, messageId);

  // Fetch the full thread for context
  const thread = await client.threads.get(inboxId, threadId);

  // Pass to your classifier
  const intent = await classifyIntent(message.subject, message.bodyText, thread);

  await handleIntent(intent, inboxId, messageId);

  res.sendStatus(200);
});

Fetching the full thread via client.threads.get() is important for repeat customers or ongoing issues. A support ticket about a billing error in the third reply looks very different without the first two messages. Thread context prevents your classifier from treating it as a fresh, unrelated inquiry.

Step 4: Classify Intent and Reply

Your AI classifier receives the message text and thread context and returns an intent label plus a confidence score. The exact implementation of your classifier is up to you. The important part is that this function returns something structured:

async function classifyIntent(subject: string, body: string, thread: any) {
  // Call your AI classification layer here
  // Return: { intent: string, confidence: number, suggestedReply: string }
}

Instantly's research shows that 70 to 80 percent of routine support emails fall into a small set of intent categories: order status, refund request, account access, and general inquiry. A well-tuned classifier handles the bulk of volume without human review.

When confidence is above your threshold, reply in the same thread:

async function handleIntent(intent: any, inboxId: string, messageId: string) {
  if (intent.confidence >= 0.80) {
    await client.messages.reply({
      inboxId,
      messageId,
      bodyText: intent.suggestedReply,
    });
  } else {
    await escalateToHuman(inboxId, messageId, intent);
  }
}

Using client.messages.reply() keeps the response inside the original thread. The customer's email client shows it as a continuation of the same conversation, not a new message. This matters both for the customer experience and for the threading chain that future AI classification will need.

Step 5: Verify Delivery with the Event Timeline

Sending a reply is not the same as delivering it. Network issues, misconfigured DNS, and provider-side throttling can all cause a message to leave your system without reaching the recipient.

Use client.engagement.messageTimeline() to confirm the delivery path after sending:

const timeline = await client.engagement.messageTimeline(messageId);

const delivered = timeline.events.some(e => e.type === 'delivered');
const opened = timeline.events.some(e => e.type === 'opened');

if (!delivered) {
  console.warn('Reply not confirmed delivered. Flagging for review.');
  // Trigger retry or alert here
}

This is the kind of operational check that separates a demo agent from a production one. If a customer does not receive the reply, the next message they send will be an escalation in frustration. Catching delivery failures early gives you time to intervene before that happens.

Step 6: Escalate to a Human When Confidence Is Low

When the classifier's confidence falls below your threshold, the message should go to a human reviewer rather than being sent an automated reply that may be wrong or tone-deaf.

The pattern has two parts: label the message so it appears in the escalation queue, then notify a human agent via a separate inbox.

async function escalateToHuman(inboxId: string, messageId: string, intent: any) {
  // Label the message in the support inbox
  await client.messages.updateLabels({
    inboxId,
    messageId,
    labels: ['escalated'],
  });

  // Send notification to human agent inbox
  await client.messages.send({
    inboxId: HUMAN_AGENT_INBOX_ID,
    to: 'support-team@yourcompany.com',
    subject: 'Escalation Required: Low Confidence Classification',
    bodyText: `Message ID ${messageId} was classified as "${intent.intent}" with confidence ${intent.confidence}. Please review and respond manually.`,
  });
}

This pattern is consistent with findings from Eesel AI's analysis of human handoff best practices, which identifies confidence thresholds and intent-specific triggers as the most reliable escalation signals. Keywords like "refund," "cancel," or "legal" warrant a lower threshold regardless of overall confidence.

The label approach keeps your support inbox organized. Messages labeled escalated appear separately from those the agent handled autonomously. You get a natural audit trail without building a separate database.

Step 7: Check Compliance Readiness Before Going Live

Before routing real customer email through the agent, run a compliance readiness check on the inbox:

const readiness = await client.compliance.readiness(inbox.id);
console.log('Compliance status:', readiness);

This checks that the inbox has proper configuration for unsubscribe handling, opt-out tracking, and other requirements that apply to automated email senders. Running this before go-live avoids situations where a compliance gap surfaces only after you have been sending at volume.

Putting It Together

The full architecture looks like this:

A dedicated support inbox receives inbound email cleanly.
An event notification listener fires your handler on each new message.
Your handler fetches the message and full thread context.
Your AI classifier returns an intent and confidence score.
High-confidence intents trigger an automated reply via client.messages.reply().
The event timeline confirms delivery after each send.
Low-confidence intents are labeled escalated and routed to a human agent via a second inbox.
Compliance readiness is verified before production launch.

We built and run this exact pattern for mailbot's own support. The dogfooding post goes into detail on how the live system handles real volume and where we had to adjust our confidence thresholds over time.

The Infrastructure Is the Product

The AI classifier is the part that gets the most attention in conversations about AI support agents. But as the r/AI_Agents community has found directly, the classifier is rarely where things break. The email infrastructure underneath it is where fragility lives: brittle polling loops, lost thread context, unconfirmed delivery, no human fallback.

The steps in this guide address each of those failure points specifically. A dedicated inbox eliminates noise. Event notifications replace polling. client.threads.get() preserves context. client.engagement.messageTimeline() confirms delivery. Labels and a second inbox create a human escalation path. Compliance readiness checks prevent surprises at go-live.

Ready to start building? The full SDK reference is at getmail.bot/docs/getting-started.

Sources

Why Your Agent Needs Its Own Email Address, Not a Shared Mailbox

Yopie Suryadi — Sun, 29 Mar 2026 09:43:15 +0000

You have three agents running different workflows. Support, onboarding, and billing. All three send email from the same address: team@yourcompany.com. A customer replies to a billing notification. The support agent picks it up. The onboarding agent ignores it. Nobody knows which agent should own the conversation.

This is what happens when agents share a mailbox. It works in demos. It breaks in production.

The Shared Mailbox Problem

Shared mailboxes were designed for human teams. A group of people monitoring a single address, manually triaging incoming messages, and collectively managing responses. The assumption: someone is reading everything and routing it to the right person.

Agents don't work this way. An agent processing inbound email needs to know that every message arriving in its inbox is relevant to its workflow. When agents share an inbox, every agent receives every message. Filtering becomes your problem. Thread ownership becomes ambiguous. And when two agents both try to respond to the same email, the customer gets duplicate replies from the same address with no way to tell them apart.

The core issue: assigning a single email address to all agents makes it difficult to track which agent is responsible for specific communications. Forwarding rules can fail. Routing logic adds complexity that grows with every new agent. And the challenge isn't just having an inbox per agent — it's maintaining a reliable and searchable state for those inboxes that the entire system can trust.

These are infrastructure problems, not application logic problems. And they don't go away by writing better routing code.

Why Gmail and Outlook Don't Solve This

The first instinct for most developers is to use Gmail or Outlook. Create a Google Workspace account per agent, connect via OAuth, and start sending.

This breaks down fast.

Gmail's OAuth 2.0 requirements reached full enforcement in March 2025, replacing password-based authentication entirely. Every agent now needs a proper OAuth flow with token refresh handling. For a single agent, that's manageable. For twenty agents, you're maintaining twenty separate OAuth sessions, each with its own token lifecycle, scope configuration, and failure modes.

Gmail also wasn't priced for this. As AgentMail's analysis notes, Google Workspace costs $12 per inbox per month. At 100 agents, that's $14,400 per year just for email addresses, before you've sent a single message.

Then there's the rate limit problem. Gmail imposes sending limits per account. Microsoft recently attempted to cap Exchange Online at 2,000 external recipients per day and had to reverse the change after customer backlash about broken automated workflows. These limits assume a human sending cadence. Agents operate at machine speed, and consumer email platforms weren't built for that.

What a Dedicated Agent Inbox Looks Like

The alternative is programmable inboxes: email addresses created via API, one per agent or one per workflow, each with its own identity and its own message stream.

With mailbot, creating an inbox is a single API call:

import { MailbotClient } from '@yopiesuryadi/mailbot-sdk';

const client = new MailbotClient({ apiKey: 'mb_test_xxx' });

// Create a dedicated inbox for your support agent
const supportInbox = await client.inboxes.create({
  name: 'Support Agent',
  email_prefix: 'support-agent',
});

// Create a separate inbox for your billing agent
const billingInbox = await client.inboxes.create({
  name: 'Billing Agent',
  email_prefix: 'billing-agent',
});

Each inbox gets its own email address. Messages sent to support-agent@yourdomain.mailbot.id arrive only in the support agent's inbox. The billing agent never sees them. No routing logic. No filtering. The isolation is structural, not application-level.

When an agent needs to reply, it uses its own identity. The customer sees a consistent sender address. Thread headers are handled automatically:

// Support agent replies to a customer message
await client.messages.reply({
  inboxId: supportInbox.id,
  messageId: 'msg_inbound_customer_123',
  bodyText: 'We found the issue. Your subscription has been corrected.',
});
// In-Reply-To and References headers are set automatically
// The customer sees a threaded reply from support-agent@yourdomain.mailbot.id

No shared address. No ambiguity about which agent sent the response. No threading collisions.

Reputation Isolation

There's a deeper infrastructure reason to give each agent its own identity: sender reputation.

According to Twilio's guide on email reputation, domain reputation follows you everywhere. IP reputation can be rebuilt in 2 to 4 weeks, but domain reputation takes 6 to 12 weeks to recover. And Gmail now prioritizes domain-based filtering over IP reputation alone.

When all your agents share a single sending address, a reputation problem caused by one agent affects every agent. If your outreach agent triggers spam complaints, your support agent's replies start landing in spam too. The workflows are unrelated, but the reputation is shared.

With dedicated inboxes, reputation risk is contained. Each agent operates under its own address. If one workflow has deliverability problems, you can investigate and fix it without disrupting every other agent's email.

This is the same principle behind subdomain isolation in traditional email infrastructure, applied at the agent level.

Thread Ownership and Conversation Continuity

When agents share a mailbox, thread ownership becomes a constant source of bugs. Common failures include aligning message threads with the right workflow — outreach sequences, support escalations, deal stages — and ensuring replies aren't lost when agents restart or hand off conversations.

Dedicated inboxes solve this structurally. Each inbox has its own thread list. You can retrieve all threads for a specific agent without filtering across a shared pool:

// List all threads for the support agent's inbox
const threads = await client.threads.list(supportInbox.id);

// Get a specific thread with full message history
const thread = await client.threads.get(supportInbox.id, 'thread_abc123');

When a customer replies, the message arrives in the inbox that owns the conversation. The agent picks it up with full context. No race conditions with other agents. No need to build your own thread routing layer on top of a shared mailbox.

And when you need to trace what happened, events are scoped to the thread:

// Check delivery events for a specific thread
const events = await client.events.list('thread_abc123');
// Returns: delivered, opened, bounced events with timestamps

Each agent's conversation history is self-contained and traceable.

The Compliance Angle

For organizations handling sensitive data, shared mailboxes create audit problems. When three agents share an address, who sent what? Which agent accessed which customer data? Audit trails become tangled because the identity layer is shared.

Dedicated inboxes produce clean audit logs. Every message is tied to a specific inbox, a specific agent, a specific workflow. mailbot's audit log tracks actions per inbox:

// Review audit trail
const auditEntries = await client.auditLog.list({
  inbox_id: supportInbox.id,
});

For teams working toward compliance frameworks like ISO 27001, this separation of concerns matters. It's easier to demonstrate access control and data isolation when each agent operates within its own boundary.

When You Need More Than One Inbox

The real power of programmable inboxes shows up in multi-agent architectures. Common patterns:

Per-workflow inboxes. A support agent, a billing agent, and a notifications agent each get their own address. Customers know who they're talking to. Each agent manages its own conversation history.

Per-customer inboxes. For multi-tenant applications, create an inbox per customer or per account. Inbound messages are automatically isolated. No risk of data leaking between tenants.

Ephemeral inboxes. Need a temporary email for a verification flow or a one-off test? Create an inbox, use it, delete it:

// Create a temporary inbox for a verification flow
const tempInbox = await client.inboxes.create({
  name: 'Verification Flow - User 8847',
});

// Wait for the verification email to arrive
const verification = await client.messages.waitFor({
  inboxId: tempInbox.id,
  direction: 'inbound',
  subjectContains: 'Verify your email',
  timeoutMs: 30000,
});

// Process the verification, then clean up
await client.inboxes.delete(tempInbox.id);

Each pattern is possible because inboxes are API primitives, not manually provisioned resources.

Stop Sharing, Start Isolating

Shared mailboxes were built for human teams passing messages around. Agent workflows need structural isolation: one identity per agent, one message stream per workflow, one reputation boundary per sending address.

mailbot gives you programmable inboxes via API. Create them with a single API call. Each one gets its own address, its own threads, its own event history. No OAuth complexity, no per-seat pricing, no manual setup.

Start building at getmail.bot/docs/getting-started.

Sources

Mailbird: Gmail OAuth 2.0 Changes 2026. Timeline of Google's OAuth enforcement reaching full rollout in March 2025.
AgentMail: Why AI Agents Need Email. Gmail pricing at $12/inbox/month, scaling cost analysis for multi-agent setups.
Computing.co.uk: Microsoft drops Exchange changes after customer backlash. Microsoft's reversed 2,000 external recipient daily cap on Exchange Online.
Twilio: IP Reputation vs. Domain Reputation. Domain reputation recovery takes 6 to 12 weeks; Gmail prioritizes domain reputation over IP.

Suggested tags for Dev.to / Hashnode: email-api, ai-agents, developer-tools, programmable-inbox, email-infrastructure, devops

The Case for Email-Native Observability

Yopie Suryadi — Sun, 29 Mar 2026 09:42:27 +0000

Your email API says "delivered." Your user says they never got it. You check the dashboard. It shows a green checkmark. The user checks their spam folder. Nothing there either.

Somewhere between your API call and the recipient's mailbox, the message vanished. And you have no way to trace where it went.

This is the default experience with most email APIs. They confirm acceptance, not arrival. And for developers building agent workflows where email is the interface, that gap is where failures hide.

The Gap Between "Sent" and "Seen"

According to Unspam's 2025 deliverability report, only 60% of emails reach a visible mailbox location. 36% land in spam. 4% are blocked or disappear entirely. These numbers come from millions of email tests across consumer and enterprise providers.

The key insight: technical delivery success now overstates actual inbox reach by roughly 40%. Your API says "delivered" because the receiving server accepted the message. But acceptance and inbox placement are not the same thing.

For a marketing team, a 60% inbox rate is a conversion problem. For a developer running an AI support agent, it's an operational failure. If four out of ten replies your agent sends don't reach the customer, your agent isn't slow. It's broken. And without per-message visibility, you won't know which four.

What Observability Means in Infrastructure (and Why Email Doesn't Have It)

In modern infrastructure, observability rests on three pillars: logs, metrics, and traces. Logs tell you what happened. Metrics tell you how much. Traces show you the path a request took from start to finish.

Every serious backend service has all three. Your database has query traces. Your API gateway has request logs. Your CDN has latency metrics. When something breaks, you open a dashboard and follow the breadcrumbs.

Email doesn't work this way. Most email APIs give you one of three things: a delivery status ("sent," "delivered," "bounced"), an aggregate dashboard (open rates, bounce rates across a campaign), or raw SMTP logs that require you to parse headers manually.

None of these are observability. A delivery status is a single data point, not a trace. An aggregate dashboard hides the individual failures that matter most. And SMTP logs are what you read when everything else has failed and you're three hours into an incident.

The debugging challenge compounds when you consider how many layers are involved: email transport, agent logic, and delivery mechanics. A bug can live in any of those layers, and the symptoms rarely point to the actual source. Without per-message tracing, developers often waste hours investigating agent logic when the root cause is an infrastructure failure in the inbound or outbound email layer.

What Email-Native Observability Looks Like

Email-native observability means treating every message as a traceable event with a clear input, a set of processing steps, and a measurable outcome.

Not aggregate stats. Not "check the logs." A timeline per message.

Here's what that looks like in mailbot.

Event timeline. Every message gets a chronological sequence of events: message.delivered, message.opened, message.clicked, message.bounced. Not batched into a daily report. Updated in real time, visible per message, per recipient.

Event replay. When a delivery fails, you don't just see that it failed. You can replay the event sequence to understand what happened. Was it a temporary deferral that resolved on retry? A permanent 5xx rejection? A DMARC alignment failure? The replay shows the full sequence, not just the final status.

Inbound visibility. Observability isn't just about outbound. When your agent receives an email, you need to see the raw message, the parsed content, and the event notification that triggered your workflow. If classification went wrong, was it because the email body was garbled, quoted text wasn't separated, or the message arrived with unexpected headers?

import { MailbotClient } from '@yopiesuryadi/mailbot-sdk';

const client = new MailbotClient({ apiKey: 'mb_test_xxx' });

// Send a message and get a trackable handle
const message = await client.messages.send({
  inboxId: 'inbox_support_01',
  to: 'customer@example.com',
  subject: 'Re: Ticket #2847',
  text: 'We've identified the issue. A fix is rolling out now.',
});

// message.id ties to a full event timeline in your dashboard:
// message.delivered → message.opened → message.clicked
// or: message.bounced (with bounce code and reason)

The dashboard shows this as a visual timeline. One message, one trace. The same model that modern infrastructure uses for request tracing, applied to email.

Why This Matters for Agent Workflows

Agent workflows multiply the observability problem. A human sending one email can check their sent folder and follow up if there's no response. An agent sending fifty replies an hour needs infrastructure-level visibility.

Consider a support agent that processes inbound tickets. A customer emails in. The agent classifies the ticket, drafts a reply, and sends it. Without per-message observability, the developer has no way to answer basic questions:

Did the reply reach the customer's inbox?
Did the customer open it?
If it bounced, what was the bounce code?
If the original email was misclassified, was it because of a parsing problem or a classification problem?

These are not edge cases. They are the normal debugging surface of any email-based agent workflow. And most email APIs leave developers blind to all of them.

The Unspam report reinforces this: "Technical delivery success now overstates real inbox reach by approximately 40%." If you're relying on your API's "delivered" status to confirm that your agent's reply reached the customer, you're trusting a metric that's wrong four out of ten times.

Build With Visibility, Not Hope

Email is infrastructure. And infrastructure without observability is a black box you're choosing to trust.

mailbot treats every message as a first-class observable event. Event timeline, event replay, per-message delivery tracking, inbound and outbound. The same visibility model that developers expect from every other part of their stack, applied to email.

Start building at getmail.bot/docs/getting-started.

We Run Our Own Support on Our Own API

Yopie Suryadi — Sun, 29 Mar 2026 09:37:27 +0000

A support ticket comes in. An AI agent reads it, classifies it, drafts a reply with full context, and sends it back. The entire loop runs on the same API we ship to developers.

This is not a demo. This is how we handle support at mailbot, every day, on our own infrastructure.

The Best Test Is the One You Can't Skip

Dogfooding is not a new idea. Microsoft coined the term in the 1980s when a manager sent an internal memo titled "Eating our own Dogfood." Slack built its product by using it internally for months before anyone else could.

The pattern is clear: the products that hold up in production are the ones their own teams depend on. Not in a quarterly review. Not in a staged demo. In the moment when something breaks and you need the tool to work.

For mailbot, that moment is support. When a developer emails us with a problem, the clock starts. If our own infrastructure can't receive that email, classify it, and help us respond quickly, we have no business selling it to anyone else.

So we put our entire support workflow on our own API. Not as a marketing exercise. As an operational decision.

How It Works

The flow is straightforward.

A customer sends an email to our support inbox. That inbox is a programmable mailbot inbox, the same kind any developer can create through our API. The message arrives, triggers an event notification, and gets picked up by our agent workflow.

The AI agent does three things:

Classifies the ticket. Is this a bug report, a billing question, a feature request, or something else? The agent reads the full message body and assigns a category and priority.
Drafts a reply. Using the classification and the original message as context, the agent generates a response. Not a template. A contextual reply that addresses what the customer actually wrote.
Sends the reply through the mailbot API. The same messages.send endpoint our users call. Same SDK. Same authentication. Same event timeline tracking whether the reply was delivered, opened, or bounced.

import { MailbotClient } from '@yopiesuryadi/mailbot-sdk';

const client = new MailbotClient({ apiKey: 'mb_test_xxx' });

// Receive inbound via event notification handler
app.post('/webhooks/mailbot', async (req, res) => {
  const { type, data } = req.body;

  if (type === 'message.inbound') {
    const classification = await classifyTicket(data.text);
    const draft = await generateReply(data, classification);

    await client.messages.reply({
      inboxId: data.inboxId,
      messageId: data.id,
      bodyText: draft,
    });
  }

  res.sendStatus(200);
});

The thread stays intact because mailbot handles In-Reply-To and References headers automatically. The customer sees a normal email reply, threaded under their original message.

What We Learned

Running support on our own API exposed things that testing alone never would.

Event notifications need to be fast and reliable. When a customer writes in, the event notification has to fire immediately. Early on, we found edge cases where retry timing wasn't optimal for real-time support workflows. We fixed them. Those fixes shipped to every mailbot user.

Thread continuity is harder than it looks. Customers forward emails, CC other people, and reply from different addresses. If your threading logic only handles the clean case, production will embarrass you. We tightened our threading engine because our own agent kept losing context in messy threads.

Per-message visibility is not optional. When a support reply bounces, we need to know within seconds, not the next day. Our event timeline, the same one available in the mailbot dashboard, became our primary debugging tool. If a message shows "delivered" but the customer says they didn't get it, we can trace the full delivery path.

AI classification is only as good as the data it gets. The agent receives the raw email, headers and all. Clean parsing matters. If the message body comes through garbled or if quoted text isn't properly separated, classification degrades. We improved our inbound parsing because we were eating our own output.

Why This Matters for Developers

Every email infrastructure provider claims reliability. Fewer can show you that they depend on it themselves.

When we tell developers that mailbot handles two-way email conversations, thread continuity, and per-message observability, we're describing our own production workflow. Not a feature spec. Not a roadmap item. The system we wake up to every morning.

This is also why we catch issues fast. We're not waiting for a customer to report that event notifications are delayed or that threading broke on a forwarded message. We hit those problems first because we're running the same workflows our users run.

The best developer tools get built this way: used internally until they're genuinely useful to the team, then shipped externally. If you want to build infrastructure that works under pressure, put yourself under that pressure first.

The Full Loop

mailbot is email infrastructure that gives AI agents the ability to email. We don't just say that. We run our own operations on it.

Every support ticket that comes in gets classified by AI, drafted with context, and sent back through the same API we ship to developers. One stack. Same endpoints. Same event timeline. Same deliverability.

If you're building an agent workflow that needs to send, receive, and act on email, start with the infrastructure that its own team trusts enough to run support on.

Start building at getmail.bot/docs/getting-started.

Your Email API Doesn't Have an Opinion About Deliverability

Yopie Suryadi — Sun, 29 Mar 2026 09:37:26 +0000

Your agent sends a password reset. The user never gets it. You check the logs. "Sent," they say. That's it. No bounce reason. No retry trace. No idea whether the message hit the inbox, landed in spam, or disappeared into the void.

You didn't have a sending problem. You had a deliverability problem. And your email API had nothing to say about it.

The 2026 Deliverability Landscape Changed Everything

Email deliverability used to be forgiving. Gmail would route questionable messages to spam. Outlook would give you a second chance. The system had tolerance for "almost compliant."

That era is over.

In November 2025, Gmail escalated from warnings to outright SMTP rejection for non-compliant bulk senders. Messages that fail authentication don't go to spam. They never arrive. Microsoft followed in May 2025 with its own enforcement for senders above 5,000 messages per day — returning 550; 5.7.515 Access denied for non-compliant domains. Yahoo had already tightened rules across all its consumer domains starting February 2024.

The result: a binary pass or fail model. Your SPF, DKIM, and DMARC either align perfectly, or your messages get rejected at the protocol level. No gradation. No grace period.

For developers building agent workflows that depend on email, this isn't a marketing concern. It's an infrastructure concern. A support agent that sends a reply into the void is worse than one that doesn't reply at all.

Most Email APIs Don't Own the Delivery Path

Here's what happens when you send through a typical email API. Your application calls the API. The API accepts the message. Then it hands it off to a third-party MTA, one you don't control, can't configure, and probably can't even see.

That MTA handles authentication, queue management, retry logic, and reputation. If something goes wrong, your API provider might surface a "bounced" status. Or it might just say "sent" and leave you guessing.

This is the default experience with most email APIs on the market today. They're routing layers, not delivery infrastructure. They accept your message and pass it to someone else's stack.

The problem compounds for agent workflows. When an AI agent sends a follow-up, a ticket update, or a transactional notification, the developer needs to know: did it land? Was it opened? Did it bounce? Why?

A "sent" status and a shrug is not observability. It's a liability.

Why MTA Ownership Matters

The Mail Transfer Agent is where deliverability lives. It's the system that resolves MX records, negotiates TLS connections, enforces authentication, manages queues, and retries failed deliveries. Every decision that determines whether your message reaches the inbox happens at the MTA layer.

When an email provider owns its MTA, it controls:

Authentication enforcement. SPF, DKIM, and DMARC configuration happens at the source, not delegated to a vendor you can't audit.
Reputation management. IP warm-up, sending rates, and domain reputation are tuned directly, not inherited from a shared pool.
Queue visibility. When a message is deferred, you can see why. When it retries, you can trace each attempt.
Bounce diagnostics. A 5xx rejection from Gmail tells you something specific. That information should reach the developer, not get swallowed by middleware.

When an email provider doesn't own its MTA, it's renting all of this from someone else. And renters don't get to set the thermostat.

What This Looks Like in Practice

mailbot runs its own proprietary MTA. That means when you send a message, we handle every step from API call to inbox placement. No hand-off. No third-party relay sitting between your code and the recipient's mail server.

The practical difference shows up in three places.

Per-message visibility. Every message gets a timeline: delivered, opened, clicked, bounced. Not aggregate stats across a campaign. Per-message, per-recipient, in chronological order. When an agent sends a reply, you can trace exactly what happened.

import { MailbotClient } from '@yopiesuryadi/mailbot-sdk';

const client = new MailbotClient({ apiKey: 'mb_test_xxx' });

const message = await client.messages.send({
  inboxId: 'inbox_support_01',
  to: 'customer@example.com',
  subject: 'Re: Order #4821',
  text: 'Your replacement has shipped. Tracking number attached.',
});

// Later: check what happened on the thread
const events = await client.events.list(message.threadId);
// Returns: { data: [{ type: 'message.delivered', timestamp: '...' }, { type: 'message.opened', timestamp: '...' }] }

Event replay for debugging. When something fails, you don't just see that it failed. You can replay the event to understand the sequence. What was the bounce code? When did the retry happen? Was it a temporary deferral or a permanent rejection?

Unified deliverability stack. Because mailbot controls the MTA, authentication alignment, IP reputation, and sending behavior are tuned as a single system. Not stitched together across vendors hoping their configurations don't conflict. For context, top-performing email programs achieve inbox placement rates above 95%, while shared-infrastructure providers often average closer to 75–80%.

The Agent Workflow Problem Gets Worse Without This

Consider a support automation workflow. An inbound email arrives. Your AI agent classifies the ticket, drafts a reply, and sends it back through your email API.

If that reply bounces and your API can't tell you why, your agent is flying blind. Worse, if the bounce was caused by a misconfigured PTR record or a DMARC alignment failure on your API provider's side, you have zero ability to fix it. You're dependent on someone else's infrastructure team to resolve a problem that's blocking your customers.

This isn't hypothetical. Studies show that 20–30% of emails with misconfigured reverse DNS settings are either rejected or sent to spam. Since Gmail, Microsoft, and Yahoo now enforce FCrDNS (Forward-Confirmed reverse DNS) for bulk senders, many mail servers outright reject connections from IPs without valid PTR records — before SPF or DKIM are even checked. If your email provider owns that infrastructure, they fix it. If they're renting it, you file a ticket and wait.

Build on Infrastructure You Can See Through

Email deliverability in 2026 is binary. Your messages either pass authentication and reach the inbox, or they get rejected at the gate.

If your email API doesn't own the delivery path, you're trusting a black box to handle the most critical part of your workflow. For developers building AI agents, automated support, or transactional systems that depend on email actually arriving, that's a bet you don't need to make.

mailbot gives you the full picture: proprietary MTA, per-message event timelines, and event replay. One stack. No hand-offs.

Start building at getmail.bot/docs/getting-started.