Quickstart

This takes you from nothing to a sent message. Budget about five minutes, plus however long your DNS takes to propagate.

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.

You’ll need: an Org with Email enabled, a domain you control DNS for, and an active payment method on the Org — minting a send key requires one, the same gate as creating a cluster.

1. Register a domain

In the Console, open Email → Domains and add the domain you want to send from — example.com, or a subdomain like mail.example.com. Registering it returns a set of DNS records to publish.

2. Publish the DNS records

Add the Sending records at your DNS provider: three CNAMEs for DKIM and an MX plus TXT for the custom MAIL FROM host. The full walkthrough — where the records live, the two things that trip people up, and how verification works — is in Configuring DNS.

We re-read your DNS on a schedule and flip the domain to verified on its own; press Check now to run a check immediately. Wait for the domain’s Sending state to read verified before the next step.

3. Mint a send key

A send key is the credential your application sends with. Under Email → Send keys, create one and copy the secret:

lpk_a1b2c3d4.9f8e7d6c5b4a39281706f5e4d3c2b1a0

Important: The secret is shown once, at mint. Store it somewhere safe now — you can’t retrieve it later, only revoke the key and mint another. It’s also your SMTP password, so keep it wherever your app reads credentials from.

4. Send your first message

You have two front doors, and the same send key opens both.

Over the HTTPS API

POST to the send endpoint on your Org’s Email API host, with the send key as a bearer token:

curl https://api.email.lngbrdg.com/v1/email/send \
  -H "Authorization: Bearer lpk_a1b2c3d4.9f8e7d6c5b4a39281706f5e4d3c2b1a0" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "hello@example.com",
    "to": ["you@your-inbox.com"],
    "subject": "First message from Longbridge",
    "text": "It works."
  }'

A 202 Accepted with a message id means the message is durably enqueued — accepted for delivery, not yet delivered:

{ "id": "msg_7h3k9m2p" }

Over SMTP

Point any SMTP client at smtp.lngbrdg.com on port 587 (STARTTLS) or 465 (implicit TLS). The username is the key id (the lpk_… part before the dot); the password is the whole secret:

Host:      smtp.lngbrdg.com
Port:      587            # STARTTLS  (or 465 for implicit TLS)
Username:  lpk_a1b2c3d4
Password:  lpk_a1b2c3d4.9f8e7d6c5b4a39281706f5e4d3c2b1a0

The envelope recipients are the destinations; the header From must be an address at a send-verified domain. Both doors run the same pipeline — see Sending mail for the request body, the gates, and delivery events.

5. (Optional) Turn on receiving

To receive mail as well, arm receiving on a domain and publish its MX record.

Warning: Receiving is an exclusive MX takeover — it routes all inbound mail for that exact domain to Longbridge. If the domain already has mailboxes (Google Workspace, Microsoft 365), use a dedicated subdomain such as in.example.com instead. Receiving mail explains why and how.

Once the receiving MX verifies, add an inbound route — a local-part pattern (support, support-*, or * for catch-all) pointing at a webhook endpoint. Matching mail is delivered to that endpoint as an email.received event.

Where to next

• Sending mail — the API and SMTP in full, plus quotas and events.
• Receiving mail — inbound routes and the email.received event.
• Configuring DNS — the records behind verification.