The inbound-first alternative to Resend

Resend is a sending product. It became popular because sending through it is pleasant, and receiving arrived later as an addition to that platform — mail is stored on arrival, an API reads it back, and webhooks are signed and retried. If your problem is outbound with a few replies coming home, that addition is probably enough.

Inbound is not an addition here. It is the entire product, and that shows up in the object model: domains hold addresses, addresses point at endpoints, endpoints have retry policies, messages belong to threads, and rules run before any of it. When receiving is the feature you are buying, buying it from a product organised around receiving is not a small difference.

Three differences, and they are all architectural rather than featural:

• Routing is configured here and coded there. An address in this product points at endpoints, and an address can have several — post to your app and forward to a person, from the same message. With Resend the receiving domain has one webhook and your handler is the router: the branch on to, the fan-out, the forwarding, all in code you own and deploy.
• Filtering happens before delivery or in your handler. Rules that drop mail on sender, recipient, subject or spam verdict mean the junk never becomes an invocation. Without them, every scraped-address blast is a call to your endpoint that you pay for and then discard.
• The webhook is one round trip or two. Their event is deliberately metadata-only so a large attachment cannot exceed a serverless request limit — a defensible choice. The cost is that the simplest possible handler still makes an API call before it can read the sentence someone wrote.

The rows that matter are the ones you would otherwise write code for: routing, filtering, and getting the message in one request instead of two.

The difference is easiest to see in the handler you end up writing. With a metadata-only event, the shape is fetch-then-act:

export async function POST(req: Request) {
  const event = await verify(req);            // signature check
  const id = event.data.email_id;

  // The body is not here yet.
  const mail = await api.received.get(id);    // second call
  const text = mail.text;

  await handle(text);
}

And with the body already in the payload:

{
  "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"
  }
}

Attachments stay out of the request body in both products — sooner or later someone sends a 20 MB PDF — but the body of the message is the thing your handler always needs, and here it is already there. One round trip, one failure mode, one thing to retry.

Multiply that by every message and every cold start: a second API call in the hot path of an inbound webhook is latency you pay on every single email, forever, to read text that had already been parsed before the event was sent.

No price table here, deliberately: both products change their pricing and a stale number is worse than none. Check theirs at the source and ours here. What is worth comparing is the shape of the meter.

• Resend is anchored on sending volume, because that is what the platform is for. Receiving is measured against a meter built for outbound.
• Inboundr is anchored on messages received, with an allowance and opt-in pay-as-you-go past it — the axis your bill should be on when inbound is the workload.

And a cost that never appears on either pricing page: mail you did not want. Filtering before delivery keeps a spam blast off your compute bill as well as out of your database. Every message dropped by a rule is an invocation you never ran, a row you never wrote and a payload your agent never had to read.

Both sides are two DNS records, so the cutover is short and reversible if you order it correctly:

1. 1Add the domain or subdomain in the Inboundr console and copy the MX and DKIM records it shows you. Change nothing in DNS yet.
2. 2Create the addresses and endpoints that will replace the branching in your current handler. If your handler dispatches on to today, each branch is usually one address pointed at one endpoint.
3. 3Publish the DKIM record and wait for verification. This does not affect delivery, so it is safe to do while Resend is still receiving.
4. 4Replace the MX record. Use a low TTL an hour beforehand so resolvers pick the change up in minutes rather than hours.
5. 5Send a test message with an attachment and a reply in a thread. Those are the two paths where an assumption from the old handler usually survives the move.
6. 6Leave the old webhook deployed for a few days. It costs nothing idle, and it is your rollback if something in the payload shape surprises you.