Receiving customer email

Forward your support mailbox to a per-channel address, or let Leodesk poll it over IMAP. Both produce the same tickets — here is how to pick.

Leodesk gives every email channel a unique forwarding address. Mail that reaches that address becomes a ticket, replies thread back onto the same ticket, and the sender becomes a contact. There are two ways to get your customers' mail there: a forwarding rule in the mailbox you already use, or IMAP polling, where Leodesk logs into the mailbox and pulls.

Option A — forward to your channel address (recommended)

Open Settings → Email → Receive customer email. Each channel shows its own forwarding address, unique to that mailbox and workspace:

[email protected]  →  [email protected]

Copy it and create a forwarding rule inside the mailbox you already run — Gmail, Google Workspace, Microsoft 365, or anything else with a forwarding setting. You do not touch your domain's MX records. Your mailbox keeps receiving mail exactly as it does today and simply passes a copy along.

Because the address is per mailbox rather than per workspace, Leodesk knows which channel a message arrived on without guessing from the To header. That is what lets several support addresses — support@, billing@, partners@ — land in the right place with the right branding and the right team. The Free plan allows one mailbox; paid plans are unlimited.

Option B — poll the mailbox over IMAP

Open Settings → Email, pick the channel, and fill in the IMAP section: host, port, username, password and the folder to watch (INBOX by default). Most providers require an app-specific password rather than the account password, and most want port 993 with SSL/TLS.

Leodesk then polls on a fixed interval — once a minute by default — fetching unread messages, up to a bounded batch per run so a large backlog cannot swamp a single tick. Parsing is identical to the forwarding path: the same threading, the same contact creation, the same attachment handling. The message's HTML part is preserved and sanitised, so pasted tables and styled text render the way the customer sent them rather than collapsing into flat lines.

When a poll fails, the channel records a plain-English reason rather than an opaque code — "Authentication failed — check the username and password (app password may be required)", "Host not found — check the IMAP hostname", "TLS mismatch — try toggling SSL/TLS, or use port 993". Check the channel in Settings before digging through anything else.

Which should you choose?

Forwarding is the default recommendation. It is faster, since mail arrives when it is sent rather than at the next poll; it stores no mailbox credentials in Leodesk; and there is nothing to break when a password changes or a provider tightens its app-password policy.

IMAP is the right choice when you genuinely cannot create a forwarding rule — a locked-down IT policy, a shared mailbox that will not forward, or a provider that mangles forwarded mail. It is also the only path that supports pulling in your existing email history, so if you are migrating from another inbox you will configure IMAP at least once even if you forward day to day.

Running both against the same mailbox is fine. Messages are deduplicated by Message-Id, so a message that arrives twice does not create two tickets.

How replies find their ticket

Threading is attempted in order, so an unusual mail client cannot orphan a conversation:

1. Subject marker

   Outbound replies carry a marker like [INC-4821]. If a reply's subject still has it, that decides the ticket immediately. You can set your own prefix under Settings → Email → Advanced.

2. Header chain

   Failing that, the message's Message-Id and In-Reply-To headers are matched against the messages already stored on tickets.

3. Subject and participants

   As a last resort a same-subject match is accepted, but only when the new message shares a participant with the candidate ticket. Leodesk stores the original To and Cc addresses as participants, so a reply from a colleague who was copied in lands on the right ticket — while an unrelated message that happens to share a subject line starts a fresh one.

Settings worth checking on day one

• Reply-To for requester contacts. Shopify, marketplaces and many notification systems send as no-reply@… with the real human in Reply-To. With this on — it is on by default — the contact is built from the Reply-To address, so your reply reaches the person rather than a black hole. Found under Settings → Email → Advanced.
• Default assignee per mailbox. Set one if a mailbox always belongs to a named person. Leave it unassigned to let team routing or round-robin handle it instead.
• Inbound blocklist. Add an address or a domain and matching mail is dropped before a ticket is created. A domain entry also covers its subdomains — useful for a noisy monitoring vendor.
• Team on the channel. Tickets from a mailbox inherit its team, which is what scopes round-robin assignment to the right group.

Verify it works

Send an email from a personal account to your real support address. Within a moment — or at the next poll, on IMAP — a ticket should appear with the correct requester, the correct channel and the body rendered properly. Then reply to that email from the personal account and confirm it appends to the same ticket instead of opening a second one. That is the threading check that actually matters, and it is the one most setups get wrong.

Once mail is flowing in and out under your own domain, the remaining migration step is bringing across what is already sitting in the old mailbox.