Настройка исходящей почты в коробочном Битрикс24 через msmtp на Linux

Коробочный портал развёрнут, CRM настроена, сотрудники заведены — а письмо с восстановлением пароля не приходит вообще, уведомление о новой сделке падает в спам, а системные оповещения из бизнес-процессов теряются где-то между сервером и почтовым ящиком клиента. Стандартный sendmail, который есть почти в любом Linux-дистрибутиве, отправляет письма напрямую с IP сервера — и этот IP никому не знаком, у него нет репутации, SPF не настроен. Дальше разберём настройку исходящей почты в коробочном Битрикс24 через msmtp на Linux: лёгкий SMTP-клиент (msmtp — консольная утилита, которая пересылает письма через внешний почтовый сервер вместо прямой отправки) вместо стандартного sendmail. Инструкция для разработчика, который уже поднял коробку и настраивает сервер после установки.

Что понадобится

• Root-доступ или sudo на сервере с развёрнутым коробочным Битрикс24 (BitrixEnv на AlmaLinux/CentOS/Rocky либо ручная установка на Debian/Ubuntu). Если портала ещё нет — сначала разверните его.
• Аккаунт внешней почты с поддержкой SMTP — Яндекс 360 для бизнеса, VK WorkMail, корпоративный Exchange или любой другой сервис. Нужны хост, порт, логин и пароль (для Яндекса — пароль приложения, обычный пароль от аккаунта SMTP не примет).
• Домен, привязанный к порталу, и доступ к его DNS-записям — понадобится на последнем шаге для SPF/DKIM.
• Понимание, под каким системным пользователем работает PHP на вашем сервере (в BitrixEnv это обычно bitrix, на ручной установке — www-data или apache).
• Права перезапускать PHP-FPM или Apache — без перезапуска новый sendmail_path не подхватится.

Почему не sendmail и не встроенный модуль SMTP Битрикса

В Битрикс24 есть свой модуль почтовых очередей — он умеет слать письма клиентам через внешний SMTP напрямую из PHP, без участия системного sendmail. Но часть системных писем — уведомления администратора, письма от cron-скриптов, некоторые события бизнес-процессов — по-прежнему уходит через стандартную функцию PHP mail(), а она всегда обращается к тому, что прописано в sendmail_path. Если там классический sendmail или postfix без внешней настройки, эти письма улетают с IP сервера напрямую — и почтовые провайдеры их либо режут, либо кладут в спам. msmtp решает именно эту дыру: он подменяет собой sendmail на уровне PHP и пересылает всё через уже доверенный внешний SMTP-сервер, с которым у получателя есть история и репутация.

Полноценный Postfix для этой задачи — избыточность. Тут не нужна очередь на диске, ретраи, обработка bounce-писем — просто нужно, чтобы PHP умел отправить письмо через чужой SMTP. msmtp — это одна консольная команда без фонового демона, настраивается одним текстовым файлом.

Шаг 1. Устанавливаем msmtp и настраиваем исходящую почту коробки на Linux

На Debian/Ubuntu:

# msmtp — сам клиент, msmtp-mta — пакет, который кладёт символическую ссылку
# /usr/sbin/sendmail -> msmtp, чтобы PHP и другие программы видели привычный sendmail
apt update
apt install -y msmtp msmtp-mta

На AlmaLinux/Rocky/CentOS (семейство, на котором обычно живёт BitrixEnv) отдельного пакета msmtp-mta нет — нужен репозиторий EPEL, а под него на EL9 обязательно включить CRB (CodeReady Builder, репозиторий с зависимостями для сборки пакетов — часть пакетов EPEL тянет из него зависимости). Символическую ссылку на sendmail тоже придётся сделать руками:

# Включаем CRB — без него часть зависимостей EPEL на EL9 не установится
dnf config-manager --set-enabled crb

# Подключаем EPEL и ставим msmtp
dnf install -y epel-release
dnf install -y msmtp

# Проверяем, куда встал бинарник
which msmtp

