Connect A Domain To Your Inbox

Create The Address

litemx addresses create support@project.dev --forward-to owner@example.com
litemx domains dns-plan project.dev
litemx domains verify project.dev --timeout 120 --interval 5

addresses create is the normal setup path. It registers the domain, creates the address and forwarding destination, binds them together, provisions the mail providers, and returns the DNS plan. Add the returned records at the DNS provider you already use, then run domains verify.

domains dns-plan prints the provider-agnostic records LiteMX needs: inbound MX, ownership verification, DKIM CNAMEs, SPF, DMARC guidance, and bounce/MAIL FROM records. You do not need to move nameservers or change web hosting.

Verify The Existing Inbox

LiteMX forwards mail only to a verified destination. Check the destination and address binding after setup; a pending destination remains disabled until its one-time verification challenge is submitted.

litemx forwarding-destinations list
litemx mailboxes forwarding support@project.dev

# after a one-time verification challenge arrives
litemx forwarding-destinations verify <destination-id> --token <one-time-token>
litemx mailboxes forwarding support@project.dev --destination <destination-id> --enable

The current private build can auto-verify only exact founder addresses configured on the server. Delivery of verification challenges through Clerk and Resend is not implemented yet, so arbitrary destinations cannot complete this step through self-serve setup. The CLI verification command is ready for the out-of-band token flow once challenge delivery is available.

Receive And Reply

After the domain is ready and forwarding is enabled, mail sent to support@project.dev arrives in the verified inbox. Reply normally from Gmail, Thunderbird, Fastmail, or the client you already use. LiteMX accepts the reply through a signed, expiring reply address and sends it to the original correspondent assupport@project.dev.

Current limitation: forwarded copies omit attachment files, although LiteMX stores the inbound attachment metadata and content. Reverse replies with attachments are rejected. One production text-only round trip has passed; two more founder-domain dogfood passes and attachment support remain before the full acceptance gate.

Domain Readiness

domains verify checks the public DNS records and provider evidence, then updates LiteMX domain readiness. It verifies inbound receiving and outbound sending separately, so a domain may be ready to receive before it is ready to send.

Do not redirect production MX records until the selected inbound route is active. Real sending also requires an active outbound provider, verified sender domain, DKIM, and the appropriate LiteMX send permissions.

Provider Direction

• AWS SES Email Receiving is the proven inbound path.
• MailChannels Email API is the primary and paid-launch outbound route.
• Mailgun is the wired and live-tested hot standby; switching requires an operator configuration change.
• AWS SES outbound is an implemented secondary adapter, but production access is denied and it is not a launch dependency.
• Cloudflare Workers, D1, R2, Durable Objects, Queues, and Cron Triggers provide runtime and storage.

LiteMX uses provider adapters so the domain workflow stays the same. It does not automatically route or fail over between outbound providers.

Advanced Domain Setup

Use domains register only when you need to configure the domain, mailbox, alias, and catchall primitives separately. This lower-level, DNS-plan-first path is useful for operators and custom automation; most users should start with addresses create.

litemx domains register project.dev --mailbox ops --alias hello --display-name Ops --plan
litemx domains register project.dev --mailbox ops --alias hello --display-name Ops
litemx domains dns-plan project.dev
litemx domains verify project.dev

Optional Vercel DNS Publishing

export VERCEL_API_TOKEN=<vercel-token>
litemx domains dns-plan project.dev --publish --confirm-publish --dns-provider vercel
litemx domains dns-plan project.dev --publish --confirm-publish --dns-provider vercel --include-inbound-mx

The Vercel publisher checks existing records, skips exact matches, refuses conflicting same-name/type records, and supports CNAME, MX, and TXT. It skips the root inbound MX by default so live mail is not redirected before the inbound bridge is ready.

Use --include-inbound-mx only after the inbound provider is ready to accept production mail for that domain. For every other DNS host, copy the records from domains dns-plan into its normal DNS editor.

Optional Cloudflare Commands

litemx domains cloudflare-account
litemx domains cloudflare-zone project.dev --cloudflare-account-id <account-id> --run --confirm-create-zone --record
litemx domains cloudflare-setup project.dev --run

These are provider-specific debug and prototype commands, not the default product path. Use them only when testing the legacy Cloudflare provider path or when a domain already uses Cloudflare DNS and that path is intentionally selected.

Smoke Test

litemx domains smoke project.dev --mailbox <mailbox-local-or-address> --inbound-query "unique subject" --to founder@example.com --timeout 120 --interval 5
litemx domains smoke project.dev --mailbox <mailbox-local-or-address> --self-send --self-to <alias-local-or-address> --to founder@example.com --timeout 120 --interval 5

A release smoke test should prove provider-ingested receiving and provider-accepted sending. Simulated inbound is for regression checks, not evidence that a public domain is ready.