A compromised mailbox is rarely reported by its owner. It is discovered because the server started sending spam, or because a customer says they received something strange from you.
The order of the response matters, and one step in it is almost always skipped.
Stop the sending first
If mail is still going out, that is doing damage to everyone on the server right now: the address's reputation is shared.
Suspend the account or the mailbox immediately, then investigate. Suspension is reversible, so acting fast on a suspicion costs an apology at worst. Suspending accounts deals with doing it quickly.
Change the password
From a device you trust. If the compromise came from malware on the owner's computer, changing the password from that computer hands over the new one immediately.
Change it in the hosting control panel rather than through any link in an email, and make it a password used nowhere else.
Then find the rule
This is the step that gets missed, and it is what keeps the attacker in after the password has changed.
Check, on that mailbox:
Forwarders. A forwarder sending a copy of every message to an outside address. It survives password changes, and nothing in the mailbox itself shows that it exists, messages arrive normally.
Filters and rules. Frequently a rule that deletes or files anything mentioning "password", "security" or the bank's name, so the owner never sees the warnings.
Autoresponders. Occasionally used to reply to everyone who writes in.
Look in both the hosting control panel and the webmail interface: rules created in one may not be obvious in the other. Creating email filters explains where they live.
A mailbox where the password was changed and the forwarder was left is a mailbox that is still compromised.
Clear the queue and check the damage
exim -bp | tail -20
Thousands of queued messages from one account is the signature. Clearing the queue removes the backlog; it does nothing about the cause, so do it after the password and the rules, not before.
Then check whether the server's address has been listed as a result, because that affects every customer on it. What to do when your IP or domain is blocklisted explains the delisting process, which is slow and easier if the cause is demonstrably fixed.
Work out how
Two causes account for nearly all of it.
A reused password. The password was disclosed in another service's breach and tried here. This is the most common by a distance.
A convincing fake login page. A message claiming the mailbox was full or the password expiring, leading to a page that looks exactly like the webmail login.
Malware and unencrypted connections on public networks account for most of the rest.
Asking the owner what they clicked recently is worth doing plainly rather than accusingly, people conceal it when they feel blamed, and the answer changes what else needs checking.
The same password is used elsewhere
Almost certainly. If it was reused, every account sharing it is compromised, and the email account is often the least valuable of them.
The owner needs to change it wherever it was used, starting with anything financial. This is the part of the conversation people resist and it is the part that matters most.
After it is contained
Enable two-factor authentication on the control panel, and prefer it wherever the mail provider supports it. It defeats the reused-password case entirely. Two-factor authentication in cPanel goes into it.
Check the other mailboxes on the account, since a compromise obtained by phishing one person frequently caught others.
And review the account's hourly sending limit. A limit that ordinary use never reaches is what stops the next occurrence from becoming a blocklisting before anyone notices. For setting it, see Exim configuration and mail routing.
Establish what was reachable
Before deciding how far the response goes, work out what the mailbox actually held.
An address used for password resets on other services is more serious than one used for correspondence, because access to it is access to those accounts. That distinction decides whether this is a mail incident or something wider.
Ask the owner directly which services use that address, and check the mailbox's own folders for reset messages; the presence of those tells you what an attacker could have reached in the time they had.
Where financial or administrative services are involved, those need their own password changes regardless of what the mail server shows.
Read the sent folder and the trash
Two places that record what was done, and both are frequently emptied by the attacker, which is itself informative.
Messages sent from the account show who was contacted, and it is common for an attacker to write to the owner's real contacts from a genuine address. Those people need warning, and that is a call the owner has to make quickly.
An empty sent folder on an account that plainly sent thousands of messages means it was cleared deliberately, and the server's own log is then the only record. There is more on reading it in Exim configuration and mail routing.
Check every device before declaring it resolved
A password change locks out an attacker and also locks out every device the owner uses. What follows is the pattern people misread.
A phone still configured with the old password retries every few minutes and triggers the automatic blocking, which then blocks the owner's own address repeatedly. The report is "you fixed it and now I cannot get in", and the cause is a second device nobody mentioned.
Ask how many devices and clients are configured, and update all of them in the same sitting. Diagnosing a mail client that will not connect goes into the release side.
Tell the people who received the messages
The part that is uncomfortable and matters most.
Messages sent from a genuine address, to real contacts, are trusted in a way that ordinary spam is not. Recipients who act on them are harmed by an incident that was not theirs.
A short, factual note from the owner (what happened, what to ignore, what to do if they acted on it) is what limits the damage. It is easier to send within a day than a week later.
Where the messages went to customers, this is also a reputational matter rather than only a technical one. For writing it plainly, see telling clients about incidents.