Receiving mail

Longbridge Email can receive inbound mail on a domain and deliver each message to a webhook you control, parsed and ready to handle. It’s how you build a support inbox, a reply-to-thread flow, or a parse-the-attachment pipeline without running an IMAP server.

Receiving is opt-in, per domain, and independent of sending — a domain can send long before (or without) receiving, and vice versa.

Early access. Email is being rolled out behind an Org flag. If you don’t see it in the Console, it isn’t enabled for your organization yet.

Arm receiving

In the Console, open the domain under Email → Domains and choose Turn on receiving. This arms receiving and returns one more DNS record — an MX at the domain — for you to publish. Once it verifies, inbound mail starts flowing.

Danger: Receiving is an exclusive MX takeover. An MX record decides where every message for a domain goes, so pointing example.com’s MX at Longbridge stops any existing mailboxes on that domain — Google Workspace, Microsoft 365, anything — from receiving mail. This cannot be undone by us; you recover by restoring your old MX.

Use a dedicated subdomain such as in.example.com unless the domain handles no mailbox mail at all. Sending is unaffected either way: you still send from example.com while receiving at in.example.com.

Because sending and receiving verify independently, the documented happy path is to send-verify your root domain and receive-verify a subdomain — two Domains, one for each capability. See Configuring DNS for the receiving record and how verification works.

Route inbound mail

An armed domain doesn’t deliver anything until you add an inbound route. A route says: mail arriving at addresses matching this pattern on this domain goes to that webhook endpoint. Add routes under the domain, or with lbr email route create.

The pattern matches the local part — the piece before the @ — in one of three shapes:

Pattern	Matches	Example
Exact	Only that address	support matches support@in.example.com
Trailing star	A prefix	support-* matches support-billing@…, support-eu@…
Catch-all	Every address on the domain	* matches anything

When more than one route could match, the most specific wins: an exact match beats the longest matching prefix, which beats the catch-all. So you can send support@ to one endpoint and let a * catch-all mop up everything else.

A route can only target a webhook endpoint your Org owns, and the domain must be receive-armed first.

Receive the email.received event

Matched mail is delivered to the route’s webhook endpoint as an email.received event — the same signed, retried webhook mechanism that carries delivery events, so one endpoint can handle both. The payload is a parsed digest of the message:

{
  "type": "email.received",
  "messageId": "msg_5k2n8p1q",
  "domain": "in.example.com",
  "route": { "id": "rte_3f7h", "pattern": "support" },
  "recipients": ["support@in.example.com"],
  "mail": {
    "from": { "name": "Dana Lee", "address": "dana@customer.com" },
    "to": [{ "address": "support@in.example.com" }],
    "subject": "Can't log in",
    "date": "2026-07-06T09:14:22Z",
    "rfc822MessageId": "<CAF...@mail.customer.com>",
    "text": "Hi — I'm locked out of my account.",
    "html": "<p>Hi — I'm locked out of my account.</p>",
    "attachments": []
  },
  "content": {
    "url": "https://api.email.lngbrdg.com/v1/email/messages/msg_5k2n8p1q/content",
    "expiresAt": "2026-08-05T09:14:22Z"
  }
}

A few things worth knowing:

• The body is inlined up to a limit. Long text or html is truncated in the payload (flagged with textTruncated / htmlTruncated); fetch the full raw message from content.url when you need all of it.
• Attachments are described, not inlined. Each entry carries filename, contentType, and sizeBytes — the bytes live in the raw message, retrievable from content.url until expiresAt (the 30-day content window).
• Parsing is tolerant. Real-world inbound mail is messy; a message that won’t parse cleanly still arrives, with a thinner digest. The raw bytes are always stored.

Handle the event by verifying its signature and reading the fields you need — see Webhooks for verification, retries, and manual redelivery.

Where to next

• Webhooks — verify signatures, handle retries, redeliver.
• Configuring DNS — the receiving MX record and verification.
• Sending mail — the other half of a domain.