Ошибка ex_tempfail в Битрикс при отправке почты: где искать причину

Ошибка ex_tempfail всплывает в логах Битрикс каждый раз, когда почта пытается уйти через SMTP и упирается в connection timed out. На практике это одна из самых частых причин, по которой клиенты интернет-магазинов не получают письма с подтверждением заказа, а админка тихо копит очередь из сотен неотправленных уведомлений. Разберу, откуда берётся этот код, как его читать и что чинить в первую очередь.

Что означает ex_tempfail в очереди Битрикс

ex_tempfail это не ошибка самого Битрикса, а код завершения почтового агента операционной системы (sendmail, postfix или exim) с номером 75. Он означает временный сбой на этапе доставки: локальный сервер принял письмо от PHP-скрипта, попытался передать его дальше и не смог, но при этом не считает ситуацию окончательным провалом. Отсюда и логика: письмо остаётся в очереди, Битрикс периодически пытается отправить его снова через встроенный агент, а в журнале событий накапливаются одинаковые записи.

В админке это видно в разделе с очередью почтовых сообщений (в зависимости от версии модуля она называется «Почта» или «Очередь отправки почты» в настройках продукта) и в системном журнале событий. Там же обычно лежит и вторая часть диагноза - строка connection timed out, которая указывает, что проблема именно на этапе TCP-соединения с почтовым сервером, а не в содержимом письма или адресе получателя.

Откуда берётся connection timed out при отправке письма

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

Хостинг блокирует исходящий порт 25, 465 или 587

Самая частая причина на VPS и выделенных серверах. Многие провайдеры по умолчанию режут исходящий трафик на 25 порт, чтобы сервер не превратился в источник спама, если его взломают. Иногда закрыты и 465/587, если провайдер применяет общую политику для всех исходящих SMTP-соединений. Если сайт раньше отправлял письма, а потом резко перестал без изменений в коде и настройках, в первую очередь подозреваю именно смену политики у хостера или переезд на новый сервер.

Неверные или устаревшие настройки SMTP в Битрикс

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

Проблема на стороне принимающего сервера

Greylisting, временная перегрузка удалённого MTA или проблемы с DNS-записями (в первую очередь MX и PTR у собственного сервера) тоже дают временный отказ. В этом случае письма после нескольких попыток чаще всего доставляются сами, если очередь Битрикс не остановлена принудительно и агенты продолжают работать по расписанию.

Как проверить SMTP-соединение вручную за 20 минут

Прежде чем менять настройки, стоит убедиться, где именно рвётся цепочка. Делаю это в три шага прямо с сервера сайта.

Первый шаг - проверка доступности порта:

telnet smtp.yandex.ru 465
# или, если telnet не установлен
openssl s_client -connect smtp.yandex.ru:465

Если соединение подвисает и через 10-15 секунд обрывается по таймауту, порт заблокирован на уровне сети хостинга или файрвола сервера. Если соединение устанавливается мгновенно, дело не в сети, а в настройках самого Битрикс или в учётных данных.

Второй шаг - лог почтового сервера. На большинстве конфигураций это /var/log/maillog или /var/log/mail.log. Там видно, на каком этапе конкретно рвётся передача: на подключении к удалённому хосту, на TLS-хендшейке или уже после авторизации.

Третий шаг для postfix - посмотреть саму очередь:

postqueue -p
mailq | grep -c "^[A-F0-9]"

Если очередь растёт на десятки писем в час, а лог показывает именно connection timed out, а не отказ по авторизации, почти наверняка это сетевая блокировка порта.

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

Встроенный механизм отправки в Битрикс работает через агенты, которые запускаются по крону. Если крон настроен на веб-хук (запуск через wget или curl к agents.php раз в несколько минут), а не через прямой вызов php, разрыв в этой цепочке даёт эффект, похожий на ex_tempfail, хотя причина другая: очередь просто не обрабатывается вовремя. Проверяю это отдельно, потому что чинить порт SMTP бесполезно, если сам агент обработки очереди не запускается уже несколько дней.

Это особенно критично, если на почту завязаны бизнес-процессы: уведомление курьерской службе о готовности отправления, подтверждение оплаты от эквайринга или письмо клиенту с трек-номером после интеграции с СДЭК. Зависшая на сутки очередь означает не просто задержку письма, а разрыв цепочки процесса, который клиент воспринимает как «магазин не подтвердил заказ».

Как чинить: переход на внешний SMTP-релей

Прямая отправка через локальный sendmail на 25 порт исторически ненадёжна: провайдеры блокируют его чаще всего, а репутация IP у хостинг-провайдеров обычно хуже, чем у крупных почтовых сервисов. На практике для Битрикс-проектов почти всегда перехожу на авторизованный внешний SMTP через 465 или 587 порт - у Yandex 360, у почты для бизнеса на mail.ru, либо у транзакционных сервисов вроде SendGrid или Mailgun, если объём писем большой и нужна детальная статистика доставки.

В настройках почты продукта включаю опцию использования внешнего SMTP-сервера, указываю хост, порт с шифрованием TLS/SSL и логин с паролем приложения, а не от личного кабинета. После смены настроек обязательно отправляю тестовое письмо и проверяю лог отдельно, потому что первая успешная отправка через админку не гарантирует, что фоновые агенты подхватят те же параметры без перезапуска очереди.

Если уведомления идут не только из самого Битрикс, а частично собираются во внешнем сценарии (например, обработка заказа дальше уходит в n8n для дополнительных действий - постановка задачи в CRM, отправка в мессенджер), логичнее вынести отправку писем туда же через отдельный SMTP-узел, а не тянуть её через тот же проблемный канал, что и остальная почта сайта. Когда разбираться с логами и агентами самому нет времени, эту диагностику и настройку SMTP-релея под конкретный сервер удобнее отдать на техническое сопровождение сайта, чем откладывать и терять письма неделями.

Профилактика: SPF, DKIM и мониторинг очереди

После смены способа отправки стоит обновить SPF-запись домена, добавив туда IP или include нового почтового провайдера, иначе письма начнут улетать в спам даже при успешной доставке. DKIM-подпись для домена в большинстве случаев выдаёт сам почтовый сервис при подключении, остаётся только прописать TXT-запись в DNS. DMARC добавляю с политикой мониторинга, чтобы видеть, кто и откуда пытается слать письма от имени домена, не блокируя резко всю почту.

Отдельно ставлю простое правило: раз в неделю проверять размер очереди на сервере командой mailq | wc -l или аналогичным отчётом хостинга. Если число стабильно растёт, а не колеблется около нуля, это сигнал разбираться, пока проблема не превратилась в потерянные заказы за месяц.

Частые вопросы

Что конкретно означает код ex_tempfail в логах Битрикс?

Это код завершения локального почтового агента (sendmail, postfix, exim) с номером 75, обозначающий временный сбой при передаче письма дальше по цепочке. Сам Битрикс лишь показывает этот код в журнале событий, оставляя письмо в очереди для повторной попытки.

Почему письма зависают в очереди без явной ошибки в интерфейсе?

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

Как понять, что именно хостинг блокирует порт 25?

Проще всего проверить командой telnet или openssl s_client с указанием нужного порта. Если соединение зависает и обрывается по таймауту через 10-15 секунд без ответа сервера, а на другом порту (465 или 587) то же соединение проходит мгновенно, дело именно в блокировке конкретного порта на уровне сети хостинга.

Полностью ли решает проблему переход с sendmail на внешний SMTP-релей?

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