Tickets by Email, Done Right

"Just email us" is still the support channel most customers reach for first, no matter how good your portal is. Getting that right — cleanly, reliably, at your own domain — is one of the least glamorous and most load-bearing pieces of a service desk.

Setting up your own domain

Plenix's mailhub module polls a real mailbox over IMAP and turns incoming messages into tickets automatically. To run this on your own domain instead of a generic shared address:

1. Go to Settings → Mailboxes and add a new mailbox.
2. Enter your own support address — support@yourcompany.com, not a Plenix-branded fallback.
3. Provide the IMAP credentials for that mailbox (most providers, including standard hosted email like IONOS or Google Workspace, support IMAP with an app-specific password).
4. Save — Plenix starts polling immediately, and every new message in that inbox becomes a ticket, with the sender attached as the requester.

You can run more than one mailbox — a general support@ address and a dedicated billing@ address, for example — each mapped to its own default queue or team.

The part people don't think about: replies

Creating a ticket from an inbound email is the easy half. The harder half is making sure a customer's reply to their ticket confirmation email lands back on the same ticket, instead of opening a brand new one or — worse — silently vanishing.

Email threading does this via the References and In-Reply-To headers, which every mail client sets automatically when you hit reply. Plenix's ticket-ID gets embedded in the outgoing confirmation email, and the poller matches incoming replies back to the right ticket by reading those headers.

That matching had a real, silent bug for a while: the References header, per the email spec, is always a list of message IDs, not a single string — even in the extremely common case where a reply is only threading against one earlier message. Our parser was treating it as a single string, so replies that should have matched cleanly against an existing ticket simply didn't, and were dropped rather than misfiled. It's exactly the kind of bug that doesn't announce itself: no error, no bounce, just a customer's reply that never shows up, until they email again asking why nobody responded. Fixed and manually recovered from the mail server logs on the day it was found — every stranded reply from the affected window was located and re-attached to its correct ticket rather than left lost.

Why this matters more than it looks like it should

A support desk that occasionally drops a reply doesn't look broken from your dashboard — every ticket you can see looks fine. It looks broken from the customer's side, as unresponsiveness, and that's the worst kind of bug because you won't see it in your own metrics; you'll see it in a customer's frustration a few days later. Threading correctly, on the very first attempt, on your own domain, is table stakes for a service desk — and now it's tested against exactly this failure mode so it doesn't regress quietly again.

Getting started

If you haven't pointed your own domain at Plenix yet: Settings → Mailboxes → Add Mailbox is the whole setup. Five minutes, and every reply — first message or the fifteenth in a thread — lands exactly where it should.