Сообщение «письмо не пришло» описывает результат, но не место поломки. Сначала выясните, сохранилось ли само обращение. Затем проверьте создание почтового события, его обработку, передачу почтовому сервису и доставку получателю. Такой порядок помогает не потерять заявки и не менять рабочие DNS-записи наугад. По итогам у вас будет один прослеженный пример и точная задача для специалиста.
Сначала отделите заявку от уведомления
Откройте место хранения обращений: форму CMS, CRM или журнал приложения, предусмотренный вашей реализацией. Отсутствие письма не означает отсутствие записи. И наоборот, красивое сообщение об успешной отправке не доказывает, что обращение сохранилось. Если форма существует только ради письма, стоит отдельно обсудить надёжное сохранение заявок до отправки уведомления.
Сделайте одну учебную отправку с заметной меткой, например «Проверка доставки demo-mail-42». Используйте собственный тестовый контакт и обычный короткий текст без вложений. Запишите время с часовым поясом, адрес страницы, код формы, ожидаемого получателя и результат на экране. Не нажимайте кнопку десятки раз: это создаст шум и может запустить защиту от частых отправок.
Если обращения не сохраняются, исследовать SMTP пока рано. Нужно проверить обработчик формы, обязательные поля, ответ сервера и журнал приложения за нужное время. Почтовая настройка не восстановит заявку, которая не была принята. Для безопасности диагностику ограничивают учебным примером и чтением журналов, а не отключением защиты публичной формы.
Как устроен маршрут письма
| Этап | Что требуется увидеть | Кому передать сбой |
|---|---|---|
| Форма и запись | Сохранённое обращение | Разработчику сайта |
| Событие и шаблон | Получатель и обработка | Администратору CMS |
| Почтовая передача | Ответ сервиса | Хостингу или почтовику |
| Ящик получателя | Письмо или отказ | Администратору почты |
На типовом сайте Битрикс почтовое событие связывается с шаблоном, который определяет адреса и содержимое письма. Но конкретная форма может отправлять сообщения через собственный модуль или внешний API. Сначала выясните реализацию. Отсутствие записи в стандартной очереди не является ошибкой, если эта форма её вообще не использует.
В запросе к специалисту полезно прямо написать: «Проверьте маршрут учебного обращения demo-mail-42 и укажите последний успешно завершённый этап». Это лучше просьбы «переустановить почту». По одному конкретному событию можно сопоставить журналы нескольких систем без раскрытия всей клиентской переписки.
Шаг 1. Проверьте шаблон и адрес получателя
В административной части найдите используемые тип события и почтовый шаблон. Названия разделов и доступ зависят от версии и роли. Проверьте активность шаблона, привязку к нужному сайту, поле получателя и наличие всех переменных. Шаблон может выглядеть верно, но подставлять пустой адрес или старую почту из настроек компонента.
Проверяйте значение после подстановки, а не только текст вида «#EMAIL_TO#». Если сайт многосайтовый, убедитесь, что берётся нужная привязка и отправитель. Если уведомления должны получать два сотрудника, испытайте предусмотренный формат списка, не меняя его наугад. Старый рабочий шаблон перед редактированием сохраните в приватную резервную копию.
В поле From используйте адрес разрешённого отправляющего домена и сервиса. Адрес посетителя обычно уместнее передавать в Reply-To, если реализация поддерживает это поле. Подмена отправителя адресом клиента, например чужим Gmail, может нарушить проверки почтового домена. Не исправляйте это отключением проверки сертификатов или защитных механизмов.
Шаг 2. Посмотрите состояние почтового события
Для стандартного механизма Битрикс официальная документация почтовых событий описывает поле SUCCESS_EXEC. Значения: N — событие ещё не обработано; 0 — подходящие шаблоны не найдены; F — отправка по всем шаблонам не удалась; P — частичный успех; Y — успешная отправка по шаблонам на уровне механизма системы. Это не подтверждение появления письма во «Входящих».
Попросите специалиста прочитать статус конкретного события и время его обработки. Не нужно выгружать всю таблицу с письмами и персональными данными. Достаточно идентификатора, кода события, привязки к сайту и результата. Внешний модуль может иметь собственные статусы — тогда используется его документация, а не приведённая расшифровка.
Если очередь не обрабатывается, проверьте фактический механизм запуска фоновых задач на этой установке. Он может зависеть от конфигурации сайта и расписания. Нельзя автоматически переносить совет для другого хостинга. Штатный метод CEvent::CheckEvents обрабатывает неотправленные события, но ручной запуск всей накопленной очереди без разбора способен разослать старые сообщения.
Шаг 3. Проверьте передачу почтовому сервису
Если событие обработано, найдите ответ отправляющего сервиса за то же время. Возможны отказ авторизации, ограничение отправки, неверный адрес, недоступность сервера или ошибка защищённого соединения. Запишите краткий код и текст ошибки без пароля, токена и полного тела письма.
Для SMTP уточните хост, порт, способ защищённого подключения, логин отправителя и разрешённый адрес From по инструкции вашего провайдера. Не угадывайте порт перебором и не используйте случайные настройки из старой статьи. Если пароль менялся, проверьте, в каком месте хранится действующее значение: у модуля, сервера или внешнего сервиса могут быть разные настройки.
Попросите хостинг подтвердить факт принятия сообщения и дальнейший результат: идентификатор в очереди, ответ следующего сервера, отложенную доставку или отказ. Слово «отправлено» без идентификатора и времени слишком неоднозначно. При этом успешное принятие сервером адресата всё ещё не гарантирует папку «Входящие»: письмо может быть отфильтровано дальше.
Шаг 4. Проверьте ящик и аутентификацию домена
Посмотрите «Спам», правила пересылки, фильтры, карантин корпоративной почты и уведомления о недоставке. Проверьте, не переполнен ли ящик и не заблокирован ли отправитель. Затем отправьте по одному учебному письму на два контролируемых адреса разных провайдеров. Разница результатов поможет отделить общий сбой отправки от проблемы конкретного получателя.
Для домена отправителя важны почтовые проверки SPF, DKIM и DMARC. Требования зависят от получателя и характера отправки. Например, руководство Gmail для отправителей требует аутентификацию SPF или DKIM и TLS для всех отправителей в личные ящики Gmail; для массовых отправителей требования строже. Это правила Gmail, а не универсальное обещание доставки во все почтовые системы.
Проверять нужно фактическое письмо и используемый маршрут. Если сообщения отправляет внешний сервис, DNS должен соответствовать его инструкции. Не создавайте вторую независимую SPF-запись и не заменяйте существующую запись без учёта остальных отправителей. Сначала сохраните текущую конфигурацию и список сервисов, затем согласуйте изменение с ответственным за домен.
MX отвечает за приём почты доменом, а не сам по себе за право сайта отправлять письма. Поэтому перенос входящей почты на другой сервис может вообще не устранить исходящую проблему. Сначала ищите подтверждение конкретной причины. Диагностические заголовки письма полезны, но перед передачей уберите адреса и служебные данные, которые не нужны для разбора.
Учебный пример: событие успешное, письма нет
Предположим, обращение demo-mail-42 сохранилось в CMS, событие имеет статус Y, а сотрудник не видит уведомление. Проверка показывает, что шаблон отправляет письмо на старый адрес отдела, который ещё принимает сообщения. Это учебная ситуация, а не статистика клиентов SignM.
Переустановка почтового модуля здесь не нужна. Сначала исправляют получателя в нужном источнике настройки, сохраняют предыдущую версию и выполняют одну новую проверку. Затем смотрят не только письмо, но и запись обращения. Старые заявки из периода ошибки передают сотруднику по согласованному списку, не запуская повторную рассылку всех событий сайта.
Другой возможный результат той же диагностики — адрес правильный, письмо принято сервером и попало в карантин. Тогда исправляется причина фильтрации с почтовым администратором. Повторная правка шаблона на сайте без данных о фильтре только усложнит расследование. Один симптом может требовать действий на разных этапах маршрута.
Восстановление работы без потери и повторов
Определите интервал сбоя и список сохранённых обращений, по которым нет подтверждённой реакции менеджера. Письма — вспомогательный канал; основа сверки — сами обращения. Для каждого отметьте, есть ли запись в CRM, кто её получил и требуется ли повторное уведомление. Не отправляйте клиенту несколько одинаковых подтверждений только потому, что менеджер не получил своё.
Перед повторной обработкой очереди выясните её состав: там могут быть старые регистрации, восстановление доступа и другие события. Повтор должен затрагивать только согласованные записи. Истёкшие ссылки восстановления пароля не стоит рассылать повторно; при необходимости запускается предусмотренный процесс получения новой ссылки владельцем аккаунта.
Если изменение ухудшило ситуацию, верните сохранённую конфигурацию конкретного компонента и зафиксируйте результат. Не восстанавливайте всю базу сайта ради одного почтового шаблона: это несоразмерная операция с риском потери новых данных. Для изменения DNS учитывайте время распространения и проверяйте результат до следующей правки.
Как принять исправление и что передать поддержке
- Одна новая учебная заявка сохраняется и имеет идентификатор.
- Письмо получает правильный сотрудник; тема и содержимое позволяют найти обращение.
- Адрес для ответа ведёт к предусмотренному получателю, а не к случайному техническому ящику.
- Нет дублей после повторной обработки одного события.
- Проверена доставка в согласованные тестовые ящики и состояние очереди.
- Определены ответственный и способ заметить следующую задержку.
В поддержку отправьте домен, URL формы, время, учебную метку, ожидаемый адрес в замаскированном виде, найденный статус и код ошибки. Не отправляйте пароль SMTP или полный экспорт очереди. Уточните, какое изменение уже выполнялось: несколько одновременных попыток разных специалистов способны скрыть исходную причину.
SMTP — протокол передачи почты; From — заявленный отправитель; Reply-To — адрес для ответа; bounce — сообщение о недоставке; SPF/DKIM/DMARC — механизмы проверки отправителя и политики домена. Новый сервер, тариф или почтовый модуль стоит выбирать только после выявленного ограничения. Заполненная таблица маршрута поможет решить проблему самостоятельно или передать её в поддержку сайта без повторного сбора фактов.
Применить к своей задаче
Проследить одну учебную отправку, локализовать сбой формы, очереди, почтового сервиса или ящика и подготовить точное обращение в поддержку без передачи секретов.
Маршрут проверки письма с сайта: открыть рабочий материал · Скачать CSV для заполнения. Доступ свободный, без регистрации. Можно использовать самостоятельно или передать своему исполнителю.