Короткий ответ — причин несколько. mail() может вернуть true (MTA принял сообщение), а Bitrix при выполнении «агента отправки событий» вернуть SUCCESS_EXEC = F если внутри обработки события/шаблона/агента произошла ошибка. Ниже — пошаговая инструкция по диагностике и где смотреть логи.
1) Быстрая проверка в БД
- Посмотреть последние неуспешные события:
SELECT * FROM b_event WHERE SUCCESS_EXEC='F' ORDER BY ID DESC LIMIT 50;
Это даст SITE_ID, EVENT_NAME, DATE_EXEC и другие поля — очень часто видно для какого сайта и какого события не удалось отправить письмо.
- Посмотреть связанные шаблоны:
SELECT * FROM b_event_message WHERE EVENT_NAME='имя_события' AND SITE_ID='код_сайта';
Проверьте, есть ли активные шаблоны для того SITE_ID, от имени которого отправляется событие. Частая причина при добавлении второго сайта — шаблон не привязан к новому сайту.
2) Проверить работу агентов (отправку писем делает агент CEvent::Send)
- В админке: «Настройки -> Инструменты -> Агенты» (или /bitrix/admin/agent_list.php) — найти агент отправки событий (CEvent::SendEvents / CEvent::Send) и убедиться, что он выполняется и не падает.
- Если агенты выполняются через системный cron, проверьте cron-задание на сервере (crontab) — запускается ли php-бинарь с битриксовым скриптом.
- В админке можно принудительно выполнить агент (в списке агентов есть кнопка «Выполнить»), после чего сразу смотрите b_event.
3) Логи почтового сервера и очереди
- Почтовые логи MTA (Postfix/Exim):
- Debian/Ubuntu: /var/log/mail.log
- CentOS: /var/log/maillog
- Exim: /var/log/exim_mainlog
В них видно, принял ли MTA сообщение, был ли брошен в очередь, были ли ошибки доставки.
- Просмотреть очередь: postqueue -p или mailq — если там много сообщений или сообщения зависли, причина на уровне MTA.
- Если mail() возвращает true, но сообщения в MTA нет — возможна проблема в конфигурации PHP (sendmail_path) или в chroot/postfix.
4) PHP / веб‑сервер / FPM логи
- PHP‑FPM: /var/log/php*-fpm.log или /var/log/php7.x-fpm.log
- Apache: /var/log/apache2/error.log
- Nginx + php-fpm: /var/log/nginx/error.log и php-fpm логи
В них могут быть фатальные ошибки при выполнении агента или шаблона (исключения, ошибки парсинга шаблона и т.п.).
5) Логи и отладка в Битриксе
- В админке есть раздел «Почтовые события / Шаблоны почтовых сообщений» — можно вручную отправить тестовое сообщение из шаблона и смотреть поведение.
- В b_event (или других таблицах бита) иногда хранится текст ошибки/ответ — посмотрите все поля записи с SUCCESS_EXEC='F'.
- Для временной диагностики можно добавить логирование вызова отправки: в php_interface/init.php повесить обработчик (или временно включить лог в месте, где формируется и отправляется письмо) — записывать результат в файл /tmp/bitrix_mail_debug.log.
6) Частые причины и на что обратить внимание
- Нет активного шаблона для SITE_ID (при добавлении сайта шаблоны надо привязать/клонировать).
- Шаблон содержит код, который вызывает ошибку (php-код в шаблонах) — тогда агент прерывается.
- Агент не выполняется/не имеет времени на выполнение (таймаут php-cli или ограничение по времени).
- MTA принял сообщение, но оно сразу отклоняется внешним сервером — проверяйте mail.log и bounce-сообщения.
- Ограничения хостинга / rate‑limit, блокировка отправки на стороне провайдера.
- Неправильный "FROM" или домен без SPF/DKIM — может приводить к отклонению.
7) Что можно сделать прямо сейчас
- Найти одну запись в b_event с SUCCESS_EXEC='F', посмотреть EVENT_NAME и SITE_ID.
- В админке открыть шаблон для этого EVENT_NAME и SITE_ID, вручную отправить тест — и смотреть одновременно mail.log и php/серверные логи.
- Выполнить агент вручную и сразу смотреть логи (MTA + PHP).
- Если шаблон отсутствует для сайта — скопировать/активировать шаблон для этого сайта.
Если нужно, пришлите:
- Результат SELECT * FROM b_event WHERE SUCCESS_EXEC='F' LIMIT 5;
- EVENT_NAME и SITE_ID одной записи;
- Содержимое соответствующего шаблона (или снимок настроек в админке).
Тогда подскажу более конкретно, в каком месте смотреть и как исправить.