Skip to content

Introduction

What Longbridge Email is — send transactional mail from your own domains and receive inbound mail to a webhook, both on one verified domain — who it's for, and where it is today.

Longbridge Email sends transactional mail from domains you own and receives inbound mail on them, delivered straight to a webhook you control. It’s one Product with two capabilities, built for the developer who wants their application’s mail — sign-in links, receipts, alerts, replies — on their own domain without running a mail server.

You send over an HTTPS API or plain SMTP, you receive as an HTTP callback, and everything flows through mail infrastructure we operate and keep in good standing.

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.

The one asset, two capabilities

Everything hangs off a single Domain — a DNS name you own, verified by publishing records we generate. A Domain carries two independent capabilities, and you turn on whichever you need:

  • Sending — transactional mail from an address at the domain, over an API or SMTP. Verified by DKIM and a custom MAIL FROM record. This is additive: it sits alongside whatever mail the domain already handles.
  • Receiving — inbound mail to the domain, matched against your routes and forwarded to a webhook. Verified by pointing the domain’s MX at us. This is exclusive: it takes over all inbound mail for that exact name.

The two verify separately, so a domain can be sending long before (or without) receiving. Because receiving takes over inbound mail, the common shape is to send from your root domain and receive on a dedicated subdomain — more on that in Receiving.

Who it’s for

  • Application developers who need reliable transactional mail from their own domain — verification emails, password resets, invoices, notifications — without standing up Postfix or wiring a mailbox provider’s API.
  • Teams building on inbound mail — support inboxes, reply-to-comment, parse-an- attachment flows — who want each message as a signed HTTP event instead of an IMAP poller.

It is transactional email: application-generated mail to people who expect it. Marketing and broadcast sending are out of scope.

What you get

  • Send from any address at a verified domain, over an HTTPS API and SMTP — one credential, two front doors.
  • Receive to a webhook — inbound mail parsed and delivered as an email.received event, routed by address pattern.
  • One webhook system carrying both delivery events and inbound mail, HMAC- signed with retries and manual redelivery.
  • Per-Org suppression built from bounces and complaints, so a bad address is refused rather than mailed again.
  • EU-native handling — mail is processed in Ireland and rests in the EU.

Where to next

  • New here? The Quickstart takes you from a domain to a first sent message in about five minutes.
  • Setting up a domain? Start with Configuring DNS.
  • Want the sending model first? Read Sending mail.