Guides / Inbound email
Four services will accept email for your domain and call your webhook. They differ in one dimension that matters more than any pricing table: how much of the message they digest before it reaches you, and how much is still your problem.
| Service | Your endpoint receives | MIME parsing | Webhook authentication |
|---|---|---|---|
| AWS SES | Raw MIME (usually via S3 + Lambda/SNS) | None, you parse | Standard AWS auth (IAM, SNS signatures) |
| Mailgun Routes | Form fields (subject, body-plain, stripped-text…) | Yes | HMAC signature on each POST |
| SendGrid Inbound Parse | Multipart form fields, optional raw MIME | Yes (basic) | None built in, secure the URL yourself |
| Postmark Inbound | One clean JSON object | Yes, the most complete | Basic auth / restrict by IP |
SES receiving is rule-based: mail for your domain matches a receipt rule, and the rule delivers the raw message to S3, invokes a Lambda, or publishes to SNS. What lands is the complete, unparsed MIME document. SES attaches spam and virus verdicts plus SPF/DKIM results, which is genuinely useful, but the message itself is yours to decode: multipart trees, base64 bodies, encoded headers, attachments.
Choose SES when you are already deep in AWS, want the lowest per-message cost at volume, and are comfortable owning a parsing layer (in practice: a Lambda wrapping a MIME library, plus the maintenance that follows). Note that inbound is supported in fewer regions than outbound, so check yours first.
Mailgun’s inbound story is routes: expressions matched against the recipient (match_recipient, catch-all patterns), with actions like forwarding to a URL. The POST your server gets is already parsed: subject, sender, body-plain, body-html, and the handy stripped-text (the message minus quoted replies and signatures). Each POST carries an HMAC signature you verify with your signing key.
Choose Mailgun when you want flexible recipient routing (many addresses, one domain, different endpoints) and are fine with form-encoded payloads. The parsing is solid; the data is still email-shaped, not application-shaped.
Point MX records at mx.sendgrid.net, register a hostname and URL, and SendGrid POSTs each message as a multipart form: headers, text, HTML, attachments, plus SPF results and a spam score. A checkbox switches to raw MIME delivery if you would rather parse yourself.
The sharp edge: inbound parse POSTs are not signed. The standard mitigations are an unguessable URL, basic auth embedded in it, or an allowlist, all of which are on you. It works, it has worked for a decade, but the DX shows its age.
Postmark gives you an inbound address (and optionally your own domain) and delivers each message to your webhook as a single JSON document: sender, recipients, subject, TextBody, HtmlBody, headers, and attachments as base64. Of the four, it is the one where you can go from zero to a working handler in an afternoon without reading a MIME RFC.
Choose Postmark when developer experience matters more than squeezing cost at volume and you want JSON rather than form fields.
All four stop at the same line: they hand you the email. If your application needs the data inside it, the vendor invoice total, the listing price, the deal in a newsletter, you are writing the extraction layer yourself: regex against text bodies, DOM scraping against HTML, and a quiet breakage every time a sender redesigns their template. That layer is where inbound email projects actually rot.
Full disclosure: that layer is the product we build. Inbin sits where your webhook handler would: you declare a schema (the fields you want), point any of your email at an inbox address, and receive typed JSON with a guard that drops any value the extractor cannot find literally in the source email. If you already run SES or Mailgun happily and your parsing is stable, you do not need it. If you are about to write the third regex for the same newsletter, you might.
Mechanics above reflect each provider’s documented behavior at the time of writing; pricing changes often enough that we deliberately left it out. Corrections welcome: hello@inbin.dev.