Контролируемая доставка

Не приходят письма с сайта

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

Маршрут сообщения

Где пропадает
письмо

Доставка состоит из нескольких подтверждаемых этапов. SPF описан RFC 7208, DKIM — RFC 6376, а актуальная спецификация DMARC связывает результаты аутентификации с доменом From. Но DNS-записи помогают только после корректного формирования и приёма сообщения транспортом.

01

Событие на сайте

Проверяем, что нужное действие действительно создаёт задачу отправки и содержит допустимые From, To, тему и тело.

02

SMTP-подключение

Проверяем сервер, порт, шифрование, учётную запись, лимиты и точный ответ транспорта без публикации реквизитов.

03

Очередь

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

04

Домен и DNS

Сверяем SPF, DKIM, DMARC, домен From, envelope-from и отсутствие конфликтующих или дублирующих записей.

05

Получатель

Проверяем SMTP-результат, возврат, спам, карантин, правила ящика и различия между несколькими почтовыми системами.

06

Контроль доставки

Добавляем журнал идентификаторов, сигнал об ошибке и резервное уведомление, не подменяя сохранение самой заявки.

Проверка уведомлений

Отделяем сохранение заявки от доставки письма

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

01

Разные типы писем

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

02

Адрес посетителя

Проверяем, куда сайт записывает введённый email. Для отправителя используем согласованный адрес домена сайта, а адрес клиента при необходимости передаём как Reply-To. Подстановка чужого домена в From усложняет проверку подлинности сообщения.

03

Доставка части получателей

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

04

Повтор из очереди

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

Приёмка доставки

Проверяем маршрут контрольного письма

Если заявка не создаётся, нужен ремонт формы. Для регулярного контроля ошибок рассмотрите мониторинг сайта.

Какие сведения нужны из письма?

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

Как проверяем изменение DNS?

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

Что считается результатом работы?

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

Результат

Для каждого письма известен статус

Настроенный транспорт

Сайт передаёт сообщения через проверяемый SMTP-канал.

Согласованный домен

Адрес отправителя и механизмы аутентификации не противоречат друг другу.

Наблюдаемая очередь

Задержки и отказы фиксируются, а не обнаруживаются по потерянной заявке.

Порядок диагностики

От факта создания до ответа получателя

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

01

Создаём тест

Используем помеченное сообщение и фиксируем время, получателя и событие.

02

Читаем ответы

Связываем журнал приложения, идентификатор очереди и SMTP-код.

03

Исправляем слой

Меняем только подтверждённую причину: код, транспорт, DNS или адресацию.

04

Проверяем несколько ящиков

Сравниваем доставку, заголовки, спам и возвраты в разных системах.

Ограничения

Принято SMTP не всегда значит доставлено во «Входящие»

Сервер получателя может принять сообщение, а затем применить фильтры. Поэтому отличаем создание, передачу, приём и размещение в ящике и не обещаем результат без журналов и тестов.

Для диагностики подготовьте

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

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

Вопросы

Перед настройкой

Почему успех формы не гарантирует письмо?

Заявка могла сохраниться, а письмо — не создаться, остаться в очереди или быть отфильтрованным.

Зачем SPF, DKIM и DMARC?

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

Можно использовать PHP mail?

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

Как проходит контрольный тест?

Проверяем очередь, SMTP-ответ, заголовки, спам и возвраты на нескольких почтовых системах.

Первый шаг

Опишите пропавшее письмо

Укажите тип уведомления, время теста и домены отправителя и получателя. Определим последний подтверждённый этап и необходимые журналы.