The SendGrid Inbound Parse alternative that keeps your mail

You point a subdomain’s MX record at SendGrid, tell the parse setting which URL to call, and every message that arrives is broken up and POSTed to you as a form: from, to, subject, text, html, the full header block, the envelope, SPF and DKIM results, a count of attachments and a JSON blob describing them, with the files themselves as parts of the same multipart request. There is a switch to receive the raw MIME message instead, in a single field.

It works, and for a long time it was the only way to get mail into an application without running an MTA. It also dates from that era, and one sentence in its design decides everything else about it: the POST is the whole product.

Nothing behind the webhook keeps the message. That single fact is responsible for most of the difference between the two columns in the table below, and it shows up in ordinary operational life:

• A deploy goes out at the wrong moment. Your endpoint returns 502 for ninety seconds. Whatever arrived in that window is not queryable afterwards, because there is no inbound store to query.
• A handler that returns 200 too early. The classic shape — acknowledge, then process, then throw. The provider considers the message delivered, and it was, and it is gone.
• A parsing bug you notice on Thursday. With storage behind the webhook you re-fetch the week and replay. Without it, the fix only applies to mail that has not arrived yet.
• Anyone who knows your URL can post to it. Without a signature over the body, the endpoint’s only defence is the secrecy of its address, and URLs leak into logs, proxies and error trackers.

Read the SendGrid Inbound Parsecolumn as “what arrives, and what remains afterwards”. Where it says partly, the capability is there but sits in the request rather than in a service you can call back.

Concretely, the parse handler starts by reconstructing a message from form fields:

export async function POST(req: Request) {
  // No signature to verify: the URL's secrecy is the auth.
  const form = await req.formData();

  const text = form.get("text");
  const info = JSON.parse(form.get("attachment-info") ?? "{}");

  // The files are parts of this same request. If you want them
  // after this function returns, you store them now — yourself.
  for (const key of Object.keys(info)) {
    await bucket.put(info[key].filename, form.get(key));
  }

  await handle(text);   // if this throws, the message is gone
}

And the same message delivered as data that outlives the request:

{
  "event": "email.received",
  "email": {
    "id": "em_2f9c1a4b7d3e5601",
    "threadId": "thr_8b21c0f4a95d",
    "from": "customer@example.com",
    "to": ["support@yourdomain.com"],
    "subject": "Invoice 4021 looks wrong",
    "text": "Hi — line 3 is billed twice…",
    "attachments": [
      { "filename": "invoice-4021.pdf",
        "contentType": "application/pdf",
        "size": 84213 }
    ],
    "verdicts": { "spam": "PASS", "spf": "PASS", "dkim": "PASS" },
    "receivedAt": "2026-07-30T09:14:22.104Z"
  }
}

Three headers come with it: x-inboundr-event, x-inboundr-delivery-id for idempotency, and x-inboundr-signature, an HMAC over the body and a timestamp. A failed delivery is retried with backoff, and the message stays fetchable over REST — or over MCP, if the reader is an agent — for its retention window.

No prices here on purpose: they change, and a stale figure is worse than none. Check theirs at the source and ours here.

• SendGrid meters sending. Inbound Parse rides along with the plan, so if you are already a sending customer the sticker price of receiving is zero — and the real price is the pipeline described above, paid in engineering rather than invoice.
• Inboundr meters messages received, with an allowance and overage past it, and the storage, retries, attachment handling and filtering are what the meter is for.

The comparison tips on one question: how much would it cost you to lose an hour of inbound mail, or to be unable to replay a week after fixing a bug? If the answer is “not much”, parse is cheaper and that is the end of it.

The cutover is one MX record, and it can be staged so that nothing is dark in between:

1. 1Add the same subdomain in the Inboundr console — the one whose MX record currently points at them — and copy the MX and DKIM records shown.
2. 2Publish the DKIM record. It does not affect delivery, so this is safe while parse is still live.
3. 3Point your existing handler at the new payload, or write a small adapter: form fields become JSON, and attachment-info becomes a list of descriptors with links to fetch.
4. 4Add the signature check. This is new — with parse there was nothing to verify — and it is the step people skip, so do it before the endpoint is live rather than after.
5. 5Swap the MX record, having lowered its TTL an hour beforehand. Mail in flight follows the old record until resolvers catch up, and lands at your old handler, which should stay deployed.
6. 6Send a test with an attachment, then deliberately return a 500 from your endpoint and watch the delivery retry in the console. That is the behaviour you moved for; confirm it.