TL;DR
This is infrastructure, not outreach. A sales sequencer sends campaigns from mailboxes a human owns. An agent email API gives a piece of software its own addressable identity that can receive, thread, and act. Do not evaluate them against each other. Best for: anyone about to buy the wrong category.
Gmail API is the cheapest way to give an agent an inbox a human already trusts, and the quota model changed on 1 May 2026. New projects get 1,200,000 quota units per minute per project, 6,000 per minute per user, and an 80,000,000-unit daily billing threshold that cannot be raised. Best for: agents acting inside an existing Google Workspace identity.
Microsoft Graph has the hardest ceiling in this list and it is not the API. Exchange Online caps sending at 30 messages per minute, so a Graph-based agent is throughput-limited by the mail service rather than by the API. Best for: Microsoft-tenant environments where the constraint is understood upfront.
Email infrastructure costs include mailbox identity, sending or receiving usage and storage. Price persistent agent inboxes separately from occasional transactional sends.
AgentMail is the only vendor here built for the problem rather than adapted to it: inboxes created on demand through an API, one identity per agent, threads, drafts, labels, webhooks, websockets, IMAP and SMTP, an MCP server and a CLI. Best for: systems that need hundreds of isolated agent identities.
Contents
- Why agent email is a different purchase from cold email
- The five things to specify before you choose
- 1. Gmail API
- 2. Microsoft Graph
- 3. Amazon SES
- 4. AgentMail
- Side by side summary
- Deliverability is not solved by any of these
- FAQ: Email APIs for AI Agents
Why agent email is a different purchase from cold email
A cold email platform assumes a human owns the mailbox, a campaign owns the message, and the reply lands in a unified inbox for a person to read. Every design decision in that category follows from those three assumptions.
An agent breaks all three. The agent is the account holder. There is no campaign, there is a conversation. And the reply is not something to be read later, it is the next input to a running process.
AgentMail's own framing of the problem is the clearest statement of it available, and it is worth quoting because it is a product thesis rather than marketing: existing email infrastructure was built for humans, legacy providers lack API support for creating new inboxes on demand, and pricing is per inbox rather than per use. Those are the two structural blockers. If you need one inbox, Gmail is fine. If you need three hundred, provisioning becomes the product.
The practical consequence for a GTM team is that these two purchases sit in different budget lines and solve different failures. Buying a sequencer to give an agent an identity produces an agent that can send and cannot meaningfully receive. Buying an agent email API to run outbound campaigns produces a bill with no warm-up, no rotation and no deliverability tooling.
The five things to specify before you choose
Identity. Does the agent get its own address, or does it borrow a human's? Borrowing is faster and it means every action the agent takes is attributed to a person, which is a governance problem the first time an agent sends something wrong.
Receive, not just send. Most email infrastructure is a send pipe. Agents need inbound. Check whether inbound is a first-class product with its own routing, or an add-on. Amazon SES treats it as a completely separate meter with its own rule sets and actions. Gmail and Graph give you a real mailbox, so inbound is native. Send-only transactional providers do not belong on this shortlist at all.
Threading. An agent that cannot reconstruct a conversation restates itself. Look for a thread object in the API rather than a message list you have to stitch by subject line.
Webhooks and streaming. Polling a mailbox is the wrong architecture and it burns quota. AgentMail publishes both webhooks and websockets as first-class API resources. Gmail and Graph support push notification patterns. Design for push and treat polling as the fallback.
Isolation. If one agent's address gets blocked, does it take the others with it? This is the question that decides whether you can run many agents on one domain, and it is a reputation question rather than an API question.
1. Gmail API
Layer: Full mailbox API on an existing Google Workspace identity
Best for: A small number of agents operating inside identities humans already trust
Gmail API is the default and it is a good default, provided you have read the May 2026 quota change and understand that you are metering in quota units rather than requests.
Google updated Gmail API usage limits on 1 May 2026 for new Cloud projects, while projects that used the Gmail API between November 2025 and April 2026 keep their existing quotas for now. New projects get 1,200,000 quota units per minute per project, shared across all users in the project, and 6,000 quota units per minute per user per project. There is also a daily threshold of 80,000,000 quota units per day per project, and Google's documentation states that usage under this threshold does not incur extra charges, that the Cloud account is not billed, that full billing details will be shared later in 2026 with at least 90 days notice before any changes take effect, and that you cannot request an increase on the daily threshold. A per-user rate of 250 quota units per second is also documented and is the limit most commonly cited.
The per-method costs are what actually decide your architecture, because they are wildly uneven. Published unit costs include getProfile at 1, labels.get at 1, labels.list at 1, history.list at 2, drafts.list at 5, labels.create at 5, labels.delete at 5, labels.update at 5, drafts.create at 10, drafts.delete at 10, drafts.update at 15, drafts.get at 20, and drafts.send at 100. Third-party analysis notes messages.send at 100 units and messages.list at 5, with a documented example that at 250 units per second per user you can send at most 2 messages per second per user but list 50 pages per second.
That 100-unit send cost against a 5-unit read cost is the single most important design fact here. An agent that reads aggressively and sends sparingly is cheap. An agent that sends on every turn is not.
Separately from API quota, the mail service imposes sending limits. Google documents a daily sending quota of 1,000 messages per day for free Gmail accounts and 10,000 for paid Workspace accounts, per user. Third-party integration documentation cites a practical 2,000 messages per day figure and 500 emails per day on free-tier sends, and Google's Workspace limits page gives 10,000 total recipients per day, 3,000 external recipients per day and 100 addresses per message. Those numbers are the ones a real agent hits first.
Pricing: No direct charge below the documented daily quota threshold. The cost is the Google Workspace seat, from $7 per user per month annual on Business Starter with monthly at $8.40, plus your own infrastructure. Google Cloud billing details for Gmail API usage above threshold are stated as forthcoming later in 2026 with 90 days notice.
Where it falls short: One mailbox per identity, and provisioning a new identity means provisioning a Workspace user with a seat cost. Quota is per user per project, so ten agents sharing one mailbox contend for the same 6,000 units per minute. And you are inside somebody's real inbox, which means an agent misfire is indistinguishable from a human misfire in the audit trail.
Verdict: The right answer for one to five agents acting as an extension of a person. It stops being the right answer the moment provisioning becomes routine.
2. Microsoft Graph
Layer: Unified Microsoft 365 API including full Outlook mail access
Best for: Agents inside a Microsoft tenant, where the constraint is understood before the build
Microsoft Graph gives an agent the same mailbox a human has, with the same identity, permissions and compliance envelope. For a tenant already standardised on Microsoft 365, that is a governance advantage no third-party service can match.
The throttling model is published and it is per app ID and mailbox combination, meaning a specific app accessing a specific user or group mailbox, and exceeding the limit for one mailbox does not affect the application's ability to access another. The documented limits are 10,000 API requests in a 10-minute period, four concurrent requests, and 150 megabytes of upload through PATCH, POST or PUT in a 5-minute period, all applying to both v1.0 and beta endpoints.
JSON batching has its own behaviour worth knowing: by default Microsoft Graph sends the Outlook service up to four individual requests from a batch at a time regardless of target mailbox, which keeps execution within Outlook's concurrency limits, and an app can use the dependsOn property to order requests so they run sequentially.
The binding constraint is not any of those. It is Exchange Online, and Microsoft's own support answers are explicit: despite the Graph API's high request threshold, the Exchange Online sending limit of 30 messages per minute acts as the bottleneck, so even though the API can technically handle more requests per minute, only 30 emails can be sent per minute due to the Exchange Online restriction. Microsoft also states that these Outlook per-mailbox limits including the 150 MB per 5 minutes and 4 concurrent requests are fixed service limits, that there is no documentation indicating tenant administrators can configure or relax them, and that high-throughput designs should focus on load distribution across mailboxes, strict client-side throttling, batching and bulk options such as Microsoft Graph Data Connect rather than expecting to raise the limits.
Related Exchange Online figures that apply to any agent sending through the tenant: a 10,000 recipient per day limit, a per-message recipient limit customisable down to 1,000, a proxy address limit of 300, and a 30 messages per minute rate. High Volume Email supports up to 100,000 recipients per day with unpublished pricing.
Where it falls short: Thirty messages per minute is the whole story for any sending-heavy agent, and it is not raisable. Four concurrent requests per app and mailbox combination constrains parallel processing. And the July 2026 price increase means the identity layer under your agents got more expensive without the agent capability changing.
Verdict: Correct when the tenant is Microsoft and governance matters more than throughput. Architect around distribution across mailboxes from day one, because the per-mailbox ceiling will not move.
3. Amazon SES
Layer: Pay-as-you-go send and receive infrastructure with programmable inbound routing
Best for: Volume, and systems where you want to own the routing logic entirely
SES is the option in this list where inbound is a genuinely separate, genuinely programmable product rather than a mailbox you read. That is either exactly what you want or completely wrong for you, and there is not much middle ground.
Inbound works through receipt rules organised into rule sets, with only one rule set active at a time. Receipt rules can deliver incoming mail to an S3 bucket, publish it to an SNS topic, send it to Amazon WorkMail, trigger a Lambda function, or automatically send bounce messages for specific addresses. IP address filters provide a coarser control layer with block lists and allow lists, and SES maintains its own block list of IP addresses known to send spam including those listed on public blocklists.
For an agent, the Lambda path is the interesting one: an inbound message becomes a function invocation with the message as input, which is the cleanest possible integration point for a system that is already event-driven.
The billing model is modular and independent across five dimensions: outbound sending per 1,000 emails, inbound receiving per 1,000 chunks, data transfer per GB for attachments, dedicated IP addresses monthly, and add-on features. Published rates include outbound from $0.10 per 1,000 emails, attachments metered separately at $0.12 per GB, and inbound receiving at $0.10 per 1,000 inbound emails plus $0.09 per 1,000 incoming chunks, where a chunk is 256 KB. Mail Manager archiving is billed at $2 per GB ingested and $0.19 per GB per month stored. Two line items that catch people out: Email Validation API at $0.01 per validation and Email Validation Auto at $0.01 per 1,000 differ by a factor of a thousand for what reads like the same feature. A worked example of the attachment charge: a service sending 200,000 emails a month with a 200 KB PDF attached moves 40 GB, which is $4.80 on top of $20 of sending, a 24% increase no per-email calculator will show.
On 21 July 2026 AWS introduced SES pricing plans: three hierarchical options called Essentials, Pro and Enterprise, each building on the one before, offering progressively more capability at a discount against à-la-carte pricing. All new SES accounts begin on Essentials from that date. Pro adds dedicated IPs so sending reputation is isolated, catches invalid addresses before they bounce, and shows inbox placement across providers. Enterprise adds regional resilience, reputation isolation across workloads and an annual deliverability assessment. Virtual Deliverability Manager, managed dedicated IPs and Email Validation are included at Pro and above; Global Endpoints and Tenants are included at Enterprise and add-ons below it.
Pricing: From $0.10 per 1,000 emails sent. Inbound $0.10 per 1,000 emails plus $0.09 per 1,000 chunks of 256 KB. Attachments $0.12 per GB. Archiving $2 per GB ingested, $0.19 per GB per month stored. Three plans since 21 July 2026: Essentials, Pro, Enterprise. No upfront fees, no monthly subscription on the base service, no long-term contract.
Where it falls short: SES gives you a pipe and a rule engine, not an inbox. There is no thread object, no draft object, no label model and no unified view. Everything a mailbox does for free, you build. Sandbox limits and reputation warm-up apply to new accounts, and the modular meter means the true cost requires a calculation rather than a lookup.
Verdict: The volume answer, and the right answer when the agent's mail behaviour is genuinely programmatic rather than conversational. Budget engineering time for the mailbox semantics you are choosing not to buy.
4. AgentMail
Layer: API-first inbox platform purpose-built for AI agents
Best for: Systems needing many isolated agent identities provisioned on demand
AgentMail is the only vendor here designed for this problem from the start, and the design shows in the resource model. An inbox is described as a fully loaded, programmatically accessible API resource, similar to a Gmail or Outlook account but built API-first, where each inbox has a unique email address and serves as the primary resource the agent uses to send and receive, giving it a first-class identity on the internet, and built to scale horizontally rather than at human scale.
The API surface is complete in a way that matters for agent work. Documented resources cover Agent, Inboxes, Threads, Drafts, Webhooks, Websockets, Domains, Lists, Metrics, API Keys, Pods, Organizations and Auth. Documented operations include list, get, create, update and delete inboxes; list, search, get and update threads; get and delete threads; list, search, get, batch get, batch update, get raw message, update and delete messages; attachment retrieval; and send message. The base URL is https://api.agentmail.to/v0/ with bearer token authentication, and there are separate production servers for standard, x402, MPP and an EU endpoint at api.agentmail.eu, which is the detail that matters for European data residency.
The integration list is the clearest signal of who this is built for: MCP, CLI, Google ADK, LangChain, OpenClaw, Grok Bot, Replit, x402, MPP, LiveKit and Sim.ai, plus multi-tenant Pods for platform builders and IMAP and SMTP access for anything legacy. There are Python and Node SDKs. Guides cover AgentID browser enrolment, AgentID public-key authentication, multi-tenancy and domains.
The capability list for what agents do with it is worth restating because it defines the category: have conversations with users in their inboxes, automate email-based workflows for enterprises, authenticate with third-party applications, and act as first-class users on the internet. That third one, authentication, is the underrated use case. An agent that needs to receive a verification code needs an inbox, and it should not be a person's.
Pricing: Published plans are Developer, Startup and Enterprise, with the vendor describing pricing that grows as the number of agent inboxes increases. Per-plan figures are not reproduced on the indexed pricing page, so treat the tier names as the published fact and get current numbers from the vendor. Sign-up is self-serve for Developer and Startup; Enterprise is an inquiry.
Where it falls short: Published pricing detail is thin relative to the AWS and Microsoft options, which makes budgeting a conversation. It is a younger vendor than the other three by a wide margin, which is a real consideration for infrastructure. And sending reputation on a new domain is your problem regardless of how good the API is, which brings us to the section nobody wants.
Verdict: The correct architecture if you are running more than a handful of agents and each needs its own identity. The provisioning model alone justifies the shortlist; confirm current pricing directly before you commit.
Side by side summary
| Tool | Layer | Best for | Entry price |
|---|---|---|---|
| Gmail API | Mailbox API on a Workspace identity | One to five agents inside human identities | Workspace seat from $7 per user per month annual |
| Microsoft Graph | Unified Microsoft 365 API with Outlook mail | Microsoft tenants where governance leads | Microsoft 365 licence, Business Basic $7 per user per month |
| Amazon SES | Pay-as-you-go send and programmable receive | Volume with owned routing logic | From $0.10 per 1,000 emails sent |
| AgentMail | API-first inboxes purpose-built for agents | Many isolated agent identities on demand | Developer, Startup and Enterprise tiers, quote to confirm |
Deliverability is not solved by any of these
Every option above solves identity and transport. None of them solves reputation, and reputation is what determines whether the agent's mail is read.
Three things are true simultaneously and teams building agent email discover them in this order.
First, provider policy is tightening, not loosening. Microsoft's high-volume sender authentication requirements enforced from 5 May 2025 pushed many teams off shared Microsoft 365 tenants and onto dedicated or SMTP infrastructure. Practitioners report that sending through generic SMTP into Google mailboxes now performs badly enough that ESP matching has become a routine pre-send check rather than an optimisation.
Second, blocklists are structural rather than incidental at scale. Operators running high volume describe it as very difficult to stay off public blocklists because of parked domains on shared warm-up pools that resell data to blocklist operators, and because buying outreach domains without batching makes it nearly impossible, with batching and a private warm-up pool the fix and the barrier to entry high. Delisting requests are frequently declined outright.
An MX lookup provides context about receiving infrastructure, not a verdict on delivery. Do not automatically exclude a valid recipient because the domain uses an enterprise gateway. Use authenticated sending, relevant content and actual delivery evidence to investigate problems; no formatting choice guarantees that a message will avoid filtering.
For an agent specifically, this means one additional design rule. Isolate the agent's sending domain from the domain your humans send from. If the agent's reputation degrades, and at some point it will, that failure should not take the company's mail with it.
FAQ: Email APIs for AI Agents
What is the difference between an agent email API and a cold email platform?
A cold email platform manages campaigns from mailboxes a person owns, with warm-up, rotation, sequencing and a unified reply inbox for a human to work. An agent email API gives software its own addressable identity with programmatic control over receiving, threading, drafting and sending. AgentMail's stated problem definition captures it: legacy providers lack API support for creating inboxes on demand and price per inbox rather than per use. If you need to provision identities programmatically, you need the second category, and a sequencer will not substitute.
How much does the Gmail API actually cost?
There is no direct charge below the documented threshold. Google publishes a daily limit of 80,000,000 quota units per day per project, states that usage under this threshold does not incur extra charges and the Cloud account is not billed, says full billing details will be shared later in 2026 with at least 90 days notice, and confirms the daily threshold cannot be increased on request. Your real cost is the Google Workspace seat, from $7 per user per month on annual billing. Quota is spent unevenly: sending a message costs 100 units while listing costs 5, so a read-heavy agent is far cheaper than a send-heavy one.
Why is Microsoft Graph limited to 30 emails per minute?
Because the limit is imposed by Exchange Online, not by Graph. Microsoft's own guidance states that despite the API's high request threshold, the Exchange Online sending limit of 30 messages per minute acts as the bottleneck, so only 30 emails per minute can be sent regardless of API capacity. Microsoft also states that the related per-mailbox limits, including 10,000 requests per 10 minutes, four concurrent requests and 150 MB of upload per 5 minutes, are fixed service limits that tenant administrators cannot configure or relax. The documented mitigation is distributing load across mailboxes rather than seeking an increase.
Can Amazon SES receive email, or is it send-only?
SES supports email receiving as well as sending, with region-specific availability and receipt-processing configuration. It is not a conventional user inbox; design storage and downstream handling for inbound messages.
Do we need a separate inbox per agent, or can several agents share one?
Share only if the agents never need independent identity, independent reputation or independent quota, which in practice means only for a small internal pilot. Gmail quota is 6,000 units per minute per user per project, so agents sharing a mailbox contend for one pool. Microsoft throttles per app and mailbox combination, so sharing concentrates the four-concurrent-request limit. And reputation is shared, which means one agent's mistake degrades the others. AgentMail's entire premise is that per-agent inboxes should be provisioned on demand rather than treated as scarce.
What happens to compliance when an agent sends email under a person's identity?
The audit trail stops distinguishing them, which is the core governance objection to the Gmail and Graph approach. Every message the agent sends is attributable to the licensed user whose mailbox it used, in eDiscovery, in retention policy and in any dispute. That is acceptable when the agent is a drafting assistant a person reviews before sending, and it is a problem when the agent sends autonomously. Where autonomous sending is in scope, give the agent its own identity on its own domain, keep it separate from human sending, and log agent actions independently of the mail service.
The agent still needs an execution workflow. Our comparison of n8n vs zapier vs make covers the adjacent options.
Work with Forma Nôrden
We build signal based outbound systems for B2B companies selling into the enterprise and upper mid market. Agent email is an identity and reputation decision disguised as an API choice, and the teams that get it wrong usually discover it through a domain rather than through a bill. Explore how we work.
For enquiries about this article: partnerships@formanorden.com
