Nobody was hacked. for one client in Springfield, the damage was done anyway.

Every account follows the same shape. There was a wall. Someone got over it. The damage flowed from the breach, and the lesson is always to build the wall higher.

It's a satisfying shape because it assigns a cause you can point at and a fix you can buy. It is also, often, not the full story. Sometimes, the worst days a small business has involve the system working precisely the way it was built to, in a situation nobody anticipated when they set it up.

What actually happened in Springfield.

Our client runs an online retail operation and manages all of its customer communication in Zoho Desk. Every email a customer sends becomes a ticket. That's the whole point of the product, and it had served them well for years.

In the summer of 2025, the support queue began filling, first by the dozens and then by the thousands. Not with customers. With bounce-backs — automated "this message could not be delivered" replies — arriving faster than anyone could read them. Nothing had been broken into. No account was compromised. The tickets were real, the system that created them was healthy, and there was no fence anyone had climbed.

When you set up Zoho Desk, it hands you a support address to give your customers. By default, that address ends in .zohodesk.com. It works immediately, it costs nothing extra, and Zoho's own documentation tells you that you can share it with your customers. So that's what many businesses do. There was nothing careless about it. It was the obvious, sanctioned, out-of-the-box choice.

Here is the catch: that address lives on a domain the client did not own. zohodesk.com belongs to Zoho. You can only set the rules for a domain you control.

Those rules, set for every domain, let the rest of the internet tell a real message from a forged one — the digital equivalent of a return address that can actually be verified. For an address on your own domain, you set those rules yourself. For an address on someone else's domain, you can't. Not because you did something wrong, and not because the setting was hidden. Because it was never yours to set. The address customers knew the business by was, in the one way that mattered here, indefensible by design.

Someone used the client's address as the fake sender on a mass spam run, blasting it across leaked lists made up largely of dead and junk mailboxes. Every message that couldn't be delivered bounced — and a bounce goes back to the address on the envelope, not to whoever actually sent it. The address on the envelope was the client's. The bounces came home to Zoho Desk, and each one became a ticket.

The honest part of this story is the part most case studies leave out: it's often very difficult to tally the true cost of a spoofing incident. That is normal. The measurable blast radius of an event like this is almost always fuzzy — some unknowable number of real people received spam wearing the client's name, the sender reputation of the address took some amount of damage that's hard to put a figure on, and the genuine customer emails that surfaced in that flood are impossible to count cleanly after the fact. We'd rather say that plainly than invent a number.

But fuzzy impact does not soften the experience of it. What is not fuzzy is the feeling of watching thousands of tickets pour into the queue your business runs on, not knowing how many are hiding a real customer, not knowing when it stops, and not knowing what you did to deserve it.

The flood was brought under control within a day of being identified, largely to a Herculean effort by the client. The lasting fix took a little longer, because it wasn't a setting anyone could flip. It was a move.

The client already ran email on a domain they owned. We set up a new support address on that domain — one whose verification rules are theirs to set — and put it in front of customers in place of the old one. There was also the unfortunate necessity of emailing current and repeat customers to explain the mail change.

The part nobody likes.

You don't actually get to delete the .zohodesk.com address. Desk still needs it to function. So it stays, quietly, behind a forwarding rule — mail to the real address is handed off to the old one in the background. You don't get rid of the borrowed thing. You build something you control in front of it and stop handing the borrowed one out. That's the honest shape of the fix: not a clean removal, a careful arrangement.

Then we watched it.

A move like this isn't finished the day it's made; you have to confirm the new arrangement is holding and that nobody is still abusing the name. So for the rest of 2025, we monitored it daily. Once it was clearly quiet, that handed down to a lighter weekly check that now goes to the client directly. The intensive part was ours to carry. The ongoing part is sustainable for them to keep.

There are two lessons worth taking, and neither requires you to understand a line of the mechanics underneath.

First: a default is not a decision. The address the software gave them worked perfectly, right up until the day someone else used their name with it — and the very fact that it worked so easily was what made it impossible to defend. The cheapest option at setup carried a cost that didn't come due for years, and then came due all at once.

Second: not every security incident requires someone to get over the fence. The most disruptive day this business had didn't involve a break-in at all. It involved an address they were right to trust, doing exactly what it was built to do, in a situation no one had set it up to survive. The fix wasn't a higher wall. It was owning the ground it stood on.