Some tickets are easy because the symptom names the cause. “The printer is jammed” needs no detective work. “I have stopped getting email” is the opposite: one flat sentence covering at least eight unrelated failures, several of which are invisible from the user’s side and one of which is a security incident.
Worse, the user’s own account of it is honestly unhelpful. Everyone says the same thing, whether their mailbox is full or an attacker is quietly forwarding their mail elsewhere. So you cannot triage this ticket by asking better questions. You triage it by asking the server.
Start with the trace, always
Run a message trace on the mailbox before touching anything. It costs a minute and it splits the eight causes into two piles.
If the trace shows messages arriving and being delivered, the mail platform is doing its job and the problem is between the mailbox and the user. If the trace shows failures, holds, queuing, or nothing at all, the problem is on the platform side and there is no reason to go anywhere near the user’s laptop.
Getting this order wrong is how techs burn an hour rebuilding a mail profile for a mailbox that was over quota the whole time. The rebuild even looks like it worked for about a day, which is the worst possible outcome, because now everyone believes a wrong theory.
The server side causes
A full mailbox is the most common and the most quietly frustrating, because the sender gets a bounce and the recipient gets silence. The user experiences a mailbox that stopped, and nobody tells them why. The trace shows the quota rejection outright.
A disabled mailbox produces a similar silence with a different reason attached, and it usually has a story behind it: an offboarding process that ran on the wrong person, a licensing change, an account action nobody linked to mail.
A queue backlog looks different again. Messages are not rejected, they are waiting, and the trace shows temporary status rather than failure. There is nothing to fix on this user’s account, and the correct handling is to say so plainly, note the backlog, and resist the urge to make a change so the ticket feels worked. Changing settings during a backlog is how you get blamed for the recovery.
Filtering is the fourth. Messages accepted and then held in quarantine never reach the mailbox, and neither does mail from a sender who ended up on a block list. Both are fixable in about ten seconds once you have looked, and both are impossible to guess at from the user’s description.
The user side causes
If mail is being delivered, the remaining suspects are all in the last few feet.
Inbox rules are the classic. Users build them during a busy week years ago and forget completely, and a rule that files anything from a domain into a subfolder is indistinguishable from mail not arriving. Nobody scrolls to a folder they do not remember creating. Reviewing the rule list is faster than any other check on this side, so it goes first.
A broken client is next: signed in, apparently fine, not actually syncing. Web access is the fastest way to prove it, because if the mail is visible in a browser then the mailbox is healthy and the client is the patient. That single comparison saves more time on Outlook tickets than any repair tool.
The eighth cause is not an email problem
There is one pattern that ends the troubleshooting and starts something else. Mail is arriving, delivery looks perfect, and a rule the user did not create is forwarding it to an outside address, or deleting it, or both. That is not a mail configuration issue. That is a compromised account, and the forwarding rule is how an attacker keeps reading someone’s mail after the password is changed.
The instinct here is to delete the rule and close the ticket with a clean conscience. Resist it. Turning off the rule fixes what you can see and destroys nothing that the attacker still has, which is the mailbox itself, whatever they already read, and whoever they have been emailing as this user. Payment redirection fraud lives in exactly this gap. The correct move is to secure the account and escalate to whoever owns security, with the rule left as evidence and every detail written down.
Knowing which tickets stop being yours is a real skill, and it is the same one that shows up in tier boundaries everywhere else on the desk.
Practicing a ticket that lies to you
This is a genuinely hard ticket to learn on the job, because the eight causes do not arrive evenly and the dangerous one is rare. ServiceDesk Simulator runs the mail ticket with a hidden root cause drawn from the same list, and the user’s wording is deliberately written to give none of it away. You trace, you look at the mailbox, you check the rules, and you decide. Occasionally the answer is that this stopped being an email ticket three steps ago, and noticing that is worth more than any fix on the list.