Не отправляется почтовые уведомления с сайта на битрикс

Настроили SMTP-модуль, отправили тестовое письмо — всё работает. Но стоит заполнить форму на сайте, как уведомление не приходит. В журнале — ошибка:

Error: 5.7.0 Sender address rejected: not owned by authorized user

Или ещё страшнее:

[TypeError] Bitrix\Main\Mail\Mail::setHeaders(): Argument #1 ($headers) must be of type array, null given

Или вообще ничего: письмо «ушло», но менеджер его не получил. Знакомая ситуация? В этой статье разберём полный цикл диагностики почты в 1С-Битрикс — от типовых ошибок до скрытых настроек, о которых забывают даже опытные администраторы.

---

Часть 1. Почему письма не уходят: три уровня проблем

Прежде чем что-то чинить, важно понять, на каком уровне произошёл сбой. В Битриксе почтовая система работает как конвейер: событие → шаблон → очередь → служба отправки → SMTP-сервер. Проблема может возникнуть на любом из этапов[reference:0].

Уровень 1. Письмо даже не сформировано

Битрикс физически не пытается отправить письмо. Причины:

• Почтовое событие не привязано к шаблону или шаблон неактивен.
• В шаблоне неверно указан адрес отправителя или получателя.
• Скрипт обработки формы содержит ошибку и не вызывает CEvent::Send().

Уровень 2. Письмо сформировано, но зависло в очереди

Запись о событии создана, но физически не отправлена. Причины:

• Агенты Битрикса не запускаются по cron — очередь не разгребается.
• Очередь переполнена: десятки тысяч неотправленных сообщений.
• В настройках указан неверный адрес отправителя, и функция mail() возвращает false.

Уровень 3. Письмо ушло с сервера, но не дошло до получателя

Сервер отправил письмо, но оно попало в спам, было отклонено принимающим сервером или потерялось. Причины:

• Отсутствуют DNS-записи SPF, DKIM, DMARC.
• Адрес отправителя не совпадает с логином SMTP-авторизации.
• Превышены лимиты почтового сервера.

---

Часть 2. Типовые ошибки и их решения

Ошибка 1. Sender address rejected: not owned by authorized user

Это ответ почтового сервера. Он говорит: «Ты авторизовался под одним ящиком, а в поле From указал другой. Я такое письмо отправлять не буду».

Современные SMTP-серверы (Яндекс, Mail.ru, Gmail) борются с подменой отправителя. Поэтому требуют, чтобы адрес отправителя совпадал с логином авторизации. Если в настройках SMTP-модуля логин noreply@example.com, а в письме From: info@example.com — сервер отклонит отправку[reference:1].

Ошибка 2. TypeError: Argument #1 ($headers) must be of type array, null given

Это ошибка PHP 8. Функция setHeaders() ожидает массив, а получает null. Чаще всего возникает при попытке отправить письмо через командную строку PHP в админке (php_command_line.php). Это не штатный способ тестирования почты. Если ошибка появляется в рабочем коде — скорее всего, виноват устаревший модуль или кастомный код, несовместимый с PHP 8.

Вывод: не тестируйте почту через командную строку PHP. Используйте форму на сайте или встроенный тест SMTP-модуля.

Ошибка 3. Письма уходят в спам

Даже если отправка работает, письма могут не доходить до получателя из-за отсутствия DNS-записей. Без записей SPF, DKIM и DMARC почтовые сервисы считают письмо поддельным и отправляют его в спам[reference:2].

Запись	Назначение
SPF	Указывает, какие серверы имеют право отправлять письма от имени вашего домена
DKIM	Подписывает письма криптографической подписью, подтверждая подлинность
DMARC	Определяет политику обработки писем, не прошедших SPF/DKIM

---

Часть 3. Главная причина: адрес отправителя берётся не оттуда

В 1С-Битрикс адрес отправителя может задаваться в нескольких местах. И они перекрывают друг друга. Вот иерархия:

1. Настройки сайта — высший приоритет для писем с конкретного сайта.
2. Настройки главного модуля — «E-Mail администратора сайта (отправитель по умолчанию)».
3. Настройки SMTP-модуля — адрес авторизации и, возможно, принудительный From.
4. Почтовые шаблоны — поле «От кого» (EMAIL_FROM).
5. Кастомный код — если разработчик прописал адрес вручную.

Чаще всего проблема именно в настройках сайта. Про них забывают, потому что они спрятаны глубже, чем настройки главного модуля. Если вы изменили адрес в главном модуле, но не проверили настройки сайта, старый email продолжит подставляться[reference:3].

---

Часть 4. Пошаговая диагностика

Шаг 1. Проверьте настройки SMTP-модуля

• Убедитесь, что логин и email отправителя в модуле — это один и тот же ящик.
• Если есть опция «Принудительно использовать адрес отправителя из настроек» — включите её.
• Для Яндекс.Почты и Mail.ru может потребоваться пароль приложения, а не обычный пароль.

Шаг 2. Проверьте главный модуль

Перейдите: Настройки → Настройки продукта → Настройки модулей → Главный модуль. В поле «E-Mail администратора сайта (отправитель по умолчанию)» должен стоять тот же адрес, что и логин в SMTP-модуле.

