Who do you call when the companies you trust suddenly appear to be sending you threats? For thousands of people last week the answer was: no one could fix it quickly — because the messages weren’t forged in the usual way, they were channeled through the plumbing of customer service itself.
Security reporter Brian Krebs detailed an alarming campaign in which attackers exploited lax outbound email authentication in the widely used customer-service platform Zendesk to launch “email bombs”: coordinated floods of menacing messages that appeared to come from hundreds of legitimate corporate customers at once. The flaw turned routine support workflows into a conduit for harassment and intimidation, and it exposed a brittle link between convenience and trust in digital communications .
At issue are the fundamental email-authentication protocols — SPF, DKIM and DMARC — that let recipient mail systems verify who actually sent a message. When a third-party service like Zendesk relays mail on behalf of its customers, the service and each customer must align DNS records, cryptographic signatures and policy settings so authentication checks pass. According to the reporting, attackers used Zendesk ticketing interfaces, APIs or public support forms belonging to many different customers to push intimidating messages into selected inboxes; because those messages were relayed through legitimate Zendesk infrastructure and often passed standard checks, they were hard to block with traditional filters .
“If the message comes from an IP address that has a good reputation and uses SPF/DKIM that appear to match, spam filters have fewer signals to block it,” said Paul Cook, a senior security engineer focused on email threats, summarizing why these campaigns are unusually difficult to detect or throttle . That technical reality turns a familiar customer-support feature — sending email that looks like it’s from a brand and routing replies into a ticket — into an attack surface when authentication and defaults are weak.
How the abuse plays out in practice:
/
Attackers identify or create support touchpoints on many Zendesk-powered sites (forms, widgets, APIs).
/
They submit or trigger messages that Zendesk relays to targets, making the mail appear to originate from the legitimate companies that own those support channels.
/
Because the relays use infrastructure and addresses already trusted by recipient systems, usual reputation-based blocks and spam filters struggle to separate malicious bursts from normal traffic.
The consequences are practical and psychological. Recipients confronted by hundreds of threatening messages worry about compromise, impersonation, or targeted extortion. Security teams face noisy alert storms and must coordinate with platform vendors to revoke abused credentials, adjust outbound controls, and trace the abuse back through customer accounts. Mail providers are forced to consider novel heuristics for distinguishing coordinated, multi-domain bursts from normal business traffic — a nontrivial problem when the sender IPs and sending domains carry good reputations .
Technologists point to several clear mitigations. Platform vendors should enforce stricter defaults for outbound authentication, require domain verification before relaying mail on a customer’s behalf, and make it simple for customers to set up SPF, DKIM and DMARC correctly. Customers should treat support endpoints like any public API: require throttling, challenge high-volume submissions, review webhook and ticket settings, and adopt DMARC policies that report and, when appropriate, reject unauthenticated mail. Mail providers should adapt reputation models to account for third-party sending relationships and implement automated throttles that detect coordinated bursts from many trusted domains simultaneously .
There are also policy and market angles. When a single cloud platform can amplify harassment at scale, questions arise about disclosure obligations following abuse, the adequacy of industry self-regulation, and whether standards bodies should tighten default security requirements for cloud-based communication services. Regulators might press vendors to adopt safer defaults; customers may demand contractual assurances about outbound authentication and abuse detection; and competitors may seize the moment to make secure-by-default an explicit selling point.
From an adversary’s perspective, the tactic is rational: weaponize a trusted conduit to maximize impact and make defensive attribution costly. From defenders’ view, the episode underscores a perennial lesson — convenience without guardrails can become an attacker’s force multiplier. The Zendesk case shows that even mature protocols like SPF, DKIM and DMARC can fail to protect users when deployment is optional, poorly documented, or left to per-customer configuration.
For organizations that rely on third-party messaging, the immediate playbook is straightforward and urgent:
/
Audit support channels and third-party relays for proper SPF/DKIM/DMARC alignment.
/
Require domain verification and enable strict outbound authentication defaults where available.
/
Harden public forms and APIs with rate limits, CAPTCHAs or other challenges to prevent automated mass submissions.
/
Work with providers to monitor and throttle unusual sending patterns tied to your account.
The Zendesk episode is a cautionary tale about the hidden costs of delegating customer communications. It also offers a roadmap: vendors must make secure configuration the default; customers must demand and verify those protections; and defenders must evolve detection to consider relationships between senders and third-party platforms. Failing to do so leaves trusted infrastructure vulnerable to being turned against the very people it was meant to serve.
If defenders and vendors act, the next generation of email-borne extortion and harassment can be blunted. If they do not, the attackers need only find the next widely used conduit and repeat the tactic. Which will the market — and the regulators — choose: easier workflows, or safer ones?
Source: https://krebsonsecurity.com/2025/10/email-bombs-exploit-lax-authentication-in-zendesk/