# Создаём символическую ссылку на sendmail вручную —
# отдельного пакета msmtp-mta, который сделал бы это сам, на EL9 нет
ln -sf /usr/bin/msmtp /usr/sbin/sendmail

Частая ошибка на этом шаге: ставить msmtp только на своей машине для теста «работает же локально», а на боевом сервере забыть, что там другой дистрибутив — и команда установки не совпадает. Проверяйте пакетный менеджер (dnf/apt) прямо на сервере, а не по памяти.

Шаг 2. Создаём конфиг ~/.msmtprc с данными внешнего SMTP

Конфиг msmtp — простой текстовый файл. Ключевой момент, который упускают чаще всего: PHP на сервере работает не от вашего пользователя, а от системного (bitrix, www-data, apache), и файл ~/.msmtprc должен лежать именно в его домашней директории — или указываться явно флагом -C в sendmail_path (это разберём в шаге 4).

Создаём конфиг от имени системного пользователя PHP (пример для BitrixEnv, пользователь bitrix):

# Переключаемся на пользователя, от которого работает PHP
su - bitrix

# Создаём файл конфига в его домашней директории
nano ~/.msmtprc

Содержимое файла — пример для Яндекс.Почты (SMTP-сервер smtp.yandex.ru, порт 587, STARTTLS):

# Общие параметры для всех аккаунтов ниже
defaults
auth           on
tls            on
tls_starttls   on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile        ~/.msmtp.log

# Аккаунт для отправки писем портала
account        bitrix24
host           smtp.yandex.ru
port           587
from           noreply@ваш-домен.ru
user           noreply@ваш-домен.ru
password       пароль_приложения_яндекс

# Аккаунт, который используется по умолчанию, если msmtp вызван без -a
account default : bitrix24

Если сервер работает на CentOS/AlmaLinux и путь к сертификатам другой — файл сертификатов там обычно /etc/pki/tls/certs/ca-bundle.crt, проверьте перед сохранением командой ls -la по обоим путям, наличие файла разное в зависимости от дистрибутива и его версии.

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

# Права только для владельца — иначе msmtp откажется читать файл с паролем
chmod 600 ~/.msmtprc

Шаг 3. Проверяем отправку из консоли напрямую через msmtp

Прежде чем трогать PHP и Битрикс24, убедитесь, что сам msmtp реально доставляет письма. Это экономит часы, потому что если ошибка в конфиге — её проще увидеть в консоли, чем гадать, почему форма на сайте молчит.

# Отправляем тестовое письмо от имени пользователя bitrix
echo -e "Subject: Тест msmtp\n\nПроверка отправки через внешний SMTP." | msmtp --debug -a bitrix24 ваш-личный-ящик@example.com

Флаг --debug выводит весь диалог с SMTP-сервером — код 235 на этапе авторизации значит, что логин и пароль приняты, письмо ушло дальше. Если видите 535 5.7.8 Authentication failed — почти всегда дело в пароле: для Яндекса обычный пароль от аккаунта тут не подойдёт, нужен пароль приложения из настроек безопасности почты.

Частая ошибка на этом шаге: тестировать под root, а не под тем пользователем, от которого реально работает PHP. Конфиг может стоять и работать у root, а у bitrix или www-data своего ~/.msmtprc не будет вовсе — и на боевом сайте письма всё равно не пойдут.

Шаг 4. Настройка msmtp в php.ini для коробочного Битрикс24

Здесь ключевая точка интеграции — параметр sendmail_path, который указывает PHP, каким бинарником отправлять почту при вызове функции mail().

Находим актуальный php.ini. На BitrixEnv (AlmaLinux) это обычно /etc/php.ini или, если используется несколько версий PHP через модули bitrix, отдельный файл в /etc/opt/php*/php.ini — уточните версию через php -v и php --ini, чтобы не править не тот файл. На Debian/Ubuntu с PHP-FPM — /etc/php/8.x/fpm/php.ini.

# Смотрим, какой именно php.ini реально подключён к текущей версии PHP
php --ini

Правим директиву:

