Zendesk Spam and How to Stop It

Zendesk spam isn't just noise. It buries real customers in a queue nobody reads, and the recovery cost is measured in days.

Where Zendesk puts spam

Zendesk does not simply bin suspicious mail. It routes it to a suspended tickets queue, which is a holding area sitting between your inbox and your real queue. Nothing in there counts toward your views, your reports or your SLA clocks.

Things land there for several reasons, and only some of them are spam in the ordinary sense.

Content or sender reputation flagged by the filter.
Automated mail: out of office replies, bounce notifications, delivery receipts, newsletter confirmations.
Sender is not a registered user, if your account only accepts tickets from known users. This one catches real customers constantly.
Detected mail loops, where the same message repeats.
Mail apparently from your own support address, which almost always means a forwarding rule is misconfigured rather than an attacker.

The suspended tickets guide covers the queue itself in more depth. The point worth repeating here: suspended items are purged after a period, so an unreviewed queue is a queue that loses real customers permanently.

Working the queue without losing your week

Daily and brief beats weekly and thorough. Five minutes, sorted by cause.

Sorting by cause is the trick, because one cause usually accounts for most of the volume, and fixing that cause is worth more than triaging fifty individual messages. If four hundred of your five hundred suspensions are "sender not registered", the work isn't reviewing them. The work is deciding whether that setting is still right for you.

Scan sender domains rather than subject lines. Genuine customers come from ordinary domains you recognise. Bulk spam arrives from patterns, and patterns are much faster to read than prose.

Recovering a false positive properly

When you find a real customer in there, recover the ticket rather than replying from the suspended view. Recovery promotes it into a proper ticket in the queue, with the requester attached, so it appears in views, obeys your triggers, and starts an SLA clock. Replying from the holding area gets an answer out and leaves the record in the wrong place.

Then do three follow-ups, because a false positive is rarely a one-off.

Add the sender or their domain to your allow list so the next message goes straight through.
Check whether the requester exists as an end user. If your account only accepts registered users, creating them is the actual fix.
Apologise for the delay in the first line. They wrote days ago and heard nothing. Say so before you answer the question.

One honest caveat. A recovered ticket often arrives after the customer has already written in a second time through the web form, so you end up holding two records for one problem, created days apart in different channels. Check before you reply.

Cutting it off at the source

Filtering is defence. These reduce the incoming volume in the first place.

Stop publishing your support address as plain text. A support@ string on a public page is harvested within weeks. Use a form, or obfuscate it.
Put spam protection on your web form. A publicly reachable form with no challenge will be found by bots eventually.
Retire dead addresses. Old brand or acquisition addresses that still route into Zendesk are usually pure spam by now. Close them.
Fix your own email authentication. Correct SPF and DKIM records help receivers trust you, and they also reduce the odds of your own mail looping back in looking suspicious.
Suspend or block persistent offenders at the user level rather than blocking their whole domain. Domain blocks are blunt instruments and they eventually catch a customer.

What not to do

Do not turn on "only accept tickets from registered users" as an anti-spam measure without understanding the trade. It's effective, and it silently suspends every first-time customer who emails you. For a B2B desk with a known account list, fine. For anything consumer-facing, that setting will cost you more than the spam did.

And don't delete the suspended queue unread on a Friday because it looked long. That's the single most expensive five seconds available in Zendesk administration.

FAQ

Frequently asked questions

Can you block spam before it reaches the queue?

Partly. The Zendesk spam filter catches most of it into suspended tickets, and to block spam Zendesk also lets you blacklist addresses and domains outright.

Where do spam tickets go in Zendesk?

To the suspended tickets queue, a holding area separate from your normal views. Items there do not count toward reporting or SLA, and they are purged automatically after a period.

How do I recover a ticket Zendesk marked as spam?

Find it in the suspended queue and recover it, which promotes it to a real ticket with the requester attached. Then allow-list the sender so the next message is not suspended too.

Can I stop legitimate email being flagged as spam?

Allow-list known domains, make sure requesters exist as end users, and reconsider whether the registered-users-only setting suits your audience. Sorting suspensions by cause shows you which of these to fix.

Does spam count toward my Zendesk ticket limits?

Suspended items are not normal tickets, so they sit outside your working queue. Anything you recover becomes a real ticket and counts from that point.

Should I block a whole domain?

Rarely. Domain-level blocks are blunt and eventually catch a customer or a partner. Suspend individual users first and reserve domain blocks for sustained abuse.

The second ticket spam creates

A customer who gets no reply writes again through another channel. Ticket Merger catches the pair even days apart.

Start free trial

14-day free trial. No credit card required.