Can't Send, Can't Receive: The Diagnostic Order

Tuesday, 14:10, at Harbourview Clinic. Reception phones the desk and says "Nobody can email anything." Sunita, who has been on the desk for a year, asks who nobody is. "Me and Jo." Two people out of forty-one. Jo's mailbox turns out to be full, which has stopped him receiving and, on this particular mail service, stopped him sending too. The receptionist's message to a patient's family came straight back, because she had typed the address from a handwritten form and one letter was wrong. Twenty minutes went on finding out that "nobody" meant two people with two unrelated faults. The clinic's email had been fine throughout. Sunita wrote one word at the top of her notes afterwards: scope.

A diagnostic order is a fixed sequence of questions that narrows "email is broken" down to one hop and one cause. The questions are asked the same way on every ticket so that the technician never starts fixing before knowing what is wrong. For the two biggest mail complaints, cannot send and cannot receive, the sequence is short: scope, self-test, the bounce, the outbox, the mailbox, the account. This article is part of our Email Problems series, and it is the sequence the other articles assume.

It covers how a message moves in four hand-offs, then the scope question, which is one user, one device, one recipient or everyone. The self-test and the three sends, and reading a bounce in plain words, follow. Next come the stuck outbox, the full mailbox, and the password that changed. What to do when it is everyone, a short war story, and the mail diagnostic card to copy follow, in that order.

How Mail Moves, in Four Hand-offs

A message from one person to another passes through four hand-offs, and a cannot-send or cannot-receive fault lives at exactly one of them. First, the mail client, the program the user writes in, hands the message to the organisation's mail service. That is the system that stores the mailboxes and talks to the outside world. Second, that service works out which service looks after the recipient's address and hands the message over. Third, the recipient's service checks the message, decides whether it is wanted, and puts it in the recipient's mailbox, their store on that service. Fourth, the recipient's client fetches it from the mailbox and shows it. That is the whole journey, and no diagram of the internet is required to follow it.

Each hand-off fails in its own way, and the way it fails is the clue. A failure at the first hand-off leaves the message in the sender's outbox with nothing coming back, because it never reached anything that could reply. A failure at the second or third produces a bounce, an automatic message from whichever service gave up, saying what it could not do and why. A failure at the fourth leaves the message sitting in the mailbox, delivered and unseen, because the client stopped fetching or a rule moved it. So the first thing to establish on any ticket is which of those three symptoms the user actually has. Nothing came back, something came back, or it arrived somewhere they were not looking.

The same four hand-offs run in reverse for receiving, which is why cannot send and cannot receive share a diagnostic order. The difference is who holds the evidence. When the user cannot send, the bounce or the stuck outbox is on their own computer. When they cannot receive, the evidence is on the sender's computer, out of the desk's reach, and the user is describing an absence. Absences are harder to diagnose than failures, and the self-test, below, exists to turn one into the other.

The Scope Question

The first question on every ticket is scope: is this one user on one device, one user on every device, one recipient only, or everyone? Each answer points at a different hand-off and a different fix. The answer is almost never in the ticket as written, because from the user's chair every fault looks like "email". "Nobody can email" meant two people at Harbourview. It has also meant one person, and, less often than the phrasing suggests, everyone.

Establishing scope takes three questions and about two minutes. Does the same mailbox work on another device, or in the browser? Can you send to a colleague inside the organisation, and to an outside address? Is anyone near you having the same problem, and have they tried the same thing? The user can answer all three without the desk touching anything, and the table below shows what each pattern usually means. The last row is the one that changes the ticket into something else entirely.

Scope first, always, because the fix for each row is useless for the others. Resetting a password does nothing for a full mailbox. Raising a quota does nothing for a phone that has the old password. An hour spent on one user's client is an hour the whole organisation waited while the mail service was down. Nobody has ever regretted the two minutes. People have regretted skipping them, usually in writing, usually to a manager.

The Self-Test and the Three Sends

The self-test is the user sending a message to their own address and reporting what happens. It is the single most useful thing a desk can ask for. That is because it exercises all four hand-offs in under a minute without needing anyone outside the building. The message leaves the client, reaches the service, is checked, is put in the mailbox, and is fetched by the same client. If it arrives, the user's sending and receiving both work and the fault is somewhere more specific. If it bounces, the bounce says why, and the usual why is a full mailbox. If nothing happens at all, the client never handed it over, and the outbox section below is next.

After the self-test come the other two sends, and the order matters. A message to a colleague in the same organisation stays inside the mail service, so it tests the mailbox and the client without involving the outside world. A message to an outside address tests the second and third hand-offs. The message goes to a personal address the user owns or a friendly contact who will reply. The test shows whether the organisation's service can hand mail to another service and whether the other service will take it. Ask for a reply to the outside message, because the reply tests receiving from outside. That is the hop that fails when the organisation's address has been blocked somewhere. Three sends, three answers, and the fault is now in one hop.

Write the three results in the ticket in the user's words, with the time. "Self-test arrived 14:22; colleague arrived 14:23; outside bounced 14:25, bounce text below" is a ticket a second technician can pick up without a phone call. "User says email broken" is a ticket that starts again every time someone opens it.

Reading a Bounce in Plain Words

A bounce is a mail service's way of explaining what it could not do. It is the most useful document in the ticket and the least often read. It arrives as a message, usually within minutes, with a subject along the lines of "undeliverable" or "delivery failed". In its body it names the address it tried, the time it gave up, and a reason. The reason is written for people who run mail services, in a sentence or two of jargon followed by a line of codes. The user has usually read the subject, felt the message was shouting at them, and deleted it. Ask for it back. If it has gone, ask the user to send the message again and forward the bounce unopened.

Two things in the bounce matter before the reason: which service sent it, and whether the failure is final. The sending service is named in the bounce, often in the first line or the footer. If it is the organisation's own mail service, the message never left the building, and the fault is at the second hand-off. In that case, the address could not be found or the far service refused the connection. If it is the recipient's service, the message arrived there and was turned away at the third hand-off. Whether the failure is final is in the code. A three-digit number beginning with 5 means the service has given up and will not retry. One beginning with 4 means a temporary problem the service is still retrying. A bounce that says "delayed" or "still trying" is not a failure yet.

The reason itself comes in about six flavours, and the table below translates each into what the desk does next. The wording varies between services and nobody should memorise it; the pattern is enough. Notice that most of the rows end with the fix being somewhere other than the desk. A bounce is frequently the other organisation's problem explained politely in yours.

Paste the reason line into the ticket exactly as written, codes and all. The desk may not need the codes today, but the person who runs the mail service will. So will the technician who gets the same bounce from a different user next week. Three identical bounces from three users in two days is one ticket about the organisation's address, not three tickets about typing. The only way to notice is to have written the bounce down the first time.

The Stuck Outbox

A message that produces no bounce and never arrives has not been sent. It is almost always sitting in the outbox, the client's holding area for messages waiting to leave. The client puts the message there, tries to hand it to the mail service, fails quietly, and tries again later. Some clients show a count beside the outbox; some show the message with a small mark; some show nothing until the user looks. The user, meanwhile, pressed send, watched the window close, and reasonably believes the message is on its way. In a sense it is. It is on its way the way a letter in a coat pocket is on its way.

Four causes account for nearly every stuck outbox, and they are checked in order of speed. The client has no connection. That may be because the network is down, the laptop is on a hotel wireless that wants a sign-in page, or the client has been switched to working offline. The client is not signed in, because the password changed and the prompt was dismissed. This is the commonest, and it is the subject of its own section below. A huge message is at the head of the queue, usually a photograph collection or a recording, and every message behind it waits while it fails. Or the client has simply lost its mind, which is the technical term, and needs to be closed and reopened. Ask the user to send a one-line message to themselves with nothing attached. If it goes, the fault is the big message in front of it, and deleting that one from the outbox releases the rest.

Once the outbox clears, warn the user that the messages in it will all go at once, including the three copies of the thing they tried to send again. It is a small thing to say and it saves a confused reply from a customer who has just received four invoices.

The Full Mailbox

The full mailbox is the commonest single cause of cannot receive, and on many services of cannot send as well. So it is checked on every ticket whether or not the user mentions it. The self-test finds it: a message to yourself that bounces with "over quota" has diagnosed the ticket. The quota is the amount of storage the mailbox may use. The service refuses new messages when it is reached, having usually warned several times beforehand. What else it refuses varies: some services let a full mailbox keep sending for a while, some stop both at once. Check what yours does and write it on the diagnostic card, because the user's symptom will follow that behaviour exactly.

The fix in the moment is to make room, and the fix that lasts is a conversation, both of which are in Mailbox Full, and the Retention Conversation. For the diagnostic order the point is narrower: a full mailbox explains the symptom completely, so once it is found, stop looking for a second cause. A technician who finds the mailbox full and then spends twenty minutes on the phone's settings has diagnosed the ticket and then kept going out of momentum.

The Password That Changed

The password that changed is the commonest cause of one user, one device. The user changed their password on the computer because the directory asked them to. The phone, the tablet, or the second laptop is still trying the old one. The client on that device cannot sign in, so it cannot send or fetch. Depending on how the client was written, it either says so clearly or shows a small warning that nobody reads. Or it sits in silence looking perfectly normal with Friday's mail in it. The first question is "have you changed your password in the last few days?" The answer is yes often enough that it belongs on the card.

