One compromised email account should not put your other customers at risk
Every multi-tenant sender eventually gets the alert: one customer's account has been compromised and is pumping out phishing emails. When that occurs, two things have to happen at the same time. The phishing emails need to be quickly stopped, and the customer needs help finding the source of the issue to limit damage to their reputation (and that of the email infrastructure) and get back to their regular sending.
The hard part is doing both without punishing every other customer who shares your email infrastructure. That comes down to how fast you can find the bad traffic, and how precisely you can stop it.
Most compromises start the same way. A customer has been sending clean emails for months, then a leaked API key, a reused SMTP password, or a hacked web form hands an attacker the keys. The attacker isn't spoofing anything. They're sending through a legitimate account with real credentials, so the mail goes out with valid SPF, DKIM, and DMARC. These authentication methods prove an email came from the right place. They can't prove the right person sent it.
On a shared platform, that's where the real damage starts. The phishing goes out over the same IPs and the same sending domains your other customers use. Mailbox providers don't care whose account it was. They see spam complaints, spam trap hits, and blocklist listings, and they start deferring, throttling, or junking everything coming from those IPs. Every minute that traffic keeps flowing, your other customers' deliverability takes another hit.
Because your other customers are still sending email that people are waiting on, such as password resets, one-time passcodes, login links, or order confirmations. If those sit in a paused queue while your team investigates, the end user doesn't blame you. They blame your customer, and your customer blames you.
Hitting the big red button trades one problem for a bigger one. What you need is the ability to stop the bad traffic from one account while everything else keeps flowing.
An alert tells you something is wrong. It doesn't tell you which account, which credentials, or what's actually in the messages. Your email operations team needs those answers in minutes, not after an hour of grepping logs across a dozen servers. That means having message history, delivery results, and remote server responses tied to the tenant, all in one place.
The signals are usually there if you know where to look:
Context matters, though. A customer launching a big campaign will send more email to new people too, and that doesn't mean they've been hacked. Your team needs enough data to tell the difference quickly.
Once abuse is confirmed, nobody should be scrambling to write a firewall rule or call the customer to get them to stop. Containment should already be built into your policies so the affected account's traffic is held the moment you pull the trigger, while every other tenant keeps sending.
Stopping new submissions only solves half the problem. By the time abuse is confirmed, there are usually thousands of phishing messages already sitting in the queue waiting for their next retry. If you don't deal with them, they'll keep going out long after you've locked the account.
Your team needs to be able to find every queued message tied to that account and hold it, without touching anyone else's mail. That's a lot easier when your queues can be split by tenant instead of everything sitting in one big pile per destination.
The same care applies when the customer is ready to send again. Once they've rotated their credentials and closed the hole, turning their account back on should not automatically release everything that was held. Someone needs to review that backlog, deliver the legitimate email, and delete the rest. Otherwise, you just restart the same attack you worked so hard to stop.
So, do the needs of the many outweigh the needs of the few? On a shared platform, you don't have to pick. Stop the bad traffic fast and precisely, and you protect every customer who did nothing wrong. Give the compromised customer the data they need to find the source, and you get them back to sending without losing them as a customer. How well your email infrastructure handles a compromised account is one of the best tests of whether it's built for multi-tenant sending.