Email

Email is the channel most workspaces connect first. Go to Channels, then Email.

There are two halves, and they are independent. Getting mail in needs nothing but forwarding. Getting replies out needs either a connected Google mailbox or a verified sending domain.

Getting mail in

1. Get your inbound address

Connecting the email channel mints one address for the workspace. Customers, or your own forwarding rule, write to it, and anything that arrives opens a ticket here.

The local part is a random token rather than anything derived from your workspace name. The address is public, and a guessable one would be an open write path into your ticket queue.

Minting is idempotent. Pressing Connect twice is a second click, not a request for a second address.

2. Forward your support mailbox to it

The page walks you through it: pick where your mail lives and follow the numbered steps for that provider. This is the only step left, because the address is live the moment it is minted.

3. Watch the first message arrive

The page shows how many tickets have arrived on email and the most recent one, so you can confirm the forwarding rule works rather than assuming it.

Rotating the address

Rotate revokes the current address and issues a new one. Rotating is admin only, and it is not reversible.

The old address stops routing immediately. Mail sent to it afterwards creates nothing and is recorded in the delivery ledger as having hit an inactive address. Existing tickets keep their history. What breaks is any customer thread whose stored reply-to is the old address, which is the price of revoking it.

Getting replies out

The page tells you, before you send anything, what a reply would go out as right now. There are three possible answers: an address, an address with a note saying it is not your own domain and why, or a refusal with its reason.

That question is answered up front so you find out here rather than on your first customer.

Option A: connect a Google mailbox

Connect starts the Google consent flow. You are sent to Google, you choose the account, and you come back connected. The address that gets connected is read back from Google, never from anything the product sent.

Each attempt is single use, bound to your workspace and expiring on its own, so abandoning one costs nothing. Starting again is free.

Once connected, the panel shows the mailbox and its per-check health. Refresh asks Google what it currently allows and writes the answer down, which is what you want immediately after fixing something on the Google side rather than waiting for the next scheduled check.

Disconnect removes the connection. Connecting, refreshing and disconnecting are all admin only.

A connected mailbox is also polled for new mail, so a workspace on this path does not need a forwarding rule.

Option B: connect your own sending domain

Connect a domain and the response is the DNS record set to publish: host, type, value, TTL, and which check each row satisfies. Nothing is verified at that point, and the page says so.

Publish the records. The domain becomes sendable on its own once the provider sees them, or you can press Verify to ask now.

Three things worth knowing:

A domain can be connected by one workspace at a time. If it is already taken you are told that, and nothing more, because naming the workspace holding it would turn this into a way to ask who else uses this helpdesk.
Verification is a provider check on published DNS. Nothing in the product can make it pass.
Disconnecting the domain is admin only.

What sending looks like on a ticket

A reply on an email ticket goes out threaded onto the message it answers. Delivery happens after your reply is safely stored, never inside the same write, and the delivery outcome is recorded against the reply on the timeline. A reply that could not be delivered is still your reply, and the ticket says what happened to it.

See Replying.

Inbound mail with no text

Bounces, read receipts and attachment-only messages all arrive as legitimate deliveries and none of them breaks the channel.