Сайт на Битрикс не отправляет письма: что проверить
Разделяем создание почтового события, фактическую отправку и доставку получателю — это три разных этапа с разными журналами и причинами сбоя.
Фраза «Битрикс не отправляет письма» объединяет три разных сбоя: приложение не создало почтовое событие, сервер не передал сообщение почтовому провайдеру или провайдер принял письмо, но получатель его не увидел. Диагностика начинается с определения этапа, на котором теряется сообщение.
1. Проверьте, создаётся ли почтовое событие
Убедитесь, что обработчик формы завершился успешно и вызвал отправку. Проверьте код типа события, язык и сайт. Если заявка сохраняется в инфоблок или Highload-блок, а почтовое событие не создаётся, проблема находится до SMTP.
2. Проверьте тип и шаблон
В административной части откройте почтовые события и шаблоны. Шаблон должен быть активен, привязан к нужному сайту и содержать существующие поля. Ошибка в адресе получателя или пустой макрос может приводить к корректно созданному, но бесполезному сообщению.
3. Проверьте очередь и агенты
Если события отправляются через очередь, проверьте, выполняются ли агенты или cron, нет ли старых необработанных записей и повторяющихся ошибок. Перезапуск очереди без устранения причины создаёт накопление дублей.
4. Отделите PHP от почтового транспорта
Функция отправки может возвращать управление приложению, но это ещё не подтверждение доставки. Проверьте журнал MTA или SMTP-провайдера. Для production предпочтительнее аутентифицированный SMTP с понятными логами и ограничениями, чем неотслеживаемая локальная передача.
# Примеры диагностических проверок; пути зависят от сервера
tail -n 200 /var/log/mail.log
grep -iE "reject|defer|bounce|error" /var/log/mail.log | tail -n 505. Проверьте SPF, DKIM и DMARC
Если провайдер принял письмо, но оно попадает в спам или отклоняется дальше, проверьте DNS домена отправителя. SPF должен разрешать фактический сервер, DKIM — подтверждать подпись, DMARC — соответствовать выбранной политике. Адрес From не должен имитировать чужой домен.
6. Проверьте содержимое и ограничения
Большие вложения, подозрительные ссылки, неправильная кодировка и превышение лимита провайдера влияют на доставку. Проверьте письмо без вложений и с простым текстом, но не делайте вывод по одному адресу: разные почтовые системы фильтруют сообщения по-разному.
Что должно появиться после исправления
- у заявки есть уникальный ID;
- видно время создания события и результат передачи;
- ошибка транспорта попадает в мониторинг;
- необработанные события имеют retry с ограничением;
- критичная заявка не зависит только от одного email-уведомления.