TL;DR: The best inbound email parsing API depends on what you're building. For AI agents and automated pipelines, Mails.ai delivers structured JSON webhooks, built-in classification, and MCP-native tooling at $0.002/inbound — purpose-built for code that reads email, not humans.
The best inbound email parsing API isn't the most popular one — it's the one that drops a clean, structured payload on your webhook without you spending two days writing MIME parsers. Four credible options exist: Mailgun Inbound, SendGrid Inbound Parse, Postmark Inbound, and Mails.ai. They all receive email and fire a webhook. The differences — payload structure, latency, classification, threading support, pricing — determine which one actually fits your production system.
This guide makes the call for each use case.
What inbound email parsing actually does
An inbound email parsing API sits between the internet's mail infrastructure and your application code. It accepts SMTP connections at an MX record you control, processes the raw RFC 5322 message, extracts structured fields, and delivers everything to your webhook as JSON — so your code never touches raw MIME.
The MX record is the entry point. You point mail.yourdomain.com MX 10 inbound.provider.com and every message to that subdomain lands at the provider's ingestion infrastructure. From there:
- SMTP reception — the provider's MTAs accept the connection, perform SPF/DKIM verification on the sender, and queue the message.
- MIME parsing — the multipart body is decoded:
text/plain,text/html, base64-decoded attachments, inline images. - Header extraction —
From,To,Cc,Subject,Message-ID,In-Reply-To,Referencesare parsed into discrete fields. - Webhook delivery — the provider POSTs a JSON payload (or, in some cases, multipart form data) to your endpoint with a configurable retry policy.
What does that JSON look like, and how much work is left after you receive it?
sequenceDiagram
participant Sender
participant MX as Provider MX
participant Parser as MIME Parser
participant WH as Your Webhook
Sender->>MX: SMTP MAIL FROM RCPT TO DATA
MX->>Parser: Raw RFC5322 message
Parser->>Parser: Extract headers attachments body
Parser->>WH: POST JSON payload
WH->>WH: Route classify act
The four contenders: architecture comparison
Mailgun Inbound Routes
Mailgun's inbound pipeline is built around Routes — regex or header-match rules that trigger actions (forward, store, webhook). The webhook payload is multipart/form-data, not JSON. That matters: your endpoint has to parse a form body, then parse the body-mime field (a raw MIME string) if you want attachment access. Attachments arrive as separate form fields.
Payload structure (simplified):
recipient=you@domain.com
sender=them@external.com
subject=Re: Order 4821
body-plain=Thanks for the update...
body-html=<html>...
message-headers=[["Received",...],["Message-Id","<abc@mail.gmail.com>"],...]
attachment-count=1
attachment-1=<binary file>
Message-ID and In-Reply-To are buried inside the message-headers JSON array — you have to iterate it. For threading in agent workflows, that's real friction. Mailgun verifies SPF/DKIM and exposes results in the headers array, but doesn't surface them as top-level fields.
The route matching is flexible for sending to multiple endpoints, but each route is a separate configuration object. At scale with many agent mailboxes, that becomes a management problem.
Pricing: Inbound parsing is bundled into sending plans. The Flex plan charges $0.80/1,000 messages sent, with inbound processing included. For pure inbound-heavy workloads — agents receiving thousands of replies — you're paying for sending capacity you don't use.
SendGrid Inbound Parse
SendGrid's Inbound Parse posts multipart/form-data with a structure similar to Mailgun. The headers field is a raw string, not parsed — you get Message-ID: <abc123@mail.gmail.com>\r\nFrom: ... and you parse it yourself. Attachments are separate form fields.
SPF results appear in a dkim field and a SPF field as plain strings (pass, fail). Threading fields (In-Reply-To, References) are only accessible by parsing the raw headers string.
SendGrid Inbound Parse has a known architectural limitation: it doesn't enforce TLS on inbound connections the way dedicated inbound APIs do. For security-sensitive workflows, that matters.
Inbound parse is configured per-domain, not per-address. Every email to *@yourdomain.com hits the same webhook. Routing by recipient means parsing To or envelope yourself.
Pricing: Free on paid plans. Essentials starts at $19.95/month for 50K emails. No per-inbound pricing — and no granular inbound tooling either.
Postmark Inbound
Postmark's inbound processing is the cleanest of the traditional providers. The webhook is JSON, not form-data, and the payload is well-normalized:
{
"From": "sender@example.com",
"FromName": "Alice",
"To": "inbox@yourdomain.com",
"Subject": "Re: Support ticket 1042",
"MessageID": "<abc123@mail.example.com>",
"ReplyTo": "",
"MailboxHash": "ticket-1042",
"TextBody": "Thanks for your help...",
"HtmlBody": "<html>...",
"StrippedTextReply": "Thanks for your help...",
"Headers": [
{ "Name": "In-Reply-To", "Value": "<original@mail.example.com>" }
],
"Attachments": [...]
}
The MailboxHash is useful: if you send from reply+{hash}@yourdomain.com, Postmark extracts the hash into its own field. That's the standard pattern for correlating replies to a context — ticket ID, agent session ID, order number. StrippedTextReply attempts to remove quoted reply text. Useful, not always accurate.
Threading fields (In-Reply-To, References) live in the Headers array — one step better than raw strings, but still not top-level. No built-in classification, no content-based routing.
Pricing: $1.25/1,000 messages, sent or received combined. At 10,000 inbound messages/month, that's $12.50. Clean and predictable, but blended with sending volume.
Mails.ai Inbound
Mails.ai's inbound parsing was built for agents and automated systems — not bolted onto a sending API as an afterthought, but designed as a first-class inbound pipeline. The differences show up in the payload and in what happens before the webhook fires.
Payload structure:
{
"event": "inbound.received",
"message_id": "<abc123@mail.example.com>",
"in_reply_to": "<original@mail.example.com>",
"references": ["<original@mail.example.com>"],
"from": { "address": "user@example.com", "name": "Alice" },
"to": [{ "address": "agent+session-42@yourdomain.com" }],
"subject": "Re: Your report is ready",
"text": "Looks good, please proceed.",
"html": "<html>...",
"stripped_reply": "Looks good, please proceed.",
"spf": "pass",
"dkim": "pass",
"classification": "approval",
"attachments": [
{
"filename": "report.pdf",
"content_type": "application/pdf",
"size": 84210,
"url": "https://..."
}
],
"received_at": "2026-08-18T09:14:33Z"
}
message_id, in_reply_to, and references are top-level fields — no header parsing required. Same for spf and dkim. The classification field is the differentiator: Mails.ai's opt-in classification pipeline runs intent detection (approval, rejection, question, unsubscribe, bounce-feedback, and more) before the webhook fires, so your agent handler can branch on classification without an LLM call per message.
That matters when a human reply of "yes, go ahead" needs to trigger a downstream action. The classification surfaces that intent structurally.
Mails.ai also exposes a Model Context Protocol server (@mailsai/mcp-server on npm), so LLM-based agents can call read_inbox, send_reply, and get_thread as native MCP tools — no custom webhook infrastructure needed.
Pricing: $0.002 per inbound message (delivery + injection scan included). Classification is +$0.003/message, opt-in. At 10,000 inbound messages/month: $20 base, $30 with classification. Pure pay-per-use, no monthly seat fee.
Feature comparison table
| Feature | Mailgun | SendGrid | Postmark | Mails.ai |
|---|---|---|---|---|
| Webhook format | multipart/form | multipart/form | JSON | JSON |
Message-ID top-level |
❌ (in array) | ❌ (raw string) | ✅ | ✅ |
In-Reply-To top-level |
❌ | ❌ | ❌ (in array) | ✅ |
| SPF/DKIM top-level | ❌ | Partial | ❌ | ✅ |
| Stripped reply body | ❌ | ❌ | ✅ | ✅ |
| Built-in classification | ❌ | ❌ | ❌ | ✅ (opt-in) |
| MCP-native tools | ❌ | ❌ | ❌ | ✅ |
| Per-address routing | Via routes | Domain-level only | Via hash | Per-address |
| Inbound pricing | Bundled | Bundled | Blended/1K | $0.002/msg |
| TypeScript SDK | ❌ | ❌ | Community | @mailsai/sdk |
When to use each
Choose Mailgun if you're already deep in its ecosystem for sending and need basic inbound routing to a few endpoints. The route matching is flexible. Don't choose it if you need clean threading data — you'll spend real engineering time on header extraction.
Choose SendGrid Inbound Parse if your team already uses SendGrid for transactional sending and your inbound volume is low. The domain-level routing is a genuine limitation for multi-tenant or multi-agent setups.
Choose Postmark if you need a clean JSON webhook and a straightforward use case: support ticket ingestion, contact form replies, notification confirmations. The MailboxHash pattern works well. It's not built for agents — no classification, no MCP — but it's reliable and well-documented.
Choose Mails.ai if:
- You're building an AI agent that reads and acts on email replies
- You need threading fields (
In-Reply-To,References) without writing a header parser - You want classification to branch agent logic without an extra LLM call per message
- Your architecture is MCP-native or you're building on an LLM framework (LangGraph, CrewAI, AutoGen)
- You want per-message pricing that scales to zero when idle
The Mails.ai API exposes inbound configuration, webhook management, and address provisioning through a REST API with a TypeScript SDK (npm install @mailsai/sdk).
Implementing inbound parsing with Mails.ai
Here's what a production inbound handler looks like with the TypeScript SDK:
import { MailsaiWebhook } from '@mailsai/sdk';
import type { InboundEvent } from '@mailsai/sdk';
// Express handler (same pattern works for Next.js API routes, Hono, etc.)
app.post('/webhooks/inbound', async (req, res) => {
// Verify the webhook signature (HMAC-SHA256)
const event = MailsaiWebhook.verify<InboundEvent>(
req.body,
req.headers['x-mailsai-signature'] as string,
process.env.MAILSAI_WEBHOOK_SECRET!
);
if (event.event !== 'inbound.received') {
return res.sendStatus(200);
}
// Threading — no header parsing needed
const threadId = event.in_reply_to ?? event.message_id;
const sessionId = extractSessionId(event.to[0].address); // e.g. agent+session-42@
// Branch on classification without an extra LLM call
switch (event.classification) {
case 'approval':
await resumeAgentWorkflow(sessionId, { approved: true, text: event.stripped_reply });
break;
case 'rejection':
await resumeAgentWorkflow(sessionId, { approved: false, text: event.stripped_reply });
break;
case 'question':
await routeToHumanQueue(sessionId, event.text);
break;
default:
await logForReview(event);
}
res.sendStatus(200);
});
For Python-based backends (the Python SDK isn't on PyPI yet), hit the REST API directly:
import hmac, hashlib, json
from flask import Flask, request, abort
app = Flask(__name__)
WEBHOOK_SECRET = os.environ['MAILSAI_WEBHOOK_SECRET']
@app.post('/webhooks/inbound')
def inbound():
sig = request.headers.get('X-Mailsai-Signature', '')
expected = hmac.new(
WEBHOOK_SECRET.encode(),
request.get_data(),
hashlib.sha256
).hexdigest()
if not hmac.compare_digest(sig, expected):
abort(401)
event = request.get_json()
thread_id = event.get('in_reply_to') or event['message_id']
classification = event.get('classification')
# ... route to agent logic
return '', 200
Webhook signature verification is non-negotiable in production. An unauthenticated inbound webhook is a direct vector for injecting fake emails into your agent's decision loop.
Pricing at scale
For an agent platform handling 50,000 inbound messages per month:
| Provider | Inbound cost | Notes |
|---|---|---|
| Mailgun Flex | ~$40 (blended) | Tied to sending plan, route complexity |
| SendGrid Essentials | $19.95/mo flat | Inbound included, but domain-level only |
| Postmark | $62.50 | $1.25/1K blended with sends |
| Mails.ai (base) | $100 | $0.002 × 50K, no seat fee |
| Mails.ai + classify | $250 | +$0.003 × 50K for classification |
At lower volumes (under 10K/month), Mails.ai is cheaper than Postmark and competes directly with SendGrid's flat fee — without the domain-level routing limitation. At higher volumes, the classification value offsets the per-message cost: a single GPT-4o call for intent classification runs $0.003–0.01 per message depending on input length. Mails.ai's classification at $0.003 sits at the floor of that range.
For a deeper look at how sender reputation and deliverability interacts with inbound — particularly for reply-heavy agent workflows — the architecture section covers the full picture.
Frequently Asked Questions
What's the difference between inbound email parsing and a full email API?
Inbound parsing is one component of an email API for agents. A full email API handles both directions: sending (SMTP injection, template rendering, bounce handling) and receiving (MX routing, MIME parsing, webhook delivery). Mails.ai provides both. Specialized tools like mx-email-parser handle only the MIME parsing step — you still need to provision MX records and handle SMTP reception separately.
How do threading fields like In-Reply-To work in practice?
In-Reply-To contains the Message-ID of the email being replied to. When your agent sends an email with a known Message-ID, any human reply will include In-Reply-To: <that-message-id>. That lets you correlate the reply to your agent's session without any application-level state lookup — the threading is self-contained in the headers. Mails.ai surfaces both in_reply_to and references as top-level JSON fields, so no header parsing required.
Is inbound email parsing secure enough for sensitive workflows?
The parsing layer itself is passive — it receives and decodes. Security comes from three places: SPF/DKIM verification (confirm the sender domain is legitimate), webhook signature verification (confirm the webhook came from your provider, not an attacker), and your application's authorization logic (confirm the sender is allowed to trigger the action). Mails.ai verifies SPF/DKIM at ingestion and surfaces results as top-level fields, and signs all webhook deliveries with HMAC-SHA256.
Can I use inbound parsing without a custom domain?
All four providers require MX records on a domain you control. You can't use Gmail or a personal address as the inbound target — the MX record is the mechanism that routes mail to the provider's servers. Mails.ai provisions per-address routing under your domain, so agent+{session_id}@yourdomain.com routes correctly without a separate route rule per session.
How does classification work and when should I enable it?
Mails.ai's classification pipeline runs an intent detection model over the parsed message body before the webhook fires. It outputs a label (approval, rejection, question, unsubscribe, out_of_office, etc.) as a top-level field. Enable it when your agent needs to branch on human intent — approving a draft, rejecting a proposal, asking a follow-up question — and you want to skip the latency and cost of an inline LLM call per message. Skip it for pure logging, archival, or pass-through pipelines where you don't act on intent.
What's the fastest way to get started with Mails.ai inbound parsing?
Sign up at mails.ai, add your domain, configure the MX record (MX 10 inbound.mails.ai), and set your webhook endpoint in the dashboard. The first inbound message lands in under 5 minutes of DNS propagation. The @mailsai/sdk package (npm install @mailsai/sdk) includes typed webhook verification and event interfaces out of the box. The API reference covers address provisioning, webhook configuration, and event schemas.