TL;DR: The “Relay Spam” Crisis
- The Event: Since January 18, 2026, a massive global “relay spam” campaign has weaponized the customer support systems of major brands (including Discord, Tinder, and Riot Games) to flood inboxes worldwide.
- The Hook: Victims receive legitimate “ticket received” auto-replies from real company domains. Because these emails come from trusted infrastructure, they bypass many spam filters.
- The Vulnerability: Attackers are exploiting a common configuration, anonymous ticket submission. By submitting fake support requests with a victim’s email address, they force the brand’s own system to send the spam.
- Current Status (Jan 23): The attack is ongoing and unclear. It is now being used for “mail-bombing” (burying a specific person’s inbox in thousands of emails) and is damaging the sender reputation of the affected companies.
- The ZenDesk Fix: Zendesk characterises this as relay spam and recommends two primary mitigations: remove attacker-controlled placeholders from first-reply triggers (including
{{ticket.title}}and requester name fields) and, where possible, disable “anyone can submit tickets” / restrict ticket creation to added users. - Zendesk says it has added enhanced monitoring and activity limits to detect and stop abusive patterns faster, but individual customer configuration remains the biggest lever.
The Deep Dive
As of January 23, 2026, a global email-abuse campaign is still leaning on a very ordinary failure mode: misconfigured Zendesk support desks. The result is that legitimate companies are, without meaning to, sending huge volumes of “ticket received” auto-replies to people who never contacted them. This is not a one-off glitch. It is what happens when anonymous support forms meet automation and a big list of email addresses.
This issue has been ongoing since January 18, 2026, when what has been described by some as a global spam wave abusing Zendesk support desks configured to accept tickets from unverified/anonymous users, causing legitimate “ticket received” auto-replies to be sent to victim addresses.
People around the world reported getting hundreds of unsolicited acknowledgement emails, often within minutes. The important detail is that these messages were not spoofed. They were sent by real customer-support systems, from domains and infrastructure that mailbox providers generally trust.
The abuse is simple. Many Zendesk (and similar help-desk) setups allow anyone to open a ticket without proving they control the email address they enter. An attacker can feed a support form a large list of addresses and let the platform do the rest: each submission triggers an automated acknowledgement to the address on the ticket. Because those acknowledgements come from legitimate, well-reputed systems, a lot of them land in the inbox.
Much of what people are seeing (at this time) looks like reputational risk rather than direct malware delivery. Subject lines reported by recipients include fake law-enforcement orders, corporate takedown notices, offers of free “Discord Nitro”, and strings of odd Unicode characters. The intent is harder to pin down. Disruption is the obvious one. Another possibility is conditioning: training people to tune out support emails so a real phish blends into the noise. Either way, it is messy. Organisations reported as being caught up in the flood include Discord, Tinder, Riot Games, Dropbox, NordVPN, and Tennessee state departments.
Zendesk has acknowledged the abuse and says it has added monitoring and rate limits to detect unusual activity and stop it faster. It also previously warned customers about this “relay spam” behaviour and recommended straightforward configuration changes, including restricting ticket creation to verified users and removing attacker-controlled fields from auto-responses. Zendesk’s framing is that this is not a platform vulnerability so much as the downside of anonymous ticket workflows.
What it really means for us
Support desks are built to reduce friction. That is the whole point. But friction-free workflows are exactly what attackers look for, especially when the output is email that carries the sender’s reputation with it.
For email and deliverability teams, this is a painful category because “just block it” is rarely an option. These messages come from real companies, real domains, and IPs users may genuinely need. The practical defence is pattern-based: spot bursts of ticket creation, look for abnormal volumes of outbound notifications, and train users to treat unexpected support emails as background noise, not a call to action.
Practical steps for Industry Leaders
- Support Architecture: Beyond simple verification, organizations should implement Liquid Markup logic in auto-responders to programmatically strip user-supplied placeholders (like
{{ticket.title}}) from the initial outgoing mail. This neutralizes the “payload” without adding the friction of a login wall. - Reputation Safeguards: Security teams need to move beyond “monitoring surges” to Automated Reputation Throttling. If an outbound notification burst exceeds a baseline, the system should automatically divert those specific notifications to a lower-priority, “high-risk” IP pool to protect the primary support domain’s deliverability.
- Recipients & Ecosystem: Enterprise mail admins should look for Header-based filtering. Zendesk emails carry specific
X-Zendesk-headers. Filters can be written to “Quarantine” rather than “Block” if a message matches a known malicious pattern while originating from a trusted domain.
Status on January 23, 2026
This is not “fixed” in a global sense. Zendesk can throttle and detect, but the biggest lever is still customer configuration, and thousands of accounts will not change settings until someone notices the reputational damage.
Public reports today (especially on Reddit and social platforms) suggest new waves are still hitting inboxes, with additional brands being named. The problem looks “whack-a-mole” by design: attackers can rotate target forms, swap subject lines, and keep moving.
There are also signs the technique is being used more aggressively. Some researchers and users are describing targeted mail-bombing, where a specific individual is hit with thousands of auto-replies to make their inbox unusable. As mailbox providers filter common subject lines, attackers appear to be rotating to stranger Unicode strings and different social-engineering themes.
Long Term Harm
For brands using support platforms that are attacked their is longer-term harm is reputational. Some organisations are finding that their legitimate support traffic is now more likely to be filtered to spam because their support addresses were associated with high-volume junk during the peak of the campaign. A single 48-hour wave of relay spam can ‘poison’ a support domain for weeks or even months. Once Gmail’s filters decide support@brand.com is a source of Nitro scams, your legitimate CSAT scores will plummet because users never see your replies.
Open questions remain: how broadly Zendesk customers were affected, how quickly organisations are tightening workflows, and whether attackers turn this from volume abuse into more targeted phishing. The uncomfortable truth is that “mundane” systems like support desks can be turned into high-trust mailers if nobody puts a gate on the front door.
