Why am I getting Zendesk support ticket spam emails, and how do I stop them?
A number of administrators are seeing a fresh spike in spam tied to Zendesk, with inboxes getting flooded over the past couple of days. Reports suggest the messages look like legitimate support-ticket traffic, but the underlying intent is to push spam through workflows that normally bypass suspicion.
What appears to be happening is a modern version of contact-form abuse. A real person submits a genuine inquiry to a business that uses Zendesk, but they enter someone else’s email address in the contact field. When Zendesk or the receiving team replies, that reply can go to the “foreign” address, effectively turning routine ticket handling into a delivery path for unwanted mail. The result feels like “spoofed” ticket threads, even when parts of the workflow are technically functioning as designed.
Several admins report they are not alone. One reader referenced a Mastodon post describing the same pattern. The core issue is that the inbound inquiry can look valid, while the supplied contact address is not trustworthy. That mismatch is what makes this incident disruptive: it blends normal helpdesk behavior with a spammer’s ability to route messages to targets.
This should not be dismissed as harmless noise. Beyond inbox clutter, it can create real operational risk:
- It increases the chance staff reply to manipulated threads
- It can train users to trust ticket-looking emails
- It can hide phishing behind a familiar vendor template
If your environment is being hit, focus first on verifying where the messages actually originate and how they authenticate. Review message headers for alignment across From, Return-Path, Reply-To, and the sending domain used by Zendesk in your tenant. Then confirm whether SPF, DKIM, and DMARC checks pass for that sender. Even when authentication passes, remember the abuse can still occur if the platform is sending “legitimate” mail triggered by bad form data.
From a practical defense standpoint, reduce the ways your Zendesk flows can be used as a relay:
- Require stronger verification for new end-user identities where feasible (email verification, domain allowlists for certain forms, or tighter triggers)
- Add rules to detect patterns common in form abuse (unusual sender domains, high-volume bursts, repeated subjects, repeated templates)
- Rate-limit or queue first responses for untrusted contacts so you can inspect before sending
- Adjust notification behavior so internal staff see the ticket, but external email responses do not automatically fire until a basic trust check passes
Also document what you see: first observed time, volume per hour, common subject lines, affected brands or templates, and whether the traffic is tied to specific Zendesk forms or entry points. That record helps both internal escalation and vendor support.
For additional context, other security coverage has noted a Zendesk-linked spam wave reported since January 18, 2026, including reporting by BleepingComputer.