Suspended ticket queue: what lands there, and why real customers do too
In short
A suspended ticket queue holds inbound mail a helpdesk decided was probably not a customer, before any trigger, view or classifier ran. The decision is made on envelope headers, SPF and DKIM alignment and sender reputation rather than on what the message says — which is why shared aliases, forwarded threads and the customer's own service desk land there routinely, and why nobody notices.
Key takeaways
- Suspension runs before your rules, so nothing configured downstream can see or correct it.
- The decision reads headers, SPF and DKIM alignment and sender reputation — not what the customer wrote.
- A false positive is silent: no ticket, no timer, no notification, and the sender's copy shows delivered.
- A recovered ticket starts its first-reply clock at recovery, not arrival, which flatters the metric.
- Sample 25 suspended items a week. Above roughly 2 per cent genuine, the filter is mis-tuned.
- Never auto-purge the queue: deleting it destroys the only evidence the filter is wrong.
Suspension is the first triage decision in the chain and the only one you did not configure. Before a trigger fires or a classifier reads a word, the mail layer decides whether a message is plausibly from a human customer. If it decides not, the message goes to a holding area — suspended, quarantined or filtered, depending on the vendor — where it creates no ticket, notifies nobody and starts no clock.
Every other triage mistake announces itself. A ticket in the wrong queue gets reassigned, a wrong intent gets corrected, a wrong priority produces a complaint. A wrongly suspended message produces nothing at all, and the sender's mail client shows it delivered.
What diverts mail before any rule of yours runs
The checks are transport-level, and that is the point: they largely do not read the body. A carefully worded, obviously genuine customer email is filed away on the strength of how it was sent.
- Authentication alignment. SPF, DKIM and DMARC tell the receiver whether the sending domain authorised this path. Forwards, mailing lists and marketing relays break alignment while the human stays real.
- Sender reputation. The sending address and its infrastructure carry a score the sender cannot see. A customer on a badly configured self-hosted server inherits a bad one.
- Automatic-submission markers. Standard headers exist to declare that a machine wrote this — the auto-submitted header from the IETF standard for automatic responses, plus bulk-precedence and mailing-list headers.
- Loop heuristics. Near-identical mail arriving repeatedly from one sender gets held; that failure is diagnosed in a mail loop between your system and theirs.
- Identity rules. Mail from an address matching no known user, or apparently from your own support address, is suspicious by default.
- Size and attachments. A 30 MB log bundle or an executable diverts an otherwise unremarkable message.
The legitimate sender shapes that get filed as machines
In a B2B queue these are ordinary traffic, not edge cases. Each is a recognisable shape you can allow for once instead of rediscovering monthly.
| Sender shape | Why it trips | What to do |
|---|---|---|
| A shared alias — ops@, accounts@, it@ | Distribution lists rewrite the envelope and break alignment; no individual user matches | Allow the domain, attach the ticket to the company record |
| The customer's own service desk, replying with their reference | It genuinely is an automated response and carries the markers | Treat named partner systems as approved automation |
| A thread forwarded in by a colleague | The envelope sender is now the forwarder, so the original DKIM signature no longer aligns | Recover, then read the requester from the forwarded headers |
| A no-reply relay from a form or monitoring tool | No-reply addresses and machine subjects are the exact target profile | Allow by sending domain; expect no usable reply-to |
| A reply from a phone using a personal alias | The address matches no known user and no original recipient | Match on thread identity as well as sender |
Recovery is not one click. The message still has to attach to the right company, and getting that wrong converts a silent failure into a loud one — the rules are in requester, end user and organisation.
Read the queue as a measurement, not a chore
- Once a week, take the most recent 25 suspended items — not the whole queue, and not a filtered subset.
- Classify each as spam, unwanted automation, or genuine, where genuine means a human expecting a reply.
- Record the genuine rate. Above roughly 2 per cent your rules are costing real conversations, and the sender shapes above are where to look first.
- Write an allow rule for the shape, not a recovery for the message. Recovering without a rule guarantees the next one is suspended too.
The queue also distorts anything measured from tickets. A classifier trained only on what got through learns the filter's blind spots as truth — related to, but distinct from, one intent label absorbing the queue. Reporting upward inherits the same bias: turning tickets into themes a product manager will accept is only as honest as the population it clusters.
Suspension is deliberately conservative about what it will call a person, which is right for a public address and wrong for a queue full of B2B automation. It is not the same fault as a genuine message that arrives and fragments into 3 tickets — that is customer replies opening brand-new tickets.
A weekly sample, a small recovery view and a written list of approved senders is a couple of days of internal tools and ops work, and the cheapest correction in ticket and inbox triage. The wider practice is SaaS and customer support.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is the difference between a suspended ticket and a deleted one?
A suspended message never became a ticket; a deleted ticket did. Suspension happens at the mail layer before ticket creation, so there is no requester attached, no timer running and nothing in your views — just a holding area with its own retention period. Deletion acts on something already counted.
Why did a real customer's email get suspended?
Almost always because of how it was sent, not what it said. Forwarded threads, shared aliases, replies routed through the customer's own service desk and mail relayed via marketing platforms break SPF or DKIM alignment, or carry automatic-submission headers — exactly the profile the filter targets. Check the sending path before assuming the content triggered anything.
Should we turn suspension off entirely?
No — turn it down and sample it. A public support address with no filtering fills with bounces, out-of-office replies and spam, and that cost lands on the same agents. The workable position is a conservative filter, a written allow list of automated senders you want, and a weekly sample of what was held.
Does a suspended message count against our first-reply target?
Usually not, and that is the trap. The clock starts at ticket creation, which for a recovered message is when somebody rescued it rather than when it arrived, so a message held for days still reports a fast first reply. Decide explicitly whether recovered tickets are backdated or reported separately.
- triage
- helpdesk
- spam filtering
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- Requester, end user and organisation: the records a ticket hangs offA ticket points at several identity records, not one. Entitlement belongs to the company record, tone belongs to the person, and mixing them is how the wrong customer gets premium routing.definition
- Customer replies are opening new tickets instead of threadingOpen the raw source of one orphaned reply. Whether the References chain contains your outbound Message-ID decides whether this is a matching bug, a stripped-header problem, or an identity problem.diagnostic
- A mail loop is manufacturing tickets between your system and theirsRunaway ticket volume from a single counterparty is rarely spam. It is two automated systems answering each other, and the fix is a header rule your responder should already have been applying.diagnostic
- Intent taxonomy: the label set a support router can act onAn intent is not a description of a ticket. It is the instruction a router acts on, which means a label no queue, macro or automation consumes is not a label at all.definition
- First-reply SLA timer: start, pause and breach are three different eventsA first-reply SLA is three settings, not one, and most breach reports that look like a staffing problem are one of the three configured differently from how the team believes.definition
- One intent label is absorbing most of your ticketsA collapsed label distribution has four possible causes and only one of them is a model problem. Two histograms, thirty days apart in five minutes of SQL, tell you which.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation