When a user reports missing mail, begin with one complete recipient address and an approximate sending time. Broad restarts or repeated test sends can hide the original evidence and add load to an already busy receiver.
Follow the message through the system
- Sender: Was the message submitted, queued or rejected before SMTP delivery? Ask for a bounce or delivery status if available.
- DNS: Check the recipient domain's mail-routing records and whether they point to the intended receiver.
- SMTP: Look for connection, recipient-acceptance and final-response records.
- Storage: Confirm whether the accepted message has an index and body, and whether a retry is pending.
- Display: Check the requested address, session access, filters and inbox update connection.
Choose evidence that narrows the fault
| Observation | Next check |
|---|---|
| No receiver connection | Sender queue and recipient DNS. |
| Temporary SMTP failure | Retry timing and receiver capacity. |
| Accepted but not visible | Persistence status and the inbox read path. |
| Stored and readable through the API | Browser session and frontend update behavior. |
Keep recovery controlled
Use the system's normal retry mechanism where possible. Avoid launching an additional retry loop without a concurrency limit. Compare queue age and completion rate over time; a queue length alone cannot distinguish a short burst from a stalled worker.
Record the cause, recovery action and any remaining uncertainty. Do not declare a message lost merely because the first storage attempt failed, or declare it delivered solely because a worker accepted the request.