; Заменяем стандартный sendmail на msmtp с явным указанием конфига и аккаунта
; -t — брать получателей из заголовков письма, -i — не считать одинокую точку концом письма
sendmail_path = "/usr/bin/msmtp -C /home/bitrix/.msmtprc -a bitrix24 -t -i"

Флаг -C тут не для галочки: без него msmtp ищет .msmtprc в домашней директории того пользователя, от которого запущен PHP-процесс — а это не всегда очевидно, особенно если PHP работает через PHP-FPM с отдельным системным пользователем пула. Явный путь избавляет от догадок.

Если сервер использует PHP-FPM, у sendmail_path есть более надёжная альтернатива — задать его прямо в конфиге пула, это перекрывает значение из php.ini для конкретного сайта:

; В файле пула, например /etc/php-fpm.d/bitrix.conf
php_admin_value[sendmail_path] = "/usr/bin/msmtp -C /home/bitrix/.msmtprc -a bitrix24 -t -i"

Шаг 5. Перезапускаем PHP и проверяем отправку из формы Битрикс24

Изменения в php.ini не применяются на лету — обязательно перезапустите сервис, который выполняет PHP-код.

# Для связки nginx + PHP-FPM (типично для BitrixEnv)
systemctl restart php-fpm

# Если PHP работает как модуль Apache
systemctl restart httpd    # на CentOS/AlmaLinux
systemctl restart apache2  # на Debian/Ubuntu

Проверка на уровне PHP без привязки к интерфейсу Битрикса — простой скрипт:

# Кладём тестовый скрипт в корень сайта и открываем его в браузере
cat > /home/bitrix/www/mailtest.php << 'EOF'
<?php
$ok = mail('ваш-личный-ящик@example.com', 'Тест из Битрикс24', 'Письмо отправлено через msmtp.');
echo $ok ? 'Функция mail() вернула true' : 'Функция mail() вернула false';
EOF
chown bitrix:bitrix /home/bitrix/www/mailtest.php

Если письмо дошло — идём в саму админку Битрикса и проверяем боевой сценарий: «Настройки» → «Настройки продукта» → «Настройки почты» (или форма обратной связи на публичной части сайта) и смотрим, приходит ли реальное уведомление. После проверки тестовый скрипт mailtest.php обязательно удалите — это открытая дыра, через которую с сервера можно слать письма от чужого имени.

Частая проблема: письма из Битрикс24 попадают в спам без SPF/DKIM

Даже с рабочим msmtp письма могут падать в спам — потому что msmtp решает вопрос доставки до чужого SMTP-сервера, но не решает вопрос доверия к домену отправителя. Если в поле from указан адрес на вашем домене (noreply@ваш-домен.ru), а SMTP-сервер, через который письмо реально уходит, принадлежит другому провайдеру (Яндексу), у получателя возникает нестыковка: домен в письме один, а сервер отправки — чужой. Без SPF-записи (TXT-запись в DNS, которая перечисляет, каким серверам разрешено слать почту от имени домена) почтовые системы Google и Mail.ru воспринимают это как потенциальный спуфинг.

Решение — прописать SPF-запись для вашего домена, разрешающую отправку через сервер Яндекса. Если Яндекс — единственный источник почты для домена, официально рекомендованная запись такая:

v=spf1 redirect=_spf.yandex.net

Запись добавляется как TXT в зоне вашего домена — на имя @ или на сам домен, в зависимости от панели хостера.

Если с домена уже отправляется почта через другие сервисы (например, тот же Битрикс24 отправляет часть писем напрямую через встроенный модуль SMTP или у вас есть другой почтовый сервер) — redirect перезапишет всю логику SPF, и нужно перечислить источники через include:

v=spf1 include:_spf.yandex.net ~all

Это вариант для случая, когда с домена отправляет почту не один сервис.

