SMTP в 1С: настройка почтового сервера для отправки писем

Когда из 1С нужно отправлять счета, уведомления об оплате, напоминания или другие письма клиентам, недостаточно сформировать текст сообщения. Система должна передать подготовленное письмо почтовому серверу, который отвечает за его дальнейшую отправку. Для этого используется SMTP.

Поэтому настройка SMTP в 1С — это не настройка самого текста письма и не настройка бизнес-сценария. Это транспортный уровень email-коммуникации: 1С формирует сообщение, а SMTP-сервер принимает его и передает в почтовую инфраструктуру.

На практике надежная отправка состоит из нескольких отдельных частей:

событие или команда в 1С → данные → правило и шаблон → готовое письмо → отправка через SMTP → фиксация результата.

Разделение этих этапов особенно важно, когда письма отправляются не вручную, а автоматически по событиям учета.

Что такое SMTP и зачем он нужен 1С

SMTP — протокол, используемый для отправки электронной почты. В типовой схеме 1С выступает клиентом почтового сервера: устанавливает соединение с сервером исходящей почты, передает учетные данные при необходимости и отправляет подготовленное сообщение.

При этом SMTP отвечает именно за передачу письма. Он не определяет:

• какое событие должно запустить коммуникацию;
• кому нужно написать;
• какой шаблон использовать;
• какие данные документа подставить в текст;
• требуется ли перед отправкой подтверждение сотрудника.

Эти задачи относятся к прикладной логике 1С или установленного расширения.

Упрощенно техническую схему можно представить так:

Наличие конкретного механизма очереди или журнала зависит от используемой конфигурации и реализованной автоматизации. Это не следует считать одинаковой штатной функцией всех решений на платформе 1С.

Что поддерживает механизм электронной почты платформы 1С

Платформа «1С:Предприятие» содержит механизм работы с интернет-почтой. Он позволяет подключаться к почтовым серверам с указанием параметров SMTP, IMAP и POP3, а также использовать защищенные соединения SSL/TLS и STARTTLS.

Это подтверждает официальная документация фирмы «1С» по механизму электронной почты платформы.

Конкретная форма настройки учетной записи, расположение команд и набор доступных параметров могут различаться между конфигурациями и версиями. Поэтому при настройке почтового сервера 1С лучше разделять возможности самой платформы и интерфейс конкретного прикладного решения.

Какие данные нужны для подключения SMTP в 1С

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

Обычно необходимы:

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

Не следует подставлять универсальные значения порта, шифрования или способа авторизации только потому, что они подходят другому почтовому сервису. Параметры необходимо брать из документации используемого почтового сервера или у администратора корпоративной почты.

Особенно это важно для корпоративной инфраструктуры, где внешняя отправка может быть разрешена только определенным учетным записям, серверам или адресам отправителей.

Как настроить SMTP в 1С

Практическая настройка SMTP в 1С начинается не с шаблона письма, а с проверки транспортного соединения.

1. Получите параметры почтового сервера

До внесения изменений в 1С нужно определить:

• какой SMTP-сервер используется организацией;
• какие учетные данные требуются;
• какое защищенное соединение используется;
• разрешена ли отправка от нужного адреса;
• есть ли сетевые ограничения для сервера или компьютера, на котором работает 1С.

Если эти параметры неизвестны, сначала следует получить их у администратора почты или поставщика почтовой услуги.

2. Настройте учетную запись отправителя

В используемой конфигурации 1С необходимо создать или настроить учетную запись электронной почты и указать параметры исходящей почты.

Название раздела и формы настройки зависит от конфигурации, поэтому универсальной последовательности вида «откройте такое-то меню и установите такой-то флажок» для всех решений 1С нет.

На этом этапе важно связать между собой четыре параметра:

отправитель → учетные данные → SMTP-сервер → способ защищенного подключения.

Ошибки в любой из этих частей могут сделать отправку невозможной даже при правильно сформированном письме.

3. Проверьте соединение отдельно от бизнес-сценария

Сначала следует убедиться, что 1С вообще может отправить простое тестовое письмо.

Это позволяет отделить проблемы SMTP от ошибок прикладной логики. Если тестовое письмо не отправляется, нет смысла искать причину в правилах обработки счетов, статусах заказов или шаблонах уведомлений.

Проверяется прежде всего:

• устанавливается ли соединение с сервером;
• проходит ли аутентификация;
• разрешена ли отправка выбранному пользователю;
• соответствует ли режим защищенного соединения требованиям сервера;
• не блокирует ли соединение сеть или межсетевой экран.

