Setting up email-to-ticket without creating a mail loop

Connecting your existing shared mailbox is the step that makes a service desk real. It is also the step with two failure modes serious enough to be worth understanding before you start: replies landing on the wrong ticket, and a mail loop that fills somebody's inbox overnight.

Do not create a new address

Keep the address people already use. A desk that works perfectly at a new address nobody writes to is not a working desk, and "please email support@ instead of helpdesk@ from now on" is an instruction you will be repeating in eighteen months.

Connect over IMAP to the mailbox as it is. Nothing is forwarded or changed until you point your mail at it, so you can configure it, test with one message, and switch over when you are ready.

Threading: why subject lines are not enough

When someone replies, the system has to work out which ticket the reply belongs to. There are four signals, and the order you use them in decides how often you get it wrong:

1. Message-ID — the unique identifier of the original message. Unambiguous.
2. In-Reply-To — points directly at the message being replied to.
3. References — the whole thread chain, which survives several hops.
4. A token in the subject line, like [TKT000123].

Systems that lead with the subject line get this wrong in one specific and very annoying way: somebody forwards a thread to a colleague, the colleague replies with the subject intact, and their reply attaches to a ticket they were never part of. Use the headers first and the subject token only as a fallback.

The loop guard, and why it will eat mail you wanted

A mail loop happens when your acknowledgement triggers an automatic reply, which creates a ticket, which sends an acknowledgement. Two systems can generate thousands of messages between them overnight.

The defence is to discard anything that looks automated: messages carrying Auto-Submitted, X-Autoreply, or mailing-list headers. That is the right default and you should not turn it off.

But it has a consequence people meet the hard way. A group address — the kind your HRMS or monitoring system relays through — stamps every message it passes on as mailing-list mail. So genuine notices sent through a group get discarded silently, and nobody notices until somebody asks why no case was opened for fifteen leavers.

The fix is an allow-list of specific senders whose automated mail you do want, per mailbox. Not turning the guard off — naming the exceptions. And the log should say why each message was treated the way it was, so "a loop was stopped here" and "this one was kept on purpose" can be told apart at a glance.

Acknowledgements: useful, and easy to overdo

An acknowledgement should say three things: we have it, this is its number, and this is roughly when to expect a reply. That is all. Nobody has ever been reassured by four paragraphs of process.

• Cap them at one per sender per hour, or a person forwarding five things gets five emails in a minute.
• Never acknowledge an automated message.
• Send from the address the mail arrived at, so replies come back to the right queue.

Bounces are information, not noise

When a reply bounces with a permanent failure, the address is wrong — somebody left, or there is a typo in the record. Mark it on the ticket where the agent will see it, rather than logging it somewhere nobody reads. An agent waiting on a reply that can never arrive is a slow and entirely avoidable failure.

Autoresponders, the other half of the loop

The mail loop everybody fears is two automated systems replying to each other forever, and the guard above stops it. The quieter version is your own acknowledgement mail. Send one on every inbound message and a colleague who forwards a thread of nine emails receives nine acknowledgements, which teaches four hundred people that your desk is noisy. Acknowledge once, when the ticket is created, and never on a subsequent reply to an existing ticket.

The order to do it in

1. Enable IMAP on the mailbox — it is off by default on some Microsoft 365 and Google tenants.
2. Create an app password if the account uses two-factor authentication.
3. Connect and run the IMAP and SMTP tests. Read the exact error rather than guessing.
4. Set the default category, priority and queue for mail arriving here.
5. Send yourself one message and watch it become a ticket.
6. Reply from the ticket and check the reply threads in your own mail client.
7. Forward the thread from a second account and check it does not create a second ticket.
8. Only then point your real mail flow at it.

Header-first threading, a loop guard with a per-sender allow-list, and a message log that says why anything was skipped. The setup guide