Build inbound email yourself, or ship it this afternoon

The first version works, and quickly. Point an MX record at a cloud receiving service or an MTA you run, hand the message to a function, run it through a MIME library, write the result to a table. By Sunday evening you can send yourself an email and watch a row appear. It is a good feeling and it is not a false one — that really is the shape of the thing.

Nothing on this page disputes that estimate. What it disputes is that the estimate covers the project — because the demo and the pipeline differ by everything that happens once the message is not the one you sent yourself from your own laptop, and every item of that difference is already built here.

These arrive in roughly this order, and none of them is exotic — every one is a thing real senders do:

• MIME from real clients. A message whose HTML part is nested two multiparts deep. A charset header that lies. Encoded words in a subject line. An inline signature image that arrives looking exactly like an attachment. Each is a small fix; together they are the long tail that makes people say parsing email is harder than it looks.
• The 25 MB attachment, on the day your function has a 6 MB request limit. Now attachments need somewhere to live before your handler runs, a key convention, signed URLs to hand out, and a lifecycle rule so storage does not grow forever.
• Your handler was down. Without a queue and somewhere to hold the message, that mail is gone — and unlike a failed API call, the sender believes it was delivered. This is the single most common reason a homegrown pipeline gets rebuilt.
• Duplicates. Retries mean the same message can arrive twice, so every consumer needs an idempotency key and the discipline to use it.
• Spam, and then more spam. A published address is scraped within weeks. Verdicts have to be read, thresholds chosen, and a policy written for the messages that soft-fail — which will include mail from a real customer using a misconfigured corporate relay.
• Replies. The moment you answer a message you need a sending path, a verified domain, threading headers, and somewhere for bounces and complaints to go. That is usually where a second vendor enters the diagram.
• Operations.Someone has to answer “did we get their email?” at 4pm on a Friday, which means logs, a way to look a message up, and enough retention to answer about last week rather than the last hour.

Every partlyin the right-hand column means “yes, once you build and maintain it”. That is a real answer, not a no — the question is only whether this is the list you want on your roadmap.

The cloud bill for receiving mail is small — that is not where this comparison lives. The cost is engineering time, and it has two parts: the build, and the tail.

• The build. Parser hardening, attachment storage, queue and retries, idempotency, spam policy, threading, sending and bounces, plus the console or queries someone uses to answer questions about a message. Estimate it in weeks rather than days and you will be closer.
• The tail. Mail does not stop changing. Providers tighten authentication requirements, clients invent new ways to encode a body, a bucket policy expires, a queue backs up on a bank holiday. This is the part that never appears in the original estimate and never goes away.

Set that against a per-message price and the answer is usually obvious: unless you are at very high volume with trivial handling, building spends the one resource that is actually scarce. The tie-breaker is simple — is receiving email something your team wants to be good at, or something that has to work while they build the product?

Plenty of readers should, so here is the short list of things that most often get missed. It is worth having whether or not you ever use this product:

1. 1Persist the raw message before you parse it. Every recoverable mistake downstream depends on still having the original.
2. 2Make consumers idempotent from day one, keyed on a delivery id rather than the message id — senders reuse those more than you would like.
3. 3Get attachments out of the request path immediately, with a size limit at the edge and a lifecycle policy on the bucket.
4. 4Decide the spam policy explicitly, including what happens on a soft fail, and log the verdict with the message so a false positive can be explained later.
5. 5Store Message-ID, In-Reply-To and References on the way in, even before you support threading. Reconstructing threads later without them is not possible.
6. 6Build the “did we receive this?” lookup early. It is the tool your support team will use daily and the one nobody schedules.

For comparison, the same message handed over as data looks like this, and the three headers alongside it — x-inboundr-event, x-inboundr-delivery-id and x-inboundr-signature — are the second and third items on that list, done for you:

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