# LiteMX Existing Inbox

Connect a custom-domain address such as `support@project.dev` to a verified inbox you already use. LiteMX stores accepted incoming mail, forwards a copy to that destination, and gives the copy a signed reply address. Reply from Gmail, Fastmail, iCloud, Thunderbird, or your existing client; the correspondent sees `support@project.dev`, not the private destination.

Human-friendly guide: https://litemx.com/docs/existing-inbox

## Private-Build Availability

- The forwarding leg is deployed and has delivered a real public message to the founder's existing inbox.
- The first production text-only reverse-reply round trip passed through the founder's existing inbox and returned to the original correspondent without exposing the private destination.
- Exact founder destinations on the server allowlist can be verified automatically.
- Arbitrary destinations remain pending until LiteMX can deliver a one-time verification challenge.
- Do not move production mail during the private build without coordinating with LiteMX.

## Create An Address

```sh
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` composes domain registration, address creation, forwarding-destination creation, mailbox binding, provider provisioning, and DNS planning. Add the returned records at the DNS provider you already use.

## Verify And Inspect Forwarding

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

Forwarding is enabled only for a verified destination. A pending destination may be bound to the address, but it remains disabled.

After LiteMX delivers a genuine one-time challenge out of band:

```sh
litemx forwarding-destinations verify <destination-id> --token <one-time-token>
litemx mailboxes forwarding support@project.dev \
  --destination <destination-id> --enable
```

The API never returns raw destination-verification tokens or reverse-reply tokens.

## Reply Normally

The forwarded copy uses a signed, unguessable Reply-To capability bound to the account, custom-domain address, verified destination, correspondent, source message, and thread. A normal reply from the existing inbox returns through LiteMX and uses the ordinary outbound provider, plan limits, suppressions, delivery ledger, threading, and audit path.

Inspect the resulting conversation:

```sh
litemx messages list --mailbox support@project.dev
litemx threads list --mailbox support@project.dev
litemx audit list --mailbox support@project.dev
```

New conversations remain CLI-, API-, or MCP-first during the private build.

## Reverse-Reply Security

LiteMX rejects the reply unless all of these are true:

- It arrived through the authenticated AWS SES ingress path.
- SES reports a DMARC verdict of `PASS`.
- The sender exactly matches the verified destination bound to the address.
- The destination and mailbox binding are still enabled.
- The signed reply capability is valid, unexpired, unrevoked, and bound to the original thread.

Only the capability hash is stored. Disabling the binding or destination revokes related reply addresses.

## Current Limitations

- Arbitrary destination verification cannot complete until challenge delivery ships.
- Incoming attachment bytes are stored by LiteMX but omitted from the forwarded copy.
- Reverse replies containing attachments are rejected instead of relayed.
- Two additional founder-domain dogfood passes remain before the three-domain acceptance gate is complete.

Use text- or HTML-only messages for private-build testing.

## Disable Forwarding

```sh
litemx mailboxes forwarding support@project.dev --disable
litemx forwarding-destinations delete <destination-id>
```