Шаг 3. Проверьте настройки сайта — ключевой момент

Перейдите: Настройки → Настройки продукта → Сайты → Список сайтов. Откройте ваш сайт (обычно s1). Найдите поле «E-Mail адреса по умолчанию» или «Email отправителя». Если там указан старый адрес — замените его на актуальный.

Шаг 4. Проверьте почтовые шаблоны

Перейдите: Настройки → Настройки продукта → Почтовые события → Шаблоны почтовых событий. Найдите шаблоны, которые использует форма (например, FEEDBACK_FORM). В поле «От кого» (EMAIL_FROM) должно быть либо #DEFAULT_EMAIL_FROM#, либо явно прописан правильный адрес[reference:4].

Шаг 5. Проверьте очередь сообщений

Если шаблоны и настройки в порядке, но письма не уходят, проверьте очередь. За отправку писем из очереди в Битриксе отвечают агенты — фоновые задачи, которые модуль main запускает по расписанию через CEvent::Send()[reference:5].

Проверьте таблицу b_event в базе данных. Выполните SQL-запрос:

SELECT ID, EVENT_NAME, DATE_INSERT, SUCCESS_EXECUTE
FROM b_event
WHERE SUCCESS_EXECUTE = 'N'
ORDER BY DATE_INSERT DESC
LIMIT 20;

В поле SUCCESS_EXEC смотрите значение:

• Y — письмо ушло из Битрикса, дальнейшую судьбу отслеживайте у администратора хостинга.
• N — письмо не отправлено. Проверьте, не определены ли константы BX_CRONTAB и BX_CRONTAB_SUPPORT в файле /bitrix/php_interface/dbconn.php. Если да — уберите их определение[reference:6].
• F — функция mail() вернула false. Наиболее типичные проблемы: не настроена mail() на хостинге или почтовый сервер не поддерживает формат письма[reference:7].
• 0 — неверные настройки события или шаблона[reference:8].

Шаг 6. Проверьте cron-задания

Если хостинг не настроил cron на реальный запуск агентов, при низкой посещаемости письма будут копиться часами. Проверьте, есть ли в crontab строка, которая запускает обработку агентов[reference:9]:

*/5 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/php_cli.php /home/bitrix/www/bitrix/modules/main/cron_events.php >> /home/bitrix/logs/cron_events.log 2>&1

Если строки нет — добавьте её через панель хостинга или crontab -e. После этого очередь начнёт разгребаться в течение первых пяти минут[reference:10].

Шаг 7. Очистите кэш

Битрикс агрессивно кэширует настройки. После изменений обязательно очистите кэш: Настройки → Настройки продукта → Автокеширование → Очистка файлов кеша → Все. Если есть доступ к серверу, дополнительно удалите содержимое папки /bitrix/managed_cache/. Иногда кэш, созданный от имени root, не удаляется через админку и продолжает отдавать старые данные[reference:11].

Шаг 8. Проверьте .settings.php

Откройте файл /bitrix/.settings.php. Найдите секцию smtp. Если там есть параметр from или sender со старым адресом — исправьте или закомментируйте.

---

Часть 5. Чек-лист администратора

• SMTP-модуль установлен и включён.
• Логин и email отправителя в модуле совпадают.
• В главном модуле указан правильный «E-Mail администратора сайта».
• В настройках сайта указан тот же адрес (проверить все сайты!).
• В почтовых шаблонах нет старого адреса.
• В шаблоне активна галочка «Активен» и выбран ваш сайт.
• Очередь сообщений не содержит зависших записей с SUCCESS_EXEC = 'N'.
• Cron-задание настроено и выполняется.
• SPF/DKIM/DMARC записи добавлены в DNS.
• Кэш очищен.
• Тест отправки идёт через форму, а не через командную строку PHP.

---

Часть 6. Если ничего не помогло

1. Используйте модуль подмены отправителя. Например, «Fusion: Прозрачная почта» умеет перехватывать письмо и заменять From на разрешённый адрес, сохраняя исходный в Reply-To.
2. Проверьте msmtp на BitrixVM. В настройках главного модуля в поле «Дополнительный параметр для передачи функции mail» можно добавить --read-envelope-from. Тогда msmtp сам выберет аккаунт из .msmtprc по полю From.
3. Включите подробное логирование в SMTP-модуле. В логе будет видно, под каким логином идёт авторизация и какой From передаётся.
4. Проверьте кастомный код. Если сайт дорабатывался сторонними разработчиками, адрес отправителя мог быть прописан в обработчике формы вручную.
5. Обратитесь к администратору хостинга. Если функция mail() отключена или почтовый сервер блокирует отправку, только хостер сможет предоставить логи и исправить ситуацию[reference:12].

---

Итог

Ошибка Sender address rejected: not owned by authorized user — это не баг Битрикса, а строгая политика почтового сервера. Решается она приведением адреса отправителя к логину SMTP-авторизации.

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

Помните: тестировать почту нужно только через форму на сайте или встроенный тест SMTP-модуля. Командная строка PHP — не инструмент для диагностики почты и часто сама становится источником ошибок.

После прохождения этого чек-листа письма с форм будут уходить стабильно, а логи скажут вам «спасибо».