4. Проверьте адрес отправителя

Адрес, указанный в письме как отправитель, должен соответствовать правилам почтовой инфраструктуры.

Некоторые SMTP-серверы разрешают учетной записи отправлять письма только от собственного адреса или от заранее разрешенных адресов. Поэтому ситуация, когда соединение установлено и пароль принят, еще не означает, что сервер разрешит отправить письмо с любым значением поля «От кого».

5. Только после этого подключайте шаблоны и автоматические сценарии

Когда транспортная часть проверена, ее можно использовать в прикладных процессах: формировать письмо на основании данных 1С, передавать его на проверку или автоматически отправлять через настроенную почтовую учетную запись.

Так проще диагностировать ошибки: SMTP отвечает за доставку подготовленного сообщения почтовому серверу, а правило и шаблон — за то, какое сообщение вообще было создано.

Почтовая учетная запись, SMTP и шаблон — разные уровни

При автоматизации email из 1С эти понятия часто смешивают.

Учетная запись определяет, от имени кого и с какими параметрами выполняется подключение.

SMTP-сервер обеспечивает передачу исходящего письма.

Шаблон определяет тему и содержание сообщения.

Бизнес-правило определяет, когда этот шаблон нужно использовать и какие данные подставить.

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

И наоборот: можно идеально подготовить персонализированное письмо, но без корректно настроенного подключения SMTP оно не будет передано почтовому серверу.

Пример: письмо клиенту после создания счета

Рассмотрим сценарий без привязки к конкретной конфигурации.

В информационной базе появляется счет, который по правилам организации нужно отправить клиенту.

Сценарий коммуникации может выглядеть так:

Событие: сформирован счет, соответствующий установленным условиям.

Получатель: email контактного лица клиента из данных 1С.

Содержание: номер и дата счета, сумма, срок оплаты и другая необходимая информация.

Режим: автоматическая отправка либо предварительная проверка сотрудником.

Из 1С для формирования сообщения могут потребоваться:

• наименование клиента;
• имя контактного лица;
• адрес электронной почты;
• номер документа;
• дата документа;
• сумма;
• срок оплаты;
• данные организации-отправителя;
• файл документа, если он должен быть приложен.

Пример содержания:

Добрый день, Алексей.

Сформирован счет № 184 от 10 сентября 2026 года на сумму 125 000 руб. Просим произвести оплату в соответствии с условиями договора.

Счет приложен к письму.

После формирования готовое письмо передается на отправку через настроенную учетную запись и SMTP-сервер.

Это принципиально отличается от массовой рассылки: сообщение появляется вследствие конкретного бизнес-события и содержит данные конкретного клиента и документа.

Зачем отделять формирование письма от SMTP-отправки

При небольшом количестве ручных писем разница почти незаметна: сотрудник нажал кнопку, письмо сформировалось и сразу отправилось.

При автоматической коммуникации разделение становится важным.

Сначала система должна принять бизнес-решение:

нужно ли создавать сообщение вообще?

Затем подготовить его:

кому, о чем и с какими данными писать?

И только после этого выполнить техническую операцию:

передать письмо SMTP-серверу.

Такая архитектура позволяет отдельно контролировать правила коммуникации и состояние почтового соединения.

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

Для чего нужна очередь сообщений

Очередь — полезный архитектурный элемент при событийной отправке, однако ее наличие и реализация зависят от конкретного решения.

Вместо схемы:

создали документ → немедленно подключились к SMTP → дождались результата

можно использовать схему:

создали документ → подготовили задание на сообщение → отправили его отдельным процессом → записали результат.

Это особенно полезно, когда сообщения создаются автоматически и необходимо:

• повторять отправку после временной технической ошибки;
• не терять сообщение при недоступности почтового сервера;
• контролировать необработанные задания;
• исключать неконтролируемые повторные письма;
• разделять бизнес-операцию и работу внешней почтовой инфраструктуры.

При этом очередь не заменяет журнал. Очередь отвечает за состояние задания, а журнал нужен для истории того, что происходило с коммуникацией.

Типовые проблемы при настройке SMTP-сервера 1С

Большинство проблем подключения SMTP можно искать последовательно — от транспортного уровня к содержанию письма.

Не устанавливается соединение

Следует проверить адрес сервера, порт, режим защищенного соединения и доступность SMTP-сервера из той среды, где фактически выполняется отправка.

Причина может находиться не в самой 1С, а в сетевых правилах организации.

