Email API Pricing for AI Agents: Send + Receive Compared

Email API pricing for AI agents breaks down into two very different shapes of bill. Traditional email APIs (Resend, SendGrid, Mailgun, Postmark) price on outbound volume and treat inbound as a webhook feature bolted onto a sending plan, with no mailbox object at all. Agent-native platforms (Robotomail, AgentMail) price around mailboxes and messages, with receiving, threading and storage included because an agent that cannot read replies is useless.

The practical verdict: at one mailbox, almost everything looks cheap and the invoice is not the deciding factor. At ten mailboxes, the question becomes whether you are paying for a mailbox layer or building one. At fifty, three line items decide your bill: whether inbound messages are billed, whether there is a per-mailbox fee or a hard mailbox cap, and whether message retention or log retention is gated behind a higher plan tier.

We are not going to print competitors' list prices in this post. Those numbers change on their pricing pages and a stale table is worse than no table. What does not change is the shape of the bill, which is what actually determines your cost at 50 agent mailboxes. Our current numbers are on the pricing page.

The short verdict

Provider	Primary pricing unit	Inbound story	Mailbox as a billable object	What to check at 50 agents
Robotomail	Mailboxes + messages	Included: inbound webhook, threads, attachments	Yes, mailboxes are first-class	Mailbox allowance per plan
AgentMail	Agent mailboxes + usage	Included, agent-oriented API	Yes	Mailbox and message allowances per tier
Resend	Outbound emails per month	Inbound delivered to your webhook	No	Inbound handling and domain limits
SendGrid	Outbound emails per month	Inbound Parse to your endpoint	No	Which plan tier your feature needs live on
Mailgun	Outbound volume, tiered	Routes to your endpoint	No	Log retention and feature gating by tier
Postmark	Message volume, tiered	Inbound streams to your endpoint	No	Whether inbound counts against your allowance

The row that matters most is "mailbox as a billable object." On the four classic providers there is no mailbox. You get an address that forwards a parsed payload to an HTTP endpoint. Storage, threading, per-agent isolation, sent-items history and reply correlation are yours to build. That work does not appear on the invoice, which is exactly why the invoice comparison misleads people.

If you want the full feature-level ranking rather than the money view, we keep that separate in our best email API for AI agents breakdown.

Why agent pricing looks different from bulk sending pricing

Bulk senders have one identity and a lot of volume. A marketing platform sends 2 million messages from news@brand.com. Volume-tiered pricing fits that perfectly: one address, one domain, one reputation, price per thousand sends.

Agents invert the shape. Fifty agents might send 200 messages each per month, so 10,000 sends total, which is nothing. But they need 50 distinct addresses, 50 isolated inboxes, and they receive roughly as much as they send because their whole job is conversation: a vendor replies, a candidate replies, a customer asks a follow-up question.

So the agent cost model has a different set of variables:

monthly cost =
    plan floor
  + (sends        × send rate)
  + (inbound      × inbound rate, if billed)
  + (mailboxes    × per-mailbox fee, if any)
  + add-ons (dedicated IP, extra domains, extended retention, seats)

On a volume-priced ESP, terms two and three are small and terms four and five are zero, because mailboxes do not exist. Your real cost is the engineering line that is not in the formula: a database of messages, dedupe on retries, thread correlation via Message-ID, In-Reply-To and References, attachment storage, per-agent access control, and an ops burden when the parse webhook goes down and mail silently disappears. We wrote up that tradeoff in detail in build vs buy for agent email.

On an agent-native platform, terms one and four dominate and the engineering line is close to zero. Which is cheaper depends entirely on how much a week of your time costs relative to a monthly plan.

What each provider actually bills you for

Resend

Priced on outbound emails per month in tiers, with domain and team-seat limits attached to those tiers. Inbound is delivered as a webhook payload to your endpoint. There is no per-agent mailbox, no thread store you can query, and no per-mailbox quota because the unit of identity is the domain, not the address. At 1 agent this is a very clean sending API. At 50 agents you are running your own mailbox service on top of it. Details in our Resend comparison.

SendGrid

Tiered on monthly send volume, with feature availability and support level varying by tier. Inbound Parse gives you a hostname whose mail is POSTed to your URL as multipart form data, which you parse yourself. It is functional and battle-tested, but it is a parser, not an inbox: nothing is stored, so a webhook outage during a delivery window is a permanently lost reply unless you handle retries and durability. Dedicated IPs, if you need one, are a separate line item. See the SendGrid comparison for the agent-specific gaps.

Mailgun

Volume-tiered like SendGrid, with a longer list of tier-gated capabilities: log retention windows, inbound routing features, dedicated IPs, and validation credits. For agents, log retention is the sleeper cost. When an agent claims it never got a reply, you need message logs going back further than a few days, and longer retention usually means a higher plan. Routes handle inbound the same way SendGrid's parse does: fire an HTTP request, keep nothing durable for you. More in the Mailgun comparison.

Postmark

Volume-tiered, with a strong separation between transactional and broadcast streams, which is good hygiene for agents that would otherwise mix cold outreach with real conversations. Inbound arrives on a dedicated inbound stream and is POSTed as JSON, which is nicer to parse than form data, and inbound content is retained for a limited window rather than discarded immediately. The critical question to check on their current pricing page: whether inbound messages count against the same monthly message allowance as your sends. If they do, an agent fleet that receives as much as it sends effectively doubles its billed volume.

AgentMail

Built for the agent use case, so mailboxes are the primitive and receiving is not an add-on. Pricing is oriented around mailbox count and usage rather than pure outbound volume, so read the allowances per tier: how many mailboxes, how many messages, what happens when you exceed. Feature and workflow differences are in our AgentMail comparison.

