How Startup Mail works

One address, several interfaces

A mailbox is the durable center of the system. Startup Mail stores its messages and thread state, then makes that same state available to people and software.

sender → your domain → Startup Mail mailbox
                           ├─ web inbox
                           ├─ verified forwarding address
                           ├─ REST API / TypeScript SDK
                           ├─ signed webhooks
                           └─ MCP tools

Forwarding is an extra delivery route, not a second source of truth. The Startup Mail mailbox still receives and stores the original message.

Incoming mail

Your MX record routes mail to Startup Mail’s receiving boundary. Startup Mail verifies the recipient, rejects or quarantines unsafe mail, parses accepted MIME, stores the raw message and attachments privately, adds the message to a thread, and then dispatches forwarding and webhook work.

Duplicate provider events do not create duplicate messages.

Outgoing mail

Mail can originate in the web composer, REST API, SDK, or MCP. Startup Mail validates mailbox access and sending policy, checks recipient and usage limits, writes the message and durable delivery job together, then hands it to the outbound provider.

Delivery feedback updates the message status. Hard bounces and complaints add the address to the workspace suppression list.

Threads and replies

Incoming replies are matched using standard email headers. When sending through the API or SDK, pass replyToMessageId to continue an existing conversation. A forwarded reply uses a signed, expiring relay address so it can return to the correct mailbox and thread without exposing a reusable route.

Identity and permission

Workspace roles govern configuration. Mailbox visibility governs message content. API key scopes govern operations. All three checks matter: an administrator can manage a private mailbox without automatically receiving permission to read it.