Configuring DNS

Longbridge sends and receives mail on domains you own. To prove you own a domain — and to let mailbox providers trust mail that comes from it — you publish a handful of DNS records that we generate for you.

You add each record once, at whatever DNS provider hosts your domain. We check for them automatically and light the domain up the moment they resolve.

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.

Where to find your records

In the Console, open Email → Domains, then select your domain. The DNS configuration panel lists every record to publish, grouped into Sending and Receiving. Each row gives you three things:

• Type — CNAME, MX, or TXT.
• Name — the host the record lives at (sometimes called host or record name by your provider).
• Value — what the record points to.

Copy each value with the button beside it. Nothing here is secret — DNS records are public by nature — so it’s safe to paste them anywhere.

Adding a record at your provider

The exact screens differ by provider, but the shape is always the same: choose the record type, paste the name, paste the value, and save.

Two things trip people up more than anything else:

Your provider probably appends the domain for you. Most control panels already know the domain, so they add it to whatever you type in the name field. If your record’s name is abc._domainkey.mail.example.com and your provider shows .example.com next to the input, enter only abc._domainkey.mail — otherwise you’ll end up with a doubled …mail.example.com.example.com. When in doubt, add the record and read it back: the full name should match ours exactly.

Don’t proxy or flatten the CNAMEs. If your provider offers a proxy, CDN, or “flatten CNAME” toggle (Cloudflare’s orange cloud is the common one), leave it off for these records. They must resolve to our values directly.

Sending records

Sending needs two things proven: that mail signed as your domain really came from you (DKIM), and that the address mail bounces to belongs to you (a custom MAIL FROM).

Record	What it is	Why it’s there
Three CNAMEs at …._domainkey.<domain>	DKIM signing keys	Let providers verify our signature on your mail, so it lands in inboxes instead of spam.
One MX at send.<domain>	The custom MAIL FROM host	Aligns the bounce address with your domain (SPF alignment) for a cleaner reputation.
One TXT at send.<domain>	An SPF record	Authorizes our infrastructure to send for that MAIL FROM host.

The values point at amazonses.com hosts — Amazon SES is the infrastructure we send through. That’s expected; you’re authorizing our sending, not handing over your domain.

Once all of these resolve, the domain’s Sending state flips to verified and you can send from any address at the domain.

Receiving records

Receiving is opt-in, per domain. When you arm it in the Console, we add one more record:

Record	What it is
One MX at <domain>	Routes inbound mail to the platform, where it’s matched against your Routes and forwarded to your webhooks.

Receiving takes over all inbound mail for that exact domain. An MX record decides where every message for a domain goes. If example.com already has mailboxes — Google Workspace, Microsoft 365, anything — pointing its MX at us stops those mailboxes from receiving. 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.

Verification

You don’t need to tell us when you’re done. A background check re-reads your DNS on a schedule; when the records resolve, the domain verifies on its own. You can press Check now on the domain page to run a check immediately instead of waiting for the next one.

State	Meaning
Pending	We haven’t seen all the records yet. Newly published DNS can take anywhere from a minute to an hour to propagate.
Verified	Everything resolves. The capability is live.
Failed	A record that was present has gone missing, or never resolved. Re-check the values against the Console and press Check now.

Sending and receiving verify independently — a domain can be sending-verified while receiving is still pending, and vice versa.

Troubleshooting

Symptom	Likely cause
Stuck on pending for more than an hour	The record name is doubled (the provider appended the domain) or a CNAME is proxied/flattened. Read the records back and compare to the Console.
DKIM won’t verify	One of the three CNAMEs is missing or altered. All three must be present and exact.
Sending verified, but mail still lands in spam	DKIM alignment is only part of reputation. Warm up gradually and keep bounce and complaint rates low; both are visible on the Sending page.
An existing SPF record for the domain	Our SPF lives on the send.<domain> MAIL FROM host, not the root, so it won’t collide with a root-domain SPF you already run.

If a record looks correct and still won’t verify after an hour, get in touch — we can see what our checks resolve from our side.