Сервер отклоняет имя пользователя или пароль

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

Простой ввод обычного пароля подходит не для любой современной почтовой инфраструктуры. Требования следует брать у администратора или из документации конкретного сервиса.

Соединение устанавливается, но отправка запрещена

Возможна ситуация, когда пользователь успешно прошел аутентификацию, но не имеет права отправлять письмо от указанного адреса.

В таком случае нужно проверять правила самого почтового сервера и соответствие отправителя учетной записи.

Письмо не формируется из-за отсутствующих данных

Это уже не ошибка SMTP.

Например, у клиента может отсутствовать email, в документе — необходимый реквизит, а в шаблоне — значение для обязательной подстановки. Такие проверки желательно выполнять до передачи письма почтовому серверу.

SMTP принял письмо, но клиент его не видит

Успешная передача сообщения SMTP-серверу и фактическое появление письма во входящих у адресата — не одно и то же.

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

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

Одно событие вызывает несколько одинаковых писем

Такую проблему нельзя исправить настройкой SMTP.

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

Для автоматической отправки важно уметь однозначно связывать сообщение с исходным событием или объектом учета.

Что нужно проверять до автоматической отправки

Работающий SMTP-сервер еще не означает, что любой сценарий нужно полностью автоматизировать.

Автоматическая отправка хорошо подходит для стандартизированных ситуаций, где условия определяются данными системы, например:

• документ сформирован;
• зарегистрирована оплата;
• наступила заданная дата;
• изменилось определенное состояние объекта;
• известен получатель;
• все обязательные данные заполнены.

Подтверждение сотрудником полезнее, когда письмо зависит от контекста переговоров, содержит нестандартные условия или требует проверки данных перед отправкой.

Таким образом, режим отправки является частью бизнес-правила, а не параметром SMTP.

Что фиксировать в журнале отправки

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

Для каждой попытки отправки целесообразно фиксировать как минимум:

• исходное событие или объект 1С;
• получателя;
• использованный сценарий или шаблон;
• время создания сообщения;
• время попытки отправки;
• режим — автоматически или после подтверждения;
• результат передачи;
• описание технической ошибки, если она возникла.

При этом конкретный состав журнала зависит от решения.

Такой подход позволяет ответить не только на вопрос «работает ли SMTP», но и на более важные для бизнеса вопросы: было ли нужное сообщение сформировано, кому оно предназначалось и что произошло при отправке.

SMTP в 1С как часть событийной коммуникации

Когда задача ограничивается несколькими ручными письмами, достаточно настроить почтовую учетную запись и отправлять сообщения по необходимости.

При росте количества регулярных операций появляется другая задача: не просто обеспечить подключение SMTP в 1С, а определить, какие события должны сами запускать коммуникацию.

Архитектура в этом случае выглядит так:

бизнес-событие → данные 1С → правило коммуникации → персонализированное сообщение → автоматическая отправка или проверка сотрудником → SMTP → журнал.

Именно на уровне правил, шаблонов и управления такими сценариями используется Алертариум.

Например, событием может стать создание счета, изменение состояния заказа, поступление оплаты или наступление срока. Алертариум определяет соответствующее правило, формирует сообщение на основании данных 1С и передает его в предусмотренный процесс отправки.

При этом фактическая email-отправка выполняется через локальную 1С клиента. Учетные данные почтового сервера и подключение к SMTP остаются в локальной информационной системе. Облачная часть Алертариума может использоваться для централизованного управления правилами, шаблонами и настройками, но не выступает почтовым сервером клиента.

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

Что в итоге нужно для надежной email-отправки из 1С

Настройка SMTP решает только одну, но критически важную часть задачи — техническую передачу подготовленного письма почтовому серверу.

Для полноценного процесса необходимы четыре уровня:

1. корректная учетная запись и соединение с SMTP-сервером;
2. проверенные данные получателя и отправителя;
3. правило и шаблон формирования сообщения;
4. контроль попыток и результатов отправки.

Если письма формируются автоматически, к этому добавляются требования к повторным попыткам, защите от дублирования, проверке исходных данных и выбору между автоматической отправкой и подтверждением сотрудником.

Поэтому надежная email-коммуникация из 1С начинается с правильной настройки SMTP, но не заканчивается ею.

Автоматизируйте клиентские коммуникации в 1С с Алертариумом. Система сама создаст и отправит нужное сообщение по событию, сократит ручную работу менеджеров и ускорит информирование клиентов. Начните с нескольких ключевых сценариев сейчас.