Nobody thanks the spam filter. When it works, the day is quiet and the user believes their inbox is simply calm. When it holds one invoice, it becomes the reason accounting is late, and the ticket arrives with an exclamation mark in the subject line.
Both halves of that job land on the help desk, and the second half is where the interesting decision lives.
Quarantine is not a spam folder
Users conflate the two, and the difference matters. A junk folder sits inside the mailbox: the message was delivered, the user can open it, and everything after that is their call. Quarantine sits outside the mailbox: the platform accepted the message from the internet, decided it was dangerous or unwanted, and parked it somewhere only an administrator can see.
That distinction explains why the user cannot help themselves here. From their side there is nothing to check and nothing to drag out of a folder. The message simply never existed. So the ticket reads “I never got it,” and the person who can see it is you.
Filters score rather than judge. They weigh the sending infrastructure, the reputation of the domain, the shape of the content, the links, the attachments, and produce a confidence number. High confidence gets held. That approach catches an enormous amount of genuine junk, and it also catches the invoice from the small supplier whose mail server has been configured badly since 2011.
The release decision
Here is the part that is never in the training material. When someone asks you to release a message, they are almost always right, and the times they are wrong are the times that matter.
The request has a familiar shape: I am expecting a document from a client, it has not come, can you check the filter. That expectation is precisely the lever phishing pulls. An attacker who knows an invoice is due sends one, the filter catches it, and the user innocently asks IT to hand it over. Release without looking, and the filter’s correct decision has been overridden by the help desk, which is the one bypass no security tool can defend against.
So look before you release. The sender address behind the display name, whether the domain is really the client’s or a near miss, whether the subject matches what the user described, whether there is an attachment nobody mentioned. None of that takes long, and the answer is usually reassuring. When it is not reassuring, you have just prevented the incident rather than responded to it.
When a legitimate sender keeps getting held, releasing the individual message is the short term fix, and the real fix is a rule for that sender. Releasing the same invoice every month for a year is not a workflow, it is a subscription.
Block lists have history attached
The blocked sender list gets treated as a settings screen when it is closer to a scar. Entries usually arrive after something happened: a domain that sent malware, a campaign that hit forty mailboxes, an address that impersonated an executive. The person who added it had a reason, and that reason is rarely written down anywhere the next tech will find it.
Which is why removing an entry is a decision, not a favor. Someone asks why they cannot get mail from a domain, the list explains it, and the honest answer is that it is blocked for a reason worth confirming before it is undone. If the block turns out to be stale, remove it and note why. If it turns out to be a domain that was used in an attack six months ago, the user has just learned something more useful than a fixed inbox.
The same instinct applies to what sits in quarantine. A quarantine holding obvious fraud, the lottery win, the account suspension notice from a domain that does not exist, is a filter doing its job. The temptation to clear it out wholesale so the queue looks tidy costs you the only record of what the company is being targeted with this week.
Where this fits in the ticket
Filtering is one branch of the wider mail not arriving ticket, and it is worth checking early because it resolves in seconds when it is the cause. A message trace that shows a quarantined status has already told you where to look, and everything after that is judgment rather than troubleshooting.
That judgment, the quiet decision about whether to hand a held message to a user who is waiting for it, is the kind of thing you can only really practice by making the call. ServiceDesk Simulator puts a Mail Security console in the tool list with a quarantine and a block list that both contain the genuine article alongside the false positive, so releasing everything in sight is not a strategy. Reading before clicking is, and it is a habit far better learned in a simulator than in a payment fraud postmortem.