Письма с сайта перестали приходить: проверяют создание сообщения, очередь и ответ почтового сервиса

Начните с конкретного события. Для подтверждения заказа это номер контрольного заказа; для входа это контрольный запрос ссылки. По нему инженер ищет письмо на каждом этапе.

Страница «Спасибо» не показывает, создалось ли сообщение. Если письмо не сформировано, смена почтового сервиса ничего не починит: ему нечего отправлять.

Подтверждение заказа и ссылка входа относятся к транзакционным письмам: их вызывает действие клиента. Продажи через маркетинговую рассылку требуют другой задачи.

Сохранённое событие помогает поддержке при сбое отправки. По нему отличают потерянное уведомление от заказа, которого нет в системе, без повторной оплаты.

Созданное письмо может ждать. Если сайт отправляет через очередь, запись задания ещё не означает, что обработчик взял его в работу. Нужен след попытки и её исход.

Проверяют возраст ожидающих писем и последнее выполнение обработчика. Пустой журнал ошибок не успокаивает, если процесс не запускался и не мог записать ошибку.

При обрыве связи исход отправки бывает неизвестен. Сервис мог принять письмо, а сайт не дождался ответа; слепой повтор способен отправить клиенту дубль.

Повтор связывают с тем же событием и проверяют защиту от дублей. Её условия зависят от сервиса; для старого заказа одного повторного запроса недостаточно.

«Запрос принят» означает начало доставки. В документации Resend событие sent относится к успешному запросу API. Сервис после этого пытается доставить письмо серверу получателя.

Отказ и задержку разбирают по-разному. Неверный адрес не исправляется повторением того же письма, а временный сбой требует ожидания по правилам сервиса.

Исход сверяют по номеру отправки, времени попытки и причине отказа. Текст письма и секретную ссылку для входа в отчёт не копируют.

Событие delivered подтверждает принятие сервером получателя. Оно не сообщает, в какой папке лежит письмо, и не доказывает, что клиент открыл ссылку.

Проверяют обычный путь клиента. Контрольный заказ запускает штатное письмо. Кнопка «Тест SMTP» пропускает создание сообщения и очередь.

Если сообщение есть в спаме, отправка уже состоялась. Теперь проверяют подлинность отправителя, содержимое письма и правила ящика, вместо повторной отправки той же пачки.

SPF, DKIM и DMARC проверяют отправителя и подлинность письма. Google описывает их в требованиях к отправке, но прохождение проверок не гарантирует папку «Входящие».

Контрольный ящик доказывает доставку в этот ящик в момент проверки. Для разных почтовых сервисов нужны отдельные контрольные адреса; отсутствие жалоб не заменяет проверку.

Инженер ведёт открытую машину проекта vibecoding.ru. Клиентского кейса ремонта недоставки писем у нас нет; наш пример относится к новостной ленте.

В ней отметка прогресса двигалась при упавших вызовах, а причина не попадала в нужный журнал. Обработанное задание скрывало неготовый результат.

Для почтовой очереди берём правило из этой истории: ошибка не превращается в успех, причина видна, результат проверяется отдельно.

В уроке «Руль, окно и сторож» курса агентной разработки тот же порядок: записанное правило, видимый ход работы и проверка, которая зовёт ответственного при сбое.

Инженер сначала определяет границы работы. Проверяемая задача для агента описывает событие, ожидаемое письмо и свидетельство успеха. «Починить SMTP» заранее назначает виновника.

Агентам поручают найти место создания письма и подготовить исправление с тестами. Инженер принимает диагноз и проверяет, что отправка не меняет заказ или права доступа.

Для разработки хватает контрольных адресов и обезличенных событий. Данные клиентов агенту не нужны; доступ к боевому ящику отдельно решает инженер.

До работы назначают того, кто проверяет выпуск и разбирает накопленные письма. Ответственность за поломку не исчезает от того, что правку подготовил агент.

Приёмка повторяет сценарий диагностики. Создают контрольное событие и сверяют его следы. Письмо в ящике закрывает этот проход, но не проверку будущих отказов.

Проверку отказа проводят отдельно в тестовой среде. Когда сервис недоступен, сайт не должен записывать ложный успех; ответственный должен увидеть причину и незавершённые задания.

Для старого заказа сверяют текущее состояние перед повторным письмом. Просроченную ссылку входа не воспроизводят: создают действующую по правилам входа.

Контроль запускают регулярно и после правок отправки. Задают срок ожидания и получателя сигнала, затем проверяют оповещение: молчащий сторож не помогает клиенту.

Если нужен инженер для ремонта, можно обсудить отправку писем.

Для постоянной очереди правок есть разработка по подписке: «Один проект», 250 000 ₽ в месяц, по странице услуг на 8 октября 2026.