DKIM (цифровая подпись письма, которая подтверждает, что оно не менялось по пути и действительно отправлено владельцем домена) в этой схеме настраивается на стороне почтового провайдера — в личном кабинете Яндекс 360 для домена есть отдельный раздел с DKIM-записью, которую нужно добавить в DNS. Без этого письма продолжат периодически улетать в спам даже при рабочем SPF — у крупных провайдеров DKIM всё чаще обязателен, а не желателен.

После добавления записей подождите обновления DNS (от нескольких минут до суток, зависит от TTL) и проверьте результат сервисом вроде mail-tester.com — он присылает оценку письма и явно указывает, какая из проверок (SPF, DKIM, DMARC) не пройдена.

Частые ошибки и как их избежать

Права на ~/.msmtprc остались 644. msmtp отказывается читать конфиг с паролем, если он доступен на чтение не только владельцу — вы получите ошибку вида «Permission denied» или предупреждение о небезопасных правах, письмо не уйдёт. Проверяется одной командой: chmod 600 ~/.msmtprc.

Конфиг лежит в домашней директории не того пользователя. Вы тестировали под root, всё сработало, а на сайте письма не идут — потому что PHP работает от bitrix или www-data, и у этого пользователя своего .msmtprc попросту нет. Либо кладите конфиг в его домашнюю папку с правильным владельцем (chown bitrix:bitrix ~bitrix/.msmtprc), либо указывайте путь явно флагом -C в sendmail_path.

На Ubuntu/Debian msmtp внезапно перестаёт работать после обновления системы, при рабочем конфиге. Причина — AppArmor: у пакета msmtp есть профиль безопасности, который иногда слишком строго ограничивает доступ к файлам после апдейта. Проверяется командой aa-status — если msmtp в списке ограниченных профилей и письма перестали уходить, профиль можно временно перевести в режим complain: aa-complain /usr/bin/msmtp.

Забыли перезапустить PHP-FPM после правки php.ini. Изменения сохранились, но процесс PHP их не подхватил, потому что читает конфиг только при старте. Симптом — тестовый скрипт продолжает пытаться слать через старый sendmail и падает с ошибкой «No such file or directory». Лечится перезапуском сервиса, а не повторной правкой конфига.

Из практики А2

На одном из проектов после переезда клиента на коробочную версию форма обратной связи на сайте отправляла письма исправно, а вот системные уведомления Битрикса о новых задачах и комментариях — нет. Разбирались минут сорок, пока не выяснили: sendmail_path был прописан в основном php.ini, а сайт публичной части и админка работали через разные пулы PHP-FPM, и у второго пула был отдельный php_admin_value, переопределяющий значение на дефолтный sendmail -t -i без всякого msmtp. Тот самый случай, когда правишь один файл, а реально их два.

Второй момент, который встречается регулярно — клиенты настраивают msmtp через личный ящик на Gmail или Яндексе (не корпоративный домен), рассчитывая на быстрый тест, и потом забывают заменить на боевой адрес. Письма формально уходят, но получатели видят отправителя вида ivan.petrov@gmail.com вместо info@company.ru, что для B2B-переписки выглядит странно и часто настораживает получателя больше, чем попадание в спам.

И третье: для порталов с большим объёмом уведомлений (десятки писем в минуту при активной работе в CRM) стоит закладывать лимиты внешнего почтового сервиса заранее. У большинства провайдеров есть суточный лимит на исходящие письма с одного аккаунта, и при активном использовании бизнес-процессов с email-уведомлениями коробка способна упереться в этот лимит быстрее, чем кажется на старте — тогда часть писем просто не уходит, без явной ошибки в логах Битрикса, только в логе самого msmtp.

Итог

После этой настройки вся почта из коробки — от формы на сайте до системных уведомлений через mail() — уходит не напрямую с IP сервера, а через внешний авторизованный SMTP с рабочими SPF и DKIM. Это не гарантирует нулевой процент попаданий в спам (у почтовых провайдеров хватает своих алгоритмов), но убирает самую частую причину проблем на коробочных установках. Если на каком-то шаге застряли или msmtp упорно не хочет авторизовываться — опишите ситуацию в комментарии или напишите нам напрямую.