Событие на сайте
Проверяем, что нужное действие действительно создаёт задачу отправки и содержит допустимые From, To, тему и тело.
Контролируемая доставка
Проверяем, создаёт ли сайт сообщение, принимает ли его SMTP, что происходит в очереди и как получатель оценивает домен. Возвращаем уведомления о заявках, заказах, регистрации и восстановлении доступа.
Маршрут сообщения
Доставка состоит из нескольких подтверждаемых этапов. SPF описан RFC 7208, DKIM — RFC 6376, а актуальная спецификация DMARC связывает результаты аутентификации с доменом From. Но DNS-записи помогают только после корректного формирования и приёма сообщения транспортом.
Проверяем, что нужное действие действительно создаёт задачу отправки и содержит допустимые From, To, тему и тело.
Проверяем сервер, порт, шифрование, учётную запись, лимиты и точный ответ транспорта без публикации реквизитов.
Ищем зависшие и повторяющиеся задачи, время следующей попытки, код временной или постоянной ошибки и журнал отправителя.
Сверяем SPF, DKIM, DMARC, домен From, envelope-from и отсутствие конфликтующих или дублирующих записей.
Проверяем SMTP-результат, возврат, спам, карантин, правила ящика и различия между несколькими почтовыми системами.
Добавляем журнал идентификаторов, сигнал об ошибке и резервное уведомление, не подменяя сохранение самой заявки.
Приёмка доставки
Если заявка не создаётся, нужен ремонт формы. Для регулярного контроля ошибок рассмотрите мониторинг сайта.
Идентификатор сообщения, время, адреса отправителя и получателя, результат проверки подписи и текст возврата. Перед передачей скрываем персональные данные и секреты. По заголовкам сверяем путь сообщения с доступными журналами.
Проверяем опубликованные значения и новые контрольные письма после обновления записей. Старое письмо не меняет заголовки задним числом. Отдельно фиксируем состояние транспорта и результат у получателя, включая папку спама.
Согласованное событие создаёт уведомление, транспорт принимает его, а владелец контрольного ящика подтверждает получение. Передаём правила проверки очереди и действий при отказе. Доставку в произвольный чужой ящик без его журналов гарантировать нельзя.
Результат
Сайт передаёт сообщения через проверяемый SMTP-канал.
Адрес отправителя и механизмы аутентификации не противоречат друг другу.
Задержки и отказы фиксируются, а не обнаруживаются по потерянной заявке.
Порядок диагностики
Не начинаем с случайного добавления DNS-записей. Сначала определяем последний подтверждённый этап и только затем исправляем приложение, транспорт, домен или политику приёма.
Используем помеченное сообщение и фиксируем время, получателя и событие.
Связываем журнал приложения, идентификатор очереди и SMTP-код.
Меняем только подтверждённую причину: код, транспорт, DNS или адресацию.
Сравниваем доставку, заголовки, спам и возвраты в разных системах.
Ограничения
Сервер получателя может принять сообщение, а затем применить фильтры. Поэтому отличаем создание, передачу, приём и размещение в ящике и не обещаем результат без журналов и тестов.
Пароли и SMTP-ключи не присылайте сообщением: доступ настраивается через безопасный канал только при необходимости.
Вопросы
Заявка могла сохраниться, а письмо — не создаться, остаться в очереди или быть отфильтрованным.
Они помогают проверить разрешённый источник, подпись и политику домена, но не заменяют исправный SMTP.
Можно, но без управляемого транспорта и журналов доставку сложнее диагностировать. Для важных писем обычно нужен SMTP.
Проверяем очередь, SMTP-ответ, заголовки, спам и возвраты на нескольких почтовых системах.
Первый шаг
Укажите тип уведомления, время теста и домены отправителя и получателя. Определим последний подтверждённый этап и необходимые журналы.