Robotomail

Mailboxes are the unit. You create one per agent, it has a real address, it receives mail, it keeps threads, and inbound webhooks and attachments are part of the product rather than a separately priced feature. Creating the fiftieth mailbox is the same one-line call as the first:

curl -X POST https://api.robotomail.com/v1/mailboxes \
  -H "Authorization: Bearer rm_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"address": "shopping-agent"}'

Current plan allowances and per-plan mailbox counts live on the pricing page, and the technical ceilings (rate limits, message size, mailbox limits) are documented under limits.

The math at 1, 10 and 50 mailboxes

Use a consistent workload so the comparison is honest. Assume each agent sends 200 messages a month and receives 250, which is typical for a support, procurement or scheduling agent that holds real threads.

Scale	Sends/month	Inbound/month	What decides your cost
1 mailbox	200	250	Nothing on the invoice. Time to first working reply loop.
10 mailboxes	2,000	2,500	Whether you maintain a mailbox store for 10 addresses.
50 mailboxes	10,000	12,500	Inbound billing, per-mailbox fees or caps, retention tier.

At 1 mailbox

Every provider on this list sits in its lowest tier at 200 sends. The invoice difference is noise. What differs is that on a volume-priced ESP you still have to stand up a webhook receiver, a message table and thread correlation before your agent can answer a single reply, and on an agent-native platform you call one endpoint and get an address. If you are prototyping, optimize for the shorter path, not the smaller number. Our walkthrough for that is how to give your AI agent an email address.

At 10 mailboxes

10,000 combined messages is still a low tier everywhere. The interesting question is operational: ten agents means ten reputations sharing one domain, ten sets of threads to keep separate, and ten chances for a webhook retry to double-process a message. If you are on a parse-only provider, this is the point where you have quietly written a small mail service. Price that service at even half a developer week per quarter and it dominates any plan difference.

Also check domain and seat limits here. Several volume-priced plans cap the number of verified sending domains on lower tiers. If your agents need to send from customer subdomains, the domain cap, not the message count, is what pushes you up a tier.

At 50 mailboxes

This is where the pricing models actually diverge. Three questions:

1. Is inbound billed? 12,500 inbound messages either cost nothing, cost the same as a send, or count against a shared allowance. That single policy is a 2x swing in billed volume for a conversational fleet.
2. Is there a per-mailbox fee or a hard mailbox cap? On agent-native platforms, mailboxes are the meter, so read the allowance per tier and the overage behaviour. A hard cap is worse than an overage rate if you provision mailboxes dynamically per customer or per task.
3. What retention do you need, and what tier is it on? Agents generate disputes: "did the vendor ever confirm?" Answering that six weeks later requires stored messages and logs. On several providers, extended log retention is a tier upgrade, and that upgrade is priced off send volume you do not have.

A fourth, less obvious one: rate limits per mailbox and per account. Fifty agents waking up on the same cron minute is a burst, and a per-second account limit you did not read will surface as failed sends rather than a bigger bill.

Line items people forget to price

• Dedicated IP. Usually a separate monthly charge, and usually unnecessary at agent volumes. 10,000 sends a month is not enough traffic to warm and hold a dedicated IP reputation, so shared is normally the right call.
• Extra domains. If each customer gets a subdomain, count domains as a pricing dimension, not a detail.
• Email validation credits. Priced per lookup on some providers. Agents that generate their own recipient lists burn these fast.
• Storage and attachments. Agents receive PDFs: invoices, contracts, resumes. Ask whether attachment storage is included, capped, or a separate charge, and what the maximum message size is.
• Seats. Team-seat caps on lower tiers matter if support engineers need log access.
• Overage behaviour. Soft overage billing is annoying. Hard cutoff mid-month is an outage. Find out which one you bought.

How to run the comparison for your own workload

1. Count agents, not volume. Write down mailboxes needed at launch, at 6 months, and worst case.
2. Estimate sends and inbound separately. Do not assume inbound is small; conversational agents receive roughly what they send.
3. For each provider, find the four numbers: send allowance, inbound treatment, mailbox allowance or cap, retention window.
4. Add the build line for any provider without a mailbox object: storage, threading, dedupe, access control, and the ongoing maintenance of that code.
5. Check limits documentation, not just the pricing page. Rate limits and message size caps are cost decisions in disguise.
6. Prototype on two providers with one mailbox each and measure time to a working reply loop. That number predicts your real spend better than the plan price does.

FAQ

Do email APIs charge extra for receiving email?

It varies, and it is the most important thing to check. Classic providers deliver inbound to a webhook as part of a sending plan, but some count inbound messages against the same monthly allowance as sends, which doubles billed volume for agents that hold real conversations. Agent-native platforms generally include receiving because a mailbox without inbound is pointless. Always confirm on the provider's current pricing page.

Is a per-mailbox price more expensive than volume pricing for agents?

At the same message volume, a per-mailbox model usually shows a higher invoice and a lower total cost, because it includes the inbox layer you would otherwise build: storage, threading, per-agent isolation, sent history, attachments. Volume pricing looks cheaper because the mailbox work is on your payroll instead of the invoice.

How many mailboxes do I need per agent?

One per agent identity, not one per task. An agent that handles procurement for three customers is usually better served by three mailboxes, one per customer, so threads, suppressions and reputation stay isolated and you can revoke a single relationship without touching the others.

Does sending volume or mailbox count drive cost at 50 agents?

Mailbox count, in almost every realistic agent workload. Fifty agents at a couple hundred sends each is 10,000 messages a month, which sits in the lowest tier of every volume-priced provider. The cost drivers at that scale are inbound billing, mailbox allowances, and retention tiers.

Start with Robotomail