Когда пользователь сообщает о пропавшем письме, начните с одного полного адреса получателя и примерного времени отправки. Широкие перезапуски или повторные тестовые отправки могут скрыть исходные улики и увеличить нагрузку на и без того занятого получателя.
Проследите путь сообщения через систему
- Отправитель: было ли сообщение отправлено, поставлено в очередь или отклонено до доставки по SMTP? Запросите bounce-уведомление или статус доставки, если он доступен.
- DNS: проверьте записи маршрутизации почты для домена получателя и указывают ли они на предполагаемого получателя.
- SMTP: найдите записи о подключении, принятии получателя и финальном ответе.
- Хранилище: подтвердите, есть ли у принятого сообщения индекс и тело, и ожидается ли повторная попытка.
- Отображение: проверьте запрошенный адрес, доступ к сеансу, фильтры и соединение обновления входящих.
Выбирайте улики, которые локализуют неисправность
| Наблюдение | Следующая проверка |
|---|---|
| Нет подключения к получателю | Очередь отправителя и DNS получателя. |
| Временный сбой SMTP | Время повторных попыток и ёмкость получателя. |
| Принято, но не отображается | Статус сохранения и путь чтения входящих. |
| Сохранено и доступно для чтения через API | Сеанс браузера и поведение обновления фронтенда. |
Контролируйте восстановление
По возможности используйте штатный механизм повторных попыток системы. Не запускайте дополнительный цикл повторных попыток без ограничения параллелизма. Сравнивайте возраст очереди и скорость обработки с течением времени; сама по себе длина очереди не позволяет отличить кратковременный всплеск от остановившегося обработчика.
Зафиксируйте причину, действие по восстановлению и любую оставшуюся неопределённость. Не объявляйте сообщение потерянным только потому, что первая попытка сохранения не удалась, и не объявляйте его доставленным лишь потому, что обработчик принял запрос.