The second question is which devices have been given the new password, because every device that has not is a problem waiting to happen in two ways. The obvious one is that the device will not work. The quiet one is that a device trying an old password over and over can lock the account. At that point the user raises a lockout ticket about the computer that works, and the cause is in their pocket. That pairing, and how to find the device doing it, is the subject of The Lockout That Keeps Coming Back. Where the desk ends up resetting the password rather than just re-entering it, the identity check before the reset is in Verifying Identity Before a Reset. Neither of those is repeated here. The mail ticket simply asks the question, and hands over when the answer is yes.

When It Is Everyone

When two people in different departments fail the self-test at the same time, stop diagnosing mailboxes. That is because the fault is in the service or in the connection to it and no amount of work on one user will help. Confirm it with a self-test from the desk's own mailbox, write the time down, and treat the ticket as an incident. The incident lead's roles and routine are in Major Incident Management. What to tell the organisation, by which channel and how often, is in Outage Communication. The mail series has nothing to add to either except the reminder that the announcement cannot go by email.

One kind of everyone fault is worth naming because it looks like many separate tickets. If every message to the outside world is bouncing with a rejected or reputation reason while internal mail works, the organisation's address is being refused by other services. In that case, the cause is often that one account has been sending things it should not. That is a security matter from the first bounce. Hand it to whoever runs the mail service and whoever handles security tickets, together, and let the triage in Phishing Reports and Security Tickets take it from there. The desk's part is to notice that six "cannot send to a customer" tickets in a morning are one ticket, and to say so loudly.

A Short War Story: The Same Bounce Three Times at Redbrook Engineering

Redbrook Engineering's desk took three tickets over two days from three people in sales who could not send to the same large customer. Each ticket was handled on its own. The first technician asked the user to check the spelling. The second suggested the customer's mailbox might be full, and the third, on the second afternoon, asked for the bounce. All three bounces said the same thing: the customer's mail service had rejected the message on policy grounds. The service had been doing so since a mailshot sent from the sales team's shared mailbox the week before had tripped that customer's filter. By the time Omar at the desk put the three tickets together, a quotation with a deadline had missed it by a day and been resent by courier. Three salespeople, two technicians and the account manager had spent something like six hours between them on the fault. The first bounce had explained it in one line. Omar merged the three tickets and wrote the bounce text into the resolution. The account manager phoned the customer's IT department, who had the sender released by the end of the day. The lesson at the top of the desk's notes afterwards was the one this article is built on. Read the bounce before you guess, and three of the same bounce is one ticket.

The Mail Diagnostic Card

The card below is the diagnostic order on one page, filled in on every cannot-send or cannot-receive ticket before anything is changed. Section one is the scope; two is the self-test and the three sends. Three is the bounce, pasted exactly. Four to six are the outbox, the mailbox and the account, in that order. Seven is the outcome, written so the next technician does not start again. Most tickets are resolved by section three and the rest of the card stays blank, which is the point. Keep it in the ticket, not in a separate document, and when the same bounce turns up twice, link the tickets. If you run QuerySolv, linking and merging tickets is ordinary ticket work. In that case, the three Redbrook tickets would have become one with the bounce on it the moment somebody noticed.

MAIL DIAGNOSTIC CARD — ONE TICKET
Ticket: ________   Requester: ______________   Device(s): ______________

1. SCOPE
   [ ] One user, one device         [ ] One user, every device
   [ ] One recipient only           [ ] Everyone: stop, raise an incident
   How confirmed: ______________________________________________

2. SELF-TEST AND THE THREE SENDS
   To own address ........ arrived / bounced / nothing    Time: ______
   To a colleague ........ arrived / bounced / nothing
   To an outside address . arrived / bounced / nothing    Reply received: yes / no

3. THE BOUNCE, pasted exactly
   Sent by: our service / their service
   Reason line: _________________________________________________
   Final, code begins 5 / temporary, code begins 4

4. THE OUTBOX
   Messages waiting: ____   Oldest: ________   Size of the first: ________
   Client signed in: yes / no / prompting     Working offline: yes / no

5. THE MAILBOX
   Quota warning seen: yes / no    Size and quota: ________ / ________
   What this service stops when full: receiving / sending / both
   Rules that move, forward or delete on arrival: none / listed: __________

6. THE ACCOUNT
   Password changed recently: yes / no    Date: ________
   Devices given the new password: ______________________________
   Lockouts in the sign-in history: yes / no

7. OUTCOME
   Category at close: ______________   Cause in one line: _______________________
   Fix: ________________________________   Confirmed by requester: yes / no
   Same bounce seen on another ticket: no / ticket ________ (linked)

The card is deliberately dull, and the dullness is doing work. A technician under pressure at ten past two with reception on the phone does not need to be clever. They need to be told what to ask next, and to have somewhere to write the answer. The clever part happened once, when the order was decided. After that, every cannot-send ticket is the same seven questions, and most of them stop at the third. Sunita's version of the card, at Harbourview, has a line at the bottom in her own handwriting that reads "nobody = ask who". That is the shortest summary of the scope question I have seen.

Frequently Asked Questions