Почтовые события Битрикс: как проверить шаблон и доставку

Редакция Romanov Lab · Опубликовано 13 октября 2026

Пользователь видит «заявка отправлена», а менеджер не получает письмо. Исправление адреса в шаблоне поможет лишь в одном из возможных случаев. Событие могло не создаться, очередь остаться необработанной, шаблон не подойти к сайту, а почтовый сервер отклонить сообщение. Надёжная проверка идёт по цепочке и не подменяет доставку успешным вызовом функции.

Разберите путь одного уведомления

Тип почтового события описывает назначение и набор полей. Шаблон определяет получателей, тему и содержимое. Конкретное событие связывает действие приложения с данными для письма. Далее сообщение обрабатывается почтовым механизмом и передаётся почтовому транспорту. Настройка входящего ящика в модуле «Почта» сама по себе не настраивает эту цепочку исходящих уведомлений.

Метод CEvent::Send создаёт событие и возвращает его идентификатор; это не подтверждение попадания письма во входящие. Его параметры описаны в официальном справочнике. Для расследования сохраните связь бизнес-операции с событием, время, тип, сайт и ожидаемый шаблон. Личные данные и содержимое обращения в технический журнал без необходимости не включайте.

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

Проверьте выбор шаблона

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

Если идентификатор шаблона не задан, CEvent::Send может использовать несколько подходящих шаблонов. Проверьте это прежде, чем считать два письма повторным вызовом обработчика. Также исследуйте скрытые копии и настройку общего дублирования исходящих сообщений. Один бизнес-факт, одно событие и одно письмо не всегда соответствуют друг другу автоматически.

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

Проверьте поля на неудобных значениях

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

Разработчик должен согласовать обработку пользовательских данных с местом вставки. Значение в HTML-тексте, ссылка и почтовый заголовок требуют разных проверок. Не вставляйте содержимое формы в исполняемый код шаблона и не используйте произвольный пользовательский адрес как доверенного отправителя. Адрес для ответа и адрес отправителя решают разные задачи.

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

Учебный пример: событие есть, письма нет

Представим форму расчёта оборудования. Заявка сохранена, её номер виден в административной части, идентификатор почтового события получен. Начните с состояния обработки этого события. В руководстве по почтовой системе описано поле SUCCESS_EXEC и его значения.

• N: событие ещё не обработано. Исследуйте механизм обработки очереди и его фактический запуск.
• 0: подходящие шаблоны не найдены. Проверьте привязки и параметры события.
• F: отправка не удалась для всех сообщений события. Переходите к ошибкам почтового транспорта.
• P: успешна только часть отправок. Сравните конкретные шаблоны и адресатов.
• Y: обработка считает отправку успешной. Продолжайте проверку на стороне транспорта и ящика.

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

Если очередь не движется

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

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

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

Если отправка успешна, а во входящих пусто

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

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

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

Безопасный тест и критерии готовности

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

1. Каждое контрольное действие сохраняет ожидаемый результат и создаёт нужное событие.
2. Выбираются правильные шаблоны, сайт и получатели, число писем соответствует паспорту.
3. Макросы, ссылки и вложения проверены в фактически полученном сообщении.
4. Остановка обработки видна по возрасту очереди и последнему успешному результату.
5. Повтор после сбоя не вызывает необъяснённого дублирования.
6. Журналы позволяют связать событие с операцией и транспортом без лишних персональных данных.

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