Together with Mailtrap experts I reviewed and tested Mailtrap, SendGrid, Mailgun, Postmark, Amazon SES, and AgentMail to find the best inbound email API in 2026.
We ran the same tests across all the providers and scored them on parse depth, addressing model, webhook reliability, attachment handling, agent-readiness, and receiving-side pricing.
Before you trust any of these scores:
- Mailtrap is one of the products reviewed and it ends up at #1.
- To stress, I ran one inbound benchmark across every provider and graded every score by the evidence behind it – a live capture, the provider’s own published payload, or a documented claim. The ‘How we tested…’ section features detailed methodology and grading.
- Where a competitor does something better, this article says so.
What is the best inbound email API: a snapshot
The quick-cut for teams that know what they’re building, where each provider gets the same shape of an answer – the one job it’s best at.
- Mailtrap is best for developer experience and agent-native inbound. It has MCP-driven inboxes (117+ tools in total), the broadest SDK coverage, and high-deliverability sending and email testing workflows.
- Postmark is best for existing Postmark users whose transactional app requires rich structured JSON.
- Mailgun is best for routing-heavy workloads with regex Routes and per-pattern webhooks across many endpoints.
- SendGrid is best for teams already on SendGrid’s sending stack who want inbound without switching ESPs.
- Amazon SES is best for AWS-native teams who have engineering capacity and want raw receiving cost at scale.
- AgentMail is best for agent-native inbox primitives where persistence, threading, and semantic search matter more than parse-and-route.
| Provider | Best for | Agent-ready? | Free tier | Receiving pricing |
|---|---|---|---|---|
| Mailtrap | Developer experience + agent-native inbound | Yes (MCP-native inbound) | 4000/mo | Basic: $15/mo, 10,000/emails (bundled with outbound) |
| Postmark | Teams on Postmark and parse quality | No | No | Pro: $16.50/mo Platform: $18/mo (bundled with outbound) |
| Mailgun | Routing-heavy, regex Routes | No | Limited | Free: 1 route Basic: 5 routes (bundled with outbound) |
| SendGrid | Teams on SendGrid stack | No | 60-day trial | Essentials: $19.95/mo (bundled with outbound) |
| Amazon SES | AWS-native raw receiving | No (Lambda DIY) | No | $0.10/1,000 received |
| AgentMail | Agent-native inbox primitives | Yes (MCP native) | Yes (3 inboxes, 3,000 emails/mo) | Developer: $20/mo, 10,000 emails Startup: $200/mo, 150,000 emails |
For the broader sending-side comparison, see transactional email services and the best email API roundup.
Mailtrap: Best for developer experience and agent-native inbound
Mailtrap is an email delivery platform where Inbound email API is bundled with production sending (Email API/SMTP). On the receiving side, Mailtrap Inbound does three things:
- It accepts emails at a dedicated inbound address
- Parses the email into structured JSON
- Routes the payload to an endpoint over a HMAC-signed webhook
Most competitors offer similar, if not the same workflow, but what puts Mailtrap at the top is the developer experience around those three steps. Lemme break it down for you.
Mailtrap Inbound is MCP-native. As of August 2026, the MCP server ships 117 tools in total, 19 of them are for inbound, including: inbox CRUD, message list/get/delete, reply, reply-all, forward, and threads. So an agent can create its own inbox and read, search, and answer mail without glue code.
That is what ‘agent inbox’ means in practice – the Inbound Email API over MCP or a CLI, not a second product just bolted on. But let me give you an example so you can understand how ot works.
I gave a Claude Code agent a scoped Mailtrap inbox and had it run a receive-parse-reply loop end to end. And the MCP isn’t the only agent surface either, there are two more:
- Mailrap CLI to drive the same API from a shell or a CL step
- Open-source Mailtrap Skills repo (MIT) packaging agent procedures for the sending side – authentication, sending, templates, contacts, and domain setup.
Also, as a delivery platform, Mailtrap offers Email Sandbox – a separate product for staging email against test traffic. It’s a useful addition to the inbound because, within the same agentic flow, you can check how your parser handles malformed MIME, odd charts, and large attachments before pointing a production MX record at a real domain.
What Mailtrap features ensure reliable inbound email processing?
Inbound processing: structured JSON webhooks, body text + HTML, raw headers, envelope fields, base64 email attachment parsing, HMAC-SHA256-signed payloads (mailtrap-signature over the raw body, live-verified), exponential-backoff retries up to 10 attempts over 24 hours.
Addressing: catch-all domain, per-user addressing, programmatic multi-tenant inbox creation, unique per-inbox SMTP addresses, folder organization, full CRUD via API.
Agent-readiness: (as mentioned) MCP-native inbound – 19 dedicated tools covering inbox CRUD, message list/get/delete, reply, reply-all, and threads, so the agent drives the inbound API directly.
Security: DKIM/SPF/DMARC validation on inbound, TLS, HMAC-SHA256-signed inbound webhook payloads (verified against live traffic).
SDKs: Node.js, PHP, Ruby, .NET, Java, Python, Go, Elixir, plus Laravel and Symfony packages – 10 official SDKs. API key authentication.
Inbound email API readiness benchmark results
| Criterion | Score | Evidence | Notes |
|---|---|---|---|
| Inbound parse and routing | 8.8/10 | 🟢 live | Structured JSON, 12/13 canonical fields, attachment decodes, live-verified HMAC-SHA256 webhook signature. No spam verdict in the payload (under development for Inbound at the time of writing) |
| Receiving-side pricing | 4/4 | ⚪ doc-claim | Bundled, no separate inbound charge – received messages draw on the same monthly volume as your Email API/SMTP plan, and replies and forwards count as sends; permanent free tier includes inbound (4,000/mo); not plan-gated |
| Developer experience and agent-readiness | 9/10 | ⚪ doc-claim | 10 official SDKs across 8 languages (Node.js/PHP/Ruby/.NET/Java/Python/Go/Elixir) plus Laravel and Symfony; MCP-native inbound (19 tools); programmatic inbox creation; MX-verify setup |
What are Mailtrap’s pros and cons for inbound email?
Pros:
- MCP-native inbound: 19 dedicated tools let an agent create an inbox and read, reply, and forward through the same API your app uses
- Full structured JSON, and the only inbound webhook signature here we confirmed by live capture (HMAC-SHA256 over the raw body)
- Broad SDK coverage — 10 official SDKs across 8 languages, including .NET, Go, Elixir, and Java
Cons:
- Received messages draw down the same monthly volume you send from, so heavy inbound traffic eats into your sending headroom
- The spam verdict in the inbound payload is under development
Pricing
There’s no separate line item for inbound. Received and sent messages draw from one shared monthly pool – the volume on your Email API/SMTP plan.
| Email API/SMTP plan | Price | Monthly emails (sent + received) |
|---|---|---|
| Free | $0 | 4,000 |
| Basic | $15 / $20 / $30 | 10,000 / 50,000 / 100,000 |
| Business | $85 / $200 / $300 / $450 | 100,000 / 250,000 / 500,000 / 750,000 |
| Enterprise | $750 / $1,250 / custom | 1,500,000 / 2,500,000 / unlimited |
To put things into perspective, you get 4,000 emails a month on a free plan to spend however fits your needs. For example, 2,000 sent and 2,000 received emails, or 3,500 sent and 500 received. And it’s the same story for any other plan.
Now, I need to stress that if plan to set up a support alias to receive thousands of emails a month and reply to them, make sure to size the plan for your total spending, not just what you want to receive.
Security and compliance overview
DKIM, SPF, and DMARC validation on inbound. TLS in transit. HMAC-SHA256 signed inbound webhook payloads, verified end to end against live traffic. Compliance certifications: SOC 2 Type 2, SOC 3, ISO 27001, GDPR. Full current list at trust.mailtrap.io.
Postmark: best for existing Postmarks users who need rich JSON
Postmark built its reputation on transactional deliverability, and that discipline carries into the receiving side. The named three-stream (server) architecture – Transactional, Broadcast, Inbound – means inbound is a first-class stream with its own server configuration, not a feature bolted onto a sending API. If you’re already on Postmark for sending transactional email and need to close the reply loop, you’re adding a stream, not switching vendors.
Parse output is structured JSON with a detailed field set: FromName, From, FromFull, To/ToFull/Cc/Bcc with MailboxHash, Subject, MessageID, ReplyTo, Date…and the list goes on.
SpamScore appears in X-Spam-Status, X-Spam-Score, and X-Spam-Tests headers. Inbox placement signals are passed through rather than dropped. This is the richest structured payload in the comparison – it scored a full 13/13 canonical fields against our rubric.
StrippedTextReply is a practical field: it extracts only the new content from a reply thread, without quoted text. For ticketing and reply-to-email workflows, that saves you a parsing step.
MailboxHash enables per-user routing from a single server address. Append a hash to your inbound address (hash@inbound.postmarkapp.com) and route each user’s replies to the right destination without managing individual mailboxes or separate DNS records.
Webhook retry behavior is documented and predictable: 1 min → 5 min → 10 min ×3 → 15 min → 30 min → 1 hr → 2 hr → 6 hr. The server stops retrying on a 403.
However, there’s one thign I need to be upfront about. Postmark’s inbound webhook auth is not HMAC. It’s HTTP basic-auth on the webhook URL you configure; the X-Postmark-Inbound header is a routing flag, not a payload signature. So if your threat model needs a signed payload, you’re relying on the basic-auth credential and TLS, not a per-message HMAC.
See Postmark alternatives if the plan gate is a blocker.
What Postmark features ensure reliable inbound email processing?
Parse output: structured JSON; TextBody, HtmlBody, StrippedTextReply, full Headers array, Attachments with base64 Content, SpamScore via headers.
Addressing: per-server unique address with MailboxHash convention for per-user routing; custom domain via MX forwarding.
Webhook reliability: documented retry schedule; stops on 403; auth is HTTP basic-auth on the webhook URL, not payload HMAC (Reminder: X-Postmark-Inbound is a routing flag, not a signature).
Plan gate: Pro ($16.50/mo) or Platform ($18/mo) required. Basic ($15/mo) does not include inbound.
Technical Notes:
- Inbound attachments are capped at 35 MB cumulative
- Postmark doesn’t publish a cap on how many inbound addresses or servers an account may hold
Inbound email API readiness benchmark results
| Criterion | Score | Evidence | Notes |
|---|---|---|---|
| Inbound parse and routing | 9.0/10 | 🟡 doc-sample | Richest structured JSON in the comparison: 13/13 canonical fields, base64 attachment, SpamScore in headers, StrippedTextReply; MailboxHash addressing. |
| Receiving-side pricing | 2/4 | ⚪ doc-claim | Bundled with outbound; pricing public; no free tier; plan-gated (Pro/Platform) |
| Developer experience and agent-readiness | 4/10 | ⚪ doc-claim | Clear docs; solid SDK coverage; MailboxHash per-user routing; no agent inbox; no MCP |
What are Postmark’s pros and cons for inbound email?
Pros:
- Comprehensive JSON field set including StrippedTextReply – practical for reply-to-email workflows
- Most explicitly documented webhook retry schedule in this comparison
- Named three-stream architecture makes inbound a first-class integration
- Strong API documentation and developer tooling
Cons:
- Inbound requires Pro or Platform plan – not on Basic ($15/mo)
- Webhook auth is HTTP basic-auth, not a per-message HMAC signature
- No agent-readiness features (no per-agent addressing, no MCP server)
- No sandbox for testing inbound before production
Pricing
Bundled with outbound plan volume and gated behind paid tiers.
| Plans | Price | Monthly emails (sent + received) |
|---|---|---|
| Pro | $16.50/mo | From 10,000+ emails/mo |
| Platform | $18/mo | From 10,000+ emails/mo |
Security and compliance overview
SPF/DKIM/DMARC enforcement on inbound. TLS. SOC 2 Type II and GDPR are claimed account-wide, rather than scoped to one product (which is expected). PSI is inherited through Stripe for billing, and Postmark states it never touches card data.
Mailgun: best for routing depth
Mailgun’s inbound model is built around Routes; these are regex-based matching rules that fire per-pattern webhooks. If your inbound routing involves sending different message patterns to different endpoints (support tickets to one service, billing replies to another, automated notifications to a third), Mailgun is the most configurable option here.
Basically, inbound routing is a configuration system, not a single-webhook endpoint. Yet, I need to point out one thing that surfaced during our testing.
Mailgun’s Routes webhook is not JSON. It POSTs application/x-www-form-urlencoded (upgraded to multipart/form-data when a message carries attachments), with recognized headers flattened to top-level params, body-plain/body-html, stripped-* reply variants, and attachments as file parts.
That’s the same form-encoded friction SendGrid has, and it’s why Mailgun scores where it does on parse instead of up there with the JSON providers. What you get in return is the routing: per-mailbox Routes or domain-level catch-all with custom expression matching, so you can build per-user or per-department addressing without managing individual SMTP.
Good news on webhook auth: Mailgun signs every inbound POST. The signature is HMAC-SHA256(api_key, timestamp + token), delivered as a signature field on the payload.
Route limits per plan are 1 on a Free plan and 5 on a Basic plan, and that affects how you architect routing.
See Mailgun alternatives if a JSON-first inbound payload matters more to you than routing flexibility.
What Mailgun features ensure reliable inbound email processing?
Parse output: application/x-www-form-urlencoded (multipart/form-data with attachments), NOT JSON; flattened headers, body-plain/body-html, stripped-* variants, attachments as file parts; 10/13 canonical fields.
Routing: regex Routes, custom expression matching, per-pattern webhooks; domain-level catch-all or per-mailbox addressing; routing rules configurable via API or console.
Addressing: per-mailbox or domain-level catch-all; route filters for per-user routing.
Webhook auth: every POST signed – signature = HMAC-SHA256(api_key, timestamp + token) on the payload.
Inbound email API readiness benchmark results
| Criterion | Score | Evidence | Notes |
|---|---|---|---|
| Inbound parse and routing | 5.8/10 | 🟡 doc-sample | Form-encoded (not JSON), 10/13 fields; regex Routes, per-pattern webhooks; HMAC-signed webhook confirmed; route limits per plan 1 Free/5 Basic |
| Receiving-side pricing | 2/4 | ⚪ doc-claim | Bundled with outbound; pricing public; limited free tier |
| Developer experience and agent-readiness | 4/10 | ⚪ doc-claim | Solid SDK coverage; flexible routing docs; no agent inbox; no MCP |
What are Mailgun’s pros and cons for inbound email?
Pros:
- Most flexible per-pattern routing in this comparison (regex Routes, custom expressions, per-pattern webhooks)
- Domain-level catch-all plus per-mailbox routes for sophisticated addressing without per-address API calls
- Every inbound webhook is HMAC-SHA256 signed – verifiable and replay-resistant
Cons:
- Form-encoded webhook payload, not JSON – the same content-type friction as SendGrid
- Route limits per lower-tier plans
- No agent-readiness features (no per-agent inbox, no MCP server)
- No HIPAA support
Pricing
Bundled with outbound plans, check the breakdown below.
| Plans | Price | Monthly emails (sent + received) |
|---|---|---|
| Free | $0 | 100/day + 1 inbound route |
| Basic | $15 | 10,000/mo + 5 inbound routes |
| Foundation | $35 | 50,000/mo + full inbound routing |
| Scale | $90 | 100,000/mo + full inbound routing |
| Enterprise | Custom | Scale + enterprise services |
Security and compliance overview
SOC 2 Type II, ISO 27001, GDPR. No HIPAA. Security documentation: mailgun.com/security/, security.mailgun.com/
SendGrid: best for teams already on SendGrid stack
Twilio SendGrid’s Inbound Parse is not an inbound-first product. It’s an extension of a large sending platform, so the right framing is consolidation, not inbound-first design.
And, if you’re a developer note that SendGrid’s inbound webhook delivers multipart/form-data, not JSON, same as Mailgun. Raw MIME is available via a “Post raw message” toggle, which adds the full message as an email field.
Fields you get in the standard payload include: to, from, cc, subject, text, html, charsets, plus spam_score/spam_report when the spam check is enabled. Attachments get parsed inline, with a 30 MB total limit.
Also, message_id, in_reply_to, and references are not broken out as top-level fields – they live inside the raw headers blob. Consequently, if you need to thread messages, you have to parse the headers yourself. And after a 3-day retry window, events get dropped.
On webhook auth, Inbound Parse carries no HMAC signature. The signed-webhook mechanism people associate with SendGrid is the Event Webhook (a different product surface for delivery/engagement events). But, Inbound Parse itself is unsigned, so you’re relying on the obscurity of the endpoint URL and TLS, not a per-message signature.
Inbound Parse is on Pro ($89.95/mo+) and Premier only. Not on Essentials.
When all is said and done, SendGrid inbound is best for teams already using other Twilio services. That’s the honest value proposition.
See SendGrid alternatives for providers with JSON-first inbound webhooks.
What SendGrid features ensure reliable inbound email processing?
Parse output: multipart/form-data (NOT JSON); to, from, cc, subject, text, html, charsets, spam_score/spam_report (when spam check enabled); 8/13 canonical fields (message_id/in_reply_to/references live in the raw headers blob, not top-level); raw MIME optional via “Post raw message” toggle; inline attachments; 30 MB total limit.
Addressing: subdomain + domain combos; each combination must be unique; implicit catch-all at subdomain level; authenticated domain required.
Webhook reliability: 3-day retry window; Inbound Parse is unsigned (HMAC signing is the separate Event Webhook surface, not Inbound Parse).
Plan gate: Pro ($89.95/mo+) and Premier only. Not on Essentials.
Inbound Email API Readiness Benchmark results
| Criterion | Score | Evidence | Notes |
|---|---|---|---|
| Inbound parse and routing | 5.8/10 | 🟡 doc-sample | multipart/form-data (not JSON), 8/13 fields; no per-pattern routing; Inbound Parse unsigned (no HMAC); raw MIME optional; 30 MB cap |
| Receiving-side pricing | 2/4 | ⚪ doc-claim | Bundled; pricing public; gated behind Pro ($89.95/mo+) and Premier |
| Developer experience and agent-readiness | 3/10 | ⚪ doc-claim | Decent SDK coverage; multipart/form-data complicates standard integrations; no agent inbox; no MCP |
What are SendGrid’s pros and cons for inbound email?
Pros:
- Single vendor for send + receive if you’re already on SendGrid
- Twilio ecosystem integration for teams using Twilio for other services
- 3-day retry window gives reasonable buffer for endpoint downtime
Cons:
multipart/form-datawebhook payload, not JSON – requires content-type handling the JSON providers don’t- Pro+ only – not available on Essentials; plan upgrade required
- Inbound Parse is unsigned
- No per-pattern routing; no agent-readiness features; no dedicated agent inbox
Pricing
Bundled with outbound plan, and limited to Pro and Premier, see below.
| Plans | Price | Monthly emails (sent + received) |
|---|---|---|
| Pro | $89.99 | 100,000 – 2.5M emails/mo |
| Premier | Custom | 5M+ emails/mo |
Security and compliance overview
Twilio security information at security.twilio.com/, however, note that Twilio has a public disclaimer stressing that certifications don’t apply to all their products equally. So, it’s best to reach out directly to determine which certifications might not apply to inbound.
Amazon SES: best for raw receiving cost and AWS-native routing
Amazon SES email receiving is the raw email infrastructure and several managed providers sit on. At $0.10 per 1,000 received messages – it’s the cheapest option here by a meaningful margin.
But, in a distinctly SES manner, that price comes with a price 😀.
SES delivers raw, unmodified MIME to S3, SNS, or a Lambda function. No structured parse. No JSON. No webhook to a configured endpoint – and so no webhook HMAC to verify. There’s like a workaround, route via SNS and SNS signs its own messages. But that’s the AWS notification layer, not an inbound-payload signature.
In our tests, the raw-MIME delivery lands at 2/13 canonical fields, the lowest parse help in the comparison, by design. Amazon SES doesn’t hold a grudge against raw MIME; it’s doing exactly what it was designed to do – deliver the envelope intact.
The Authentication-Results, X-SES-Spam-Verdict, and X-SES-Virus-Verdict headers are added on inbound, so the spam verdict is there. But, you guessed it – the data lives in the raw headers, not a parsed field. Everything else – field extraction, MIME parsing, attachment handling, routing logic, retry semantics – is on you and your Lambda.
Every managed provider in this comparison is building the parse layer you’d write yourself on top of SES. Whether you pay for that in API pricing or in engineering hours is the real build-vs-buy calculation. I did some digging and here’s an email scope where ‘build’ starts to make sense.
At roughly $0.10/1K received, the math favors SES somewhere above ~1M messages per month if you have the ops capacity. Below that volume, managed APIs routinely win on total cost of ownership.
Important technical note (surfaced during testing): receipt rule configuration is only available in the classic SES API, not SESv2. If you’re starting a new integration and assumed SESv2 covers everything, it doesn’t – receipt rules and the classic SES API are where inbound lives.
Mail Manager (the newer layer, built on SES email infrastructure) adds mTLS-authenticated SMTP relay endpoints and doesn’t require domain verification for those endpoints. For enterprise-scale inbound routing, that’s a real addition. See the Mail Manager announcement for details.
What Amazon SES features ensure reliable inbound email processing?
Parse output: raw unmodified MIME – no structured JSON, no field extraction. SES adds Authentication-Results, X-SES-Spam-Verdict, X-SES-Virus-Verdict headers. Developer handles all MIME parsing.
Routing: S3 delivery, SNS notifications, Lambda triggers. Mail Manager for advanced routing rules and mTLS SMTP endpoints.
Addressing: recipient-based receipt rules on verified domains/subdomains; catch-all via no-recipient condition; Mail Manager adds mTLS SMTP relay without domain verification per endpoint.
API version reminder: receipt rules are in the classic SES API only – not SESv2. Plan for two API surfaces if you’re building a new integration.
Infrastructure integration: IAM access control, CloudWatch/CloudTrail audit logging, regional data residency, AWS SDK integration across all supported languages.
Inbound email API readiness benchmark results
| Criterion | Score | Evidence | Notes |
|---|---|---|---|
| Inbound parse and routing | 2.5/10 | 🟡 doc-sample | Raw MIME only, by design; S3/SNS/Lambda routing; spam/virus verdicts in raw MIME headers; no webhook HMAC; Mail Manager adds routing depth |
| Receiving-side pricing | 3/4 | ⚪ doc-claim | Per-received pricing; pricing public; no free inbound tier |
| Developer experience and agent-readiness | 2/10 | ⚪ doc-claim | High setup friction; Lambda SDK integration; no structured parse docs; no agent inbox; no MCP; classic-SES vs. SESv2 split adds complexity |
What are Amazon SES’s pros and cons for inbound email?
Pros:
- Lowest raw receiving cost in this comparison ($0.10/1K received)
- AWS-native: IAM, CloudWatch, CloudTrail, regional control
- Direct S3/SNS/Lambda routing without middleware
- Mail Manager for enterprise inbound routing at scale
Cons:
- No structured parse – all MIME parsing and field extraction is on the developer
- Receipt rules in classic SES API only (not SESv2) – two API surfaces for a new integration
- Highest setup friction of any provider here (domain verification, MX records, receipt rules, region selection)
- No agent-readiness features
- Regional limitations on SES receiving (not all regions support it)
Pricing
Compared to every other provider, SES has a completely different pricing structure and it’s treated as an add-on. Here’s the breakdown, with out the table as these are treated separately:
- $0.10 per 1,000 received messages
- $0.09 per 1,000 incoming chunks (256 KB blocks)
- Mail Manager: $0.15/1,000 messages + $50/month per endpoint.
Security and compliance overview
AWS security controls: TLS, IAM, CloudTrail audit logging, regional data residency. Spam and virus verdicts added to inbound MIME headers. SES compliance certifications include SOC, PCI, FedRAMP, HIPAA, as scoped to SES itself.
AgentMail: best for agent-native inbox primitives
AgentMail is not a general-purpose inbound processing API. That’s the most important thing to understand before comparing it to the other five providers here.
Where Mailtrap, Mailgun, and Postmark receive an email, parse it into structured fields, and fire a webhook to your endpoint, AgentMail gives an agent a persistent, indexed inbox that stores and threads messages over time. The message stays alive, searchable, and queryable. The agent can follow conversation threads, search inbox history by content, and compose replies with or without human review before send.
The MCP server is at https://docs.agentmail.to/_mcp/server with official integrations for Claude, Cursor, LangChain, Google ADK, and Replit.
As cool as it is, I’d need to also stress what AgentMail does not do – traditional catch-all routing, or per-pattern webhook rules. Every inbox address has to be creaded explicitly through the API before it can receive an email. The wildcard MX they offer opens arbitrary subdomains, not arbitrary usernames at one domain. And webhooks scope by inbox or pod, capped at 10 each, with no rule matching on sender, recipient, or subject.
If you need to route incoming support tickets to a webhook by address pattern, Mailtrap or Mailgun are the right fit. AgentMail is the right tool when the agent itself is the endpoint that needs to read, search, and respond to mail over time.
Important Technical Notes (based on our tests):
- AgentMail documents that an inbound email failing SPF, DKIM, or DMARC gets dropped after the SMTP handshake, with no bounce. In their own words, the sender server: “may still report successful delivery because AgentMail’s servers did receive the message, but it was rejected during authentication verification.”
- There’s another more, subler trap. AgentMail keeps the email, but marks it as
spam,blocked, orunauthenticated. This email gets excluded frommessages.listand search unless you pass the matchinginclude_flag. More importantly, these types of webhook events are opt-in, meaning that two of them additionally requirelabel_spam_readorlabel_blocked_readon the API key. Simply, this may cause that an email sitting in an inbox gets invisible to the agent because it was never opted to hear about it.
To the above, filtered and lost emails may look the same from the agent side unless you instruct it properly. So if you’re building something that shouldn’t miss a single email, pool with the inlude_ flag, and reconcile against your webhook stream.
Inbound infrastructure note: AgentMail’s inbound path runs on Amazon SES – agentmail.to MX record resolves to inbound-smtp.us-east-1.amazonaws.com. Keep in mind that it’s a managed infrastructure if you have data-residecy constraints; eg. an EU API host (api.agentmail.eu), but the inbound MX resolves to us-east-1.
What AgentMail features ensure reliable inbound email processing?
- Persistent indexed inboxes – messages stay queryable over time, not dropped after webhook delivery
- Native threading – thread_id baked into the data model; no reconstruction from Message-ID headers
- Semantic search across inbox history – agents query by content, not just metadata filters
- Real-time WebSocket push – no polling interval
- Human-in-the-loop drafts – compose/approve/send workflow built into the API
- MCP server with official integrations: Claude, Cursor, LangChain, Google ADK, Replit
- Programmatic per-agent inbox creation – instant, no DNS per address for @agentmail.to
- Pods for multi-tenant inbox isolation
- Allowlists and blocklists per inbox
- Attachment parsing and extraction
- Per-inbox API key scoping
Inbound Email API Readiness Benchmark results
A note on reading AgentMail’s parse score: the parse & routing dimension measures traditional receive-parse-route capability, and AgentMail is deliberately not that – it’s an inbox-as-primitive, so its mid-table parse score reflects a design choice, not a defect. Its real strength is the agent-readiness row. I read it live all the same, on its own inbound path.
| Criterion | Score | Evidence | Notes |
|---|---|---|---|
| Inbound parse and routing | 6.3/10 | 🟢 live | Structured JSON, 10/13 fields; extracted_text reply-stripping and native thread_id; inbox-as-primitive, not catch-all routing by design. |
| Receiving-side pricing | 4/4 | ⚪ doc-claim | Per-received volume pricing; pricing public; free tier available |
| Developer experience and agent-readiness | 7/10 | ⚪ doc-claim | Instant programmatic inbox creation; per-agent addressing; MCP server; WebSockets; traditional SDK coverage limited |
What are AgentMail’s pros and cons for agent email?
Pros:
- Only provider in this comparison with persistent indexed inboxes, native threading, and semantic search as API-native primitives
- MCP server with integrations – agents can wire themselves without glue code
- Volume-based pricing with a usable free tier (3 inboxes, 3,000 emails/month)
- Real-time WebSocket push eliminates polling overhead
- Human-in-the-loop draft flow built into the API
Cons:
- Not a substitute for traditional inbound processing (catch-all routing, per-pattern webhooks, structured MIME parsing for reply-to-email app workflows)
- No visual monitoring dashboard – a consistent complaint in developer community feedback
- Newer product; smaller track record than Postmark, Mailgun, or Mailtrap
Pricing
Volume-based, priced per inbox capacity and monthly email volume, check the breakdown.
| Plans | Price | Monthly emails (sent + received) |
|---|---|---|
| Free | $0 | 3,000/month + 3 inboxes |
| Developer | $20 | 10,000/month + 10 inboxes |
| Startup | $200 | 15,000/day + 150 inboxes |
| Enterprise | Custom | Usage-based + unlimited inboxes |
Security and compliance overview
SPF/DKIM/DMARC handling documented. Infrastructure not publicly disclosed.
How we tested the best inbound email APIs
We ran one inbound benchmark across all six providers on three axes:
- Parse & routing
- Receiving-side pricing
- Developer/agent-readiness.
Parse & routing is the live-measurable core – we sent a fixed corpus (plain multipart, threading, odd charset, an attachment, a spam-bait GTUBE string) and scored exactly what each provider handed back.
Two providers we could run end to end on their real inbound path (Mailtrap, AgentMail) and those rows are marked 🟢 live.
The other four sit behind a paid account or a public webhook URL, so we scored each against its own published sample payload through the identical rubric and marked those rows 🟡 doc-sample. Facts that aren’t sample-able – pricing tiers, SDK counts – are marked ⚪ doc-claim. Every cell says which it is; nothing here is a hand-wave.
The rubric, so you can see how the parse numbers are built (0-10):
- + format (JSON 4 / multipart 2 / raw-MIME 0)
- + field coverage (0-3, scaled across 13 canonical fields)
- + HMAC (verified 1 / present 0.5 / none 0)
- + attachment decode (1)
- + spam verdict surfaced (1).
Same numbers for a live capture and a doc-sample – only the evidence grade differs.
| Provider | Parse & routing | Evidence | Note |
|---|---|---|---|
| Mailtrap | 8.8/10 | 🟢 live | Structured JSON, 12/13 fields, attachment decodes, live-verified webhook HMAC; no spam verdict in payload (by design) |
| Postmark | 9.0/10 | 🟡 doc-sample | Richest structured JSON: 13/13 fields, base64 attachment, spam score |
| AgentMail | 6.3/10 | 🟢 live | Structured JSON, 10/13 fields, extracted_text reply-stripping + native thread_id |
| SendGrid | 5.8/10 | 🟡 doc-sample | multipart/form-data (not JSON), 8/13 fields, Inbound Parse unsigned |
| Mailgun | 5.8/10 | 🟡 doc-sample | multipart/form-data, 10/13 fields, HMAC-signed webhook |
| Amazon SES | 2.5/10 | 🟡 doc-sample | Raw MIME only, 2/13 fields – you write the parser; verdicts via headers |
Worth reading the two scores in context, though: Mailtrap’s 8.8 is 🟢 live and carries the only inbound signature we verified by capture, while Postmark’s 9.0 is 🟡 doc-sample and its inbound auth is basic-auth rather than HMAC.
Mailtrap’s overall #1 rests on the combination the others don’t have – testable inbound via Email Sandbox plus the AI Agent Email Inbox and MCP-native inbound tools – not on winning the parse row. That’s the difference between a roundup you can trust and a shill.
Inbound parse and routing
Key findings:
- Amazon SES is the only provider delivering raw unmodified MIME with no structured parse – by design (2/13 fields).
- SendGrid and Mailgun both deliver form-encoded payloads (
multipart/form-data), not JSON. Postmark, Mailtrap, and AgentMail deliver structured JSON – the format split is the single biggest driver of the parse scores. - AgentMail adds persistent storage, threading, and semantic search on top of structured delivery – a different architectural model.
- Mailgun has the most flexible per-pattern routing (regex Routes with custom expressions and per-pattern webhook payloads) and signs every webhook (HMAC-SHA256).
- Postmark has the most explicitly documented webhook retry schedule – and the richest parse (13/13 fields, the top parse score here). But, its webhook auth is HTTP basic-auth, not a payload HMAC.
- Mailtrap (12/13) and Postmark (13/13) lead on parse field completeness; Mailtrap is also the only provider whose inbound webhook signature we confirmed by live capture rather than from docs (
mailtrap-signature, HMAC-SHA256 over the raw body).
Receiving-side pricing
Most email APIs are designed around sending. Inbound receiving is typically either bundled with the outbound plan, gated behind a higher plan tier, or missing from the pricing page entirely.
Practical Note: If the webhook fires, the retry fires, but if the retry window expires, the event drops, then the user’s reply disappears, and support gets the ticket. Keep in mind that the retry window length is determined by the receiving pricing plan. Therefore, choose accordingly.
| Provider | Pricing model | Notes |
|---|---|---|
| Mailtrap | Shared with sending volume | Free 4,000/mo Basic $15 ( from 10K emails) Business $85 ( from 100K emails) One pool both directions; replies and forwards count as sends |
| Postmark | Bundled with outbound | Pro/Platform only ($16.50-$18/mo); received volume counts against outbound |
| Mailgun | Bundled with outbound | 1 route on Free 5 on Basic ($15) Foundation ($35) Scale ($90) |
| SendGrid | Bundled with outbound | Included on all tiers; 60-day trial, no permanent free tier Essentials from $19.95/mo, Pro from $89.95/mo; |
| Amazon SES | $0.10/1,000 received | Only provider with per-received pricing; $0.09/1K chunks; Mail Manager adds $0.15/1K + $50/mo/endpoint |
| AgentMail | Volume-based | Free (3K/mo), Developer $20/mo (10K), Startup $200/mo (150K) |
For teams weighing managed inbound vs. self-hosted: MXHook is an Apache 2.0 open-source SMTP-to-JSON inbound webhook server worth knowing. It receives on any domain, parses to structured JSON (RFC 5322-compliant), HMAC-SHA256 signs with X-MXHook-Signature, and retries with exponential backoff. This is the keep-data-in-network alternative to any managed API.
Developer experience and agent-readiness
Setup friction, API documentation quality, SDK coverage, and agent tooling were the main focus points. But note that the best email API for developers isn’t the one with the most features – it’s the one with the shortest path from “email arrives” to “my code processes it correctly.”
Setup friction: Mailtrap and AgentMail have the lowest friction for programmatic inbox creation (API call → address live). Postmark and Mailgun require MX forwarding setup for custom domains. SendGrid requires domain authentication plus unique subdomain configuration. Amazon SES has the highest setup friction: domain verification, MX records, receipt rule configuration in the classic SES API, and region selection.
SDK and documentation coverage: Mailtrap leads on language breadth (Node.js, PHP, Ruby, .NET, Java, Python, Go, Elixir, plus Laravel and Symfony packages – 10 official SDKs). Postmark and Mailgun have solid coverage. AgentMail has more limited traditional SDK coverage but a first-class MCP. Email logs and delivery event visibility varies – check the api documentation for each provider. Language-specific integration guides on the Mailtrap blog: Node.js, Python, PHP, Java.
Agent-readiness: The picture splits between two categories, though the gap narrowed in August 2026.
- For traditional inbound + agent features: Mailtrap ships a scoped per-agent addressing and MCP-native inbound tools (19 of them – inbox CRUD, message list/get/reply/reply-all/forward, threads), so an agent can drive a Mailtrap inbox over MCP directly.
- For agent-native inbox-as-primitive: AgentMail ships an MCP server, persistent inboxes, threading, and semantic search as the core product.
Both are now MCP-native on inbound; the difference is architectural – Mailtrap wraps a full processing pipeline, AgentMail makes the inbox itself the primitive. For the broader picture on the AI agent email space, see best email API for AI agents and best email MCP servers.
Wrapping up
Inbound email APIs split into three categories. Mailtrap, Postmark, and Mailgun, deliver structured JSON webhooks with documented retry policies – the core capability most inbound email processing workflows need.
SendGrid’s Inbound Parse works but arrives as multipart/form-data and sits behind a plan gate. Amazon SES is the raw baseline everything else is built on: lowest cost, highest setup investment, no structured parse.
AgentMail is a different primitive entirely – persistent, indexed, agent-native inboxes that don’t map onto traditional inbound routing but are purpose-built for autonomous agents that need to live in email over time.
Mailtrap lands at #1 for the combination no other provider here delivers: solid structured-JSON inbound parse, MCP-native inbound tools plus a purpose-built AI Agent Email Inbox for scoped agent addressing, and Email Sandbox for validating the whole pipeline before a production MX record ever points at it.
The benchmark grades every score by the evidence behind it – 🟢 live where we captured real inbound traffic (Mailtrap, AgentMail), 🟡 doc-sample where we scored the provider’s own published payload through the same rubric (Postmark, SendGrid, Mailgun, SES). Where a cell was still open at publish time, it’s flagged in place rather than guessed.
Choose Mailtrap for developer experience and agent-native inbound. It has MCP-driven inboxes, the broadest SDK coverage, and high-deliverability sending and email testing workflows.
Choose Postmark when you’re already on Postmark for sending and need to close the reply loop with reliable JSON parsing – and you’re on Pro or Platform.
Choose Mailgun when your receive workflow involves routing different message patterns to different endpoints using regex routing rules and per-pattern webhooks.
Choose SendGrid when your team is already on SendGrid’s sending stack and want inbound in the same platform.
Choose Amazon SES when you have AWS ops capacity, need raw receiving cost at scale, and have the Lambda budget to write your own parse layer.
Choose AgentMail when you want an inbox primitive purpose-built for autonomous agents – persistent, searchable, threaded – and don’t need traditional catch-all routing or per-pattern webhook rules.
FAQ
How do you choose an inbound email API, and what should you compare across providers?
Start with what your code needs from a received message. If your app parses replies and routes them to the right workflow – ticketing, e-commerce returns, subscription management via a CRM webhook – you need structured JSON output, documented webhook retry behavior, and HMAC-signed payloads. If you’re giving autonomous agents real email identities, you need per-agent inbox addressing and – ideally – persistent indexed storage so the agent can query history.
Key dimensions to compare across inbound email APIs: parse output format (structured JSON vs. raw MIME vs. multipart/form-data), addressing model (catch-all, per-user programmatic, multi-tenant), webhook retry policy and signing, plan gates (Postmark and SendGrid both gate inbound behind paid tiers), and agent-readiness features. For context on the full email API landscape including the sending side, see best email API.
How does inbound email parsing and routing actually work?
When an email arrives at your domain, the MX record tells the sending mail server where to deliver it. The inbound email API sits at that delivery endpoint: it handles the SMTP connection, runs the message through its parse layer, and fires a webhook to your configured endpoint with the extracted fields.
What lands in that webhook payload varies significantly. Postmark, Mailgun, and Mailtrap deliver structured JSON with full body text, HTML, headers, and base64-encoded attachments. SendGrid delivers multipart/form-data. Amazon SES skips the parse entirely and delivers raw MIME to S3 or Lambda. AgentMail stores the message in a persistent indexed inbox and optionally pushes a WebSocket notification.
For catch-all and per-user addressing, providers differ: some use a catch-all inbox on a configured subdomain, some allow programmatic per-user inbox creation via API, and some (like AgentMail) let agents register their own scoped inboxes without DNS configuration per address. See also organization and sub-accounts for multi-tenant addressing patterns.
Is there a free inbound email API, and how is inbound email processing priced?
Yes – Mailtrap free tier offers 4,000 emails per month and up to 10 inboxes without custom MX. AgentMail’s free tier includes 3 inboxes and 3,000 emails/month at no cost. Mailgun includes a limited free tier with inbound routing.
Most providers bundle inbound with the outbound plan rather than pricing per-received message. The exception: Amazon SES charges $0.10 per 1,000 received, making it the only provider with explicit per-message inbound pricing.
Can you receive email programmatically without running your own mail server?
Yes – all six providers here enable exactly that. Point your domain’s MX records at the provider’s servers, configure your receiving settings (webhook URL, routing rules, inbox addresses), and the API handles SMTP reception.
The degree to which you’re “running a server” still varies. Amazon SES requires you to build the parse layer on top of raw MIME delivery. Mailtrap, Postmark, Mailgun, and AgentMail handle the parse and deliver structured data to your code.
For full data control without a managed provider, self-hosted options include MXHook (SMTP-to-JSON webhook, Apache 2.0) and Postfix with a custom processing pipeline.
Which inbound email API is best for AI agents and per-user email addresses?
For AI agents needing persistent, indexed inboxes with native threading, semantic search, and MCP-server integration, AgentMail is built for exactly this. It’s not a general-purpose inbound API – it doesn’t replace catch-all domain routing for traditional app workflows – but for an agent that needs its own email identity and the ability to query its own inbox history, it has no direct equivalent here.
For teams wanting inbound processing combined with scoped agent inboxes – validate in sandbox, process at the inbound API layer, route to per-agent inboxes, Mailtrap does the trick natively. Its combination of MCP server with 19 inbound tools alongside the outbound sending, sandbox, and template tools, helps an agent drive a Mailtrap inbox over MCP directly.
Per-user email addresses work differently across providers: Postmark uses MailboxHash for per-user routing from a single server address; Mailgun uses per-mailbox Routes; Mailtrap and AgentMail support programmatic per-user inbox creation via API. For the full picture, see best email API for AI agents and best email MCP servers.
How do inbound email APIs handle webhook reliability, deduplication, and compliance?
Webhook retry policy and HMAC signing are the two reliability variables that matter most in production.
Postmark has the most explicitly documented retry schedule: 1 min → 5 min → 10 min ×3 → 15 min → 30 min → 1 hr → 2 hr → 6 hr; stops on 403. Mailtrap’s inbound webhooks retry on exponential backoff, up to 10 attempts across 24 hours. SendGrid’s retry window is 3 days, then events are dropped. Mailgun’s webhook retry policy is not publicly documented. Amazon SES is not webhook-based: it delivers to S3/SNS/Lambda, where SNS has its own retry semantics and S3 is durable.