Plan requirement
| Subscription | Any plan |
| Access | Agent |
One message producing two tickets, or a reply starting a new one. Five causes, and the one nobody guesses is that Zendesk keeps threading data for only 30 days.
Symptoms
- Two identical tickets, seconds apart, from one customer.
- A reply creating a new ticket instead of continuing the old one.
- A reply landing on a completely unrelated older ticket.
Resolution steps
1. Is the reply more than 30 days old?
Zendesk keeps threading header data for 30 days. Beyond that, the data needed to make the connection is gone, and the reply becomes a new ticket however correctly it was addressed.
This is the one that looks like a fault and is not. Long-running conversations with gaps of weeks will do this every time.
2. Did the message lose its reference?
Zendesk matches a reply in three ways, in this order: the References and In-Reply-To header lines; an encoded ID in square brackets in the message body, such as [1G7EOR-0Q2J]; and an encoded ID in the receiving address itself, in the form support+id1G7EOR-0Q2J@yoursubdomain.zendesk.com.
Some mail clients and corporate filters strip headers or rewrite bodies, which removes all three. It is usually specific to one customer's mail system, so check whether the duplicates all come from the same sender.
3. Were two of your addresses on the message?
By default this makes one ticket, even with several of your support addresses on the email. A setting called multi-recipient email tickets changes that to one ticket per address, so each team gets its own, and it became available to everybody on 1 September 2026.
You can tell the two apart without asking anybody. Tickets made that way are linked by a Multi-recipient email ID field and open with a private note saying they came from that workflow. If you see those, this is the setting working as intended rather than a fault, and the answer is to decide whether you want it on.
4. Is the forwarding duplicated?
Two forwarding rules pointing at Zendesk, or a rule plus a connector, both deliver the same message. Look for an old rule left behind after a change; that is usually where it is.
5. Was the original ticket closed?
Then a reply correctly creates a follow-up ticket. Working as designed, and it looks exactly like duplication until you check the status of the original.
The opposite problem
Replies threading into the wrong ticket has the same root. If a header line carries a static message ID, or somebody pastes an old encoded ID into a new message, Zendesk attaches the reply to that ticket instead.
The fix is to start clean: copy the content into a fresh email and send it to the same reply-to support address, so it carries no stale references.
What to do with the duplicates you have
Merge them. If it recurs with one customer, causes one or two are worth investigating rather than merging every week.
To prevent it, publish one support address rather than several, and check that only one route delivers to Zendesk. Most duplication is two paths doing the same job.
Comments
0 comments
Article is closed for comments.