Письма с сайта на Битриксе не приходят: как найти место сбоя

Проверьте, сохранилась ли заявка

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

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

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

Повторите проблему с одной тестовой заявкой

Согласуйте проверку с сотрудником, который получает уведомления. Используйте свои тестовые контакты, а в комментарий добавьте отличимую метку, например MAIL-20261009-01. Если поля комментария нет, запишите время отправки и номер записи, если она создана. На тестовой копии заранее ограничьте получателей. Тест не должен отправлять письма клиентам или запускать рабочую рассылку.

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

В веб-интерфейсе почты найдите метку или тему письма по всем папкам, включая «Спам» и «Корзину». Проверьте фильтры, пересылку и свободное место. Если письмо видно в веб-интерфейсе, но отсутствует в почтовой программе, продолжайте проверку ее синхронизации. Если письма нет и в веб-интерфейсе ящика, передайте разработчику сведения о тесте.

Разработчику: сопоставьте событие и почтовый шаблон

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

Почтовое событие в Битриксе содержит данные для уведомления, а шаблон задает получателей, тему и текст. Вызов CEvent::Send возвращает номер созданного события. Этот номер помогает найти запись, но не подтверждает отправку письма. Свяжите событие с конкретной тестовой заявкой.

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

В разделе «Почтовые шаблоны» найдите шаблон, который использует обработчик. Сверьте активность, привязку к сайту, тип события и язык. Если код явно передает номер шаблона, проверяйте именно его. В полях «Кому» и «От кого» проверьте итоговые адреса после подстановки переменных. Запись #EMAIL_TO# обозначает подстановку значения, а не адрес ящика.

Битрикс: поля и условия выбора почтового шаблона

Проверьте обработку очереди и результат отправки

При отложенной отправке созданное событие ожидает обработки. Проверьте его состояние и время обработки. Если события накапливаются, установите, запускается ли обработка очереди и нет ли ошибок в этом запуске. Если обработку запускает cron (системный планировщик задач), проверьте фактическое выполнение назначенной задачи.

В штатной очереди поле SUCCESS_EXEC обозначает результат обработки. N означает, что событие еще не обработано; F указывает, что ни одно письмо события не отправлено; 0 означает, что подходящий почтовый шаблон не найден. P сообщает о частичном успехе, поэтому нужно проверить отправку по отдельным шаблонам. Y обозначает успешную отправку всех писем события на уровне этого механизма.

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

PHP: что подтверждает успешный результат mail()

Когда нужна проверка SMTP

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

Сверьте сервер, порт, способ защиты соединения, логин и разрешенного отправителя с документацией своего почтового сервиса. В Битриксе локальные SMTP-подключения доступны с версии Главного модуля 21.900.0 и требуют включения соответствующей настройки. Проверьте, что нужное подключение используется именно этим отправителем. Собственная библиотека обработчика может использовать другие параметры.

Для Яндекс 360 с авторизацией по паролю приложения официальный вариант включает smtp.yandex.ru, порт 465 и SSL. Логином служит полный адрес ящика. Сначала разрешите доступ почтовых программ в настройках ящика и создайте отдельный пароль приложения для почты. Эти параметры относятся к Яндексу; для другого сервиса возьмите его настройки.

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

Яндекс 360: разрешение доступа и параметры исходящей почты

Разделите отправителя сайта и адрес посетителя

Поле From задает отправителя письма. Для уведомления используйте адрес, отправку от которого разрешает ваш почтовый сервис. Контакт посетителя передавайте в тексте заявки и, если нужен ответ прямо из письма, в Reply-To. Этот заголовок задает адрес для ответа.

В условном примере From содержит site@example.com, To содержит manager@example.com, а Reply-To содержит visitor@example.net. Сайт отправляет уведомление от своего адреса сотруднику, который отвечает посетителю. Домены example.com и example.net зарезервированы для примеров. Для проверки замените их ящиками, которыми управляете, а для адреса посетителя используйте свой второй тестовый ящик.

Если сервер отправки принял письмо, но почтовый сервис получателя отклоняет его или относит к спаму, проверьте настройки подтверждения отправителя. Запись SPF перечисляет разрешенные источники отправки, а DKIM позволяет проверить подпись письма. Настройки должны учитывать фактический путь отправки. Если уведомление уходит напрямую с сервера сайта, проверьте, включен ли этот источник в SPF и подписывает ли он письмо DKIM.

Проверьте почтовые DNS-записи

Введите домен из адреса отправителя. Для site@webreach.ru это webreach.ru. Инструмент покажет MX, SPF и запись DMARC, опубликованную непосредственно для этого домена.

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

Для проверки DKIM откройте отдельный инструмент по ссылке ниже и укажите селектор. Это имя, по которому ищут ключ подписи. Его можно взять из настроек почтового сервиса или заголовка DKIM-Signature.

Подробная проверка SPF, DMARC и ключа DKIM в инструментах

Найдите ответ почтового сервера или само письмо

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

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

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

Проверьте исправление через исходную форму

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

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