Почему письма с сайта на Битрикс могут не доходить

01

Где обрывается путь письма с сайта

Почта Битрикс — не одна настройка, а цепочка. Посетитель отправляет форму, компонент или обработчик проверяет данные, создаёт почтовое событие, подставляет шаблон и передаёт письмо в функцию отправки. Далее сообщение уходит через настроенный SMTP-сервер либо системный почтовый механизм хостинга. После этого решение принимает сервер получателя: принять, отклонить, поместить в спам или отложить доставку.

Поэтому зелёное уведомление на странице не означает, что менеджер получил заявку. Оно говорит лишь о том, что фронтенд получил ожидаемый ответ. Встречается и обратная ситуация: заявка создана в CRM, а письмо сотруднику не ушло из-за неверного шаблона или адреса. Для маркетинга это риск потери лидов, который не виден в отчётах по конверсии формы.

Начинайте диагностику с конкретной тестовой заявки: зафиксируйте время до минуты, URL страницы, заполненные поля, адрес получателя и идентификатор лида или заказа. Затем сопоставьте эту запись с журналом почтовых событий. В административной части 1С-Битрикс проверьте раздел почтовых событий и шаблонов; описание механизма есть в документации 1С-Битрикс.

Если событие не создалось, проблема до почты: форма, обработчик, обязательные поля, CAPTCHA или кастомный код. Если событие создано, но письмо не ушло, проверяют шаблон, адреса и транспорт. Если отправка отмечена как успешная, а письма нет — анализируют SMTP-лог, SPF/DKIM/DMARC и правила почтового сервера получателя.

03

Первый аудит: событие, шаблон и адреса

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

Проверьте условия применения шаблона: сайт, язык, активность, получатель и подстановку полей. Частая ошибка — в поле «Кому» указан бывший сотрудник, технический ящик с переполненной квотой или переменная, которой нет в массиве данных. Ещё один риск — шаблон берёт email из поля формы, а пользователь оставляет его пустым или вводит адрес с ошибкой.

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

04

Что обычно ломает доставку: карта признаков

У одной и той же жалобы «письма не приходят» причины различаются. Важно отделить проблему генерации письма от проблемы его репутации и маршрутизации. Например, письмо с адреса no-reply@домен-сайта может быть принято локально на хостинге, но отвергнуто внешним сервисом, если домен не разрешает этому серверу отправлять почту.

Отдельно проверьте адрес отправителя. Подстановка email посетителя в поле From выглядит удобно для ответа менеджера, но ухудшает доставляемость: сервер пытается отправить письмо от имени чужого домена. Корректнее использовать корпоративный адрес сайта в From, а адрес посетителя передавать в Reply-To или в тело письма. Если шаблон и код этого не поддерживают, задачу нужно ставить разработчику.

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

05

SMTP и DNS: почему «отправлено» не равно «доставлено»

Системная функция отправки на хостинге часто работает нестабильно: у IP-адреса может быть слабая репутация, отсутствовать корректное обратное DNS-имя или стоять лимит на число сообщений. Для рабочих уведомлений лучше использовать отдельный корпоративный SMTP-ящик или транзакционный сервис, согласованный с ИТ-службой. Доступы к нему не должны храниться в публичном репозитории или в переписке.

SMTP подтверждает принятие письма сервером отправки, но не гарантирует попадание во «Входящие». Получающий сервер сверяет домен отправителя и технические подписи. SPF определяет, какие серверы вправе отправлять почту от домена; DKIM добавляет криптографическую подпись; DMARC задаёт политику, если проверки не прошли. Ошибка в любой из этих записей особенно заметна на массовых почтовых сервисах.

Попросите подрядчика не только «настроить SMTP», но и показать тесты из логов. Для сайта и почты важны разные домены: сайт может работать на example.ru, а отправитель — на mail.example.ru. DNS-записи и подпись должны соответствовать именно тому адресу, который указан в From.

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

06

Как принять исправление без потери реальных лидов

Приемка должна моделировать рабочий путь пользователя, а не ограничиваться кнопкой «Отправить» в административной части. До начала работ назначьте владельца тестовых ящиков и зафиксируйте период, когда изменения можно вносить. Если на сайте высокая нагрузка или запущена рекламная кампания, сначала согласуйте резервный канал: запись заявок в CRM, таблицу или журнал, доступный менеджеру.

Создайте тестовые сценарии: обычная форма, форма с прикреплением файла, заказ, заявка с мобильного устройства и лид с UTM-метками. В каждом сценарии сверяйте данные на всех этапах. Номер телефона может попасть в письмо, но не попасть в CRM; UTM могут обрезаться в шаблоне; Reply-To может работать только в одном типе события.

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

1. 1

   Зафиксируйте контрольный тест. Запишите страницу, время, данные формы и ожидаемых получателей.

2. 2

   Проверьте событие. Сверьте тип, шаблон, адреса и значения переменных в административной части.

3. 3

   Сравните письмо и форму. Убедитесь, что поля, URL и UTM не потерялись при подстановке.

4. 4

   Проверьте CRM. Найдите лид или сделку, ответственного и защиту от дублей.

5. 5

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

07

Что должен видеть маркетолог после настройки

Маркетологу не нужен доступ к паролям SMTP, но нужен понятный контроль результата. Минимум — уведомление о неуспешной отправке, доступ к списку заявок или CRM и правило, кто проверяет инцидент. Если отдел продаж замечает пропавшее обращение через неделю, восстановить источник и причину уже сложно: логи могут быть очищены, а рекламный бюджет потрачен без обратной связи.

Свяжите контроль почты с процессом обработки лида. Определите SLA: за какой срок менеджер отвечает, кто подменяет отсутствующего сотрудника, что происходит с письмами в нерабочее время. Техническая доставка и скорость реакции — разные показатели, но оба влияют на конверсию. Для сложных связок с несколькими формами и CRM полезно вести единый реестр событий.

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

08

Когда проблема требует доработки сайта

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

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

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

09

Вывод: проверяйте не форму, а всю цепочку заявки

Когда письма с сайта не доходят, не стоит сразу менять почтовый ящик или переписывать форму. Сначала установите точку обрыва: создано ли почтовое событие, применился ли шаблон, принял ли сообщение SMTP-сервер и как его обработал получатель. Такой порядок сокращает время диагностики и исключает случайные правки в рабочем сайте.

Для устойчивого процесса разделите ответственность. Маркетинг формулирует, какие формы, поля, получатели и источники должны контролироваться. Продажи подтверждают получение и обработку лида. Разработчик отвечает за событие, шаблон, код и логи, а ИТ-служба — за домен, SMTP и доступы. Результат принимают по тестовым сценариям, а не по словам «у меня письмо пришло».

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