Эта статья ориентируется на бизнес-сегмент (владельцев магазинов, операторов услуг), также на новичков в email-маркетинге. Опытным разработчикам и системным администраторам она может показаться не такой полезной, но определённо поможет восполнить некоторые пробелы в знаниях. Постараемся максимально просто и доступно объяснить, что такое email-транспорт, в каких ситуациях и почему может потребоваться использование SMTP-протокола, а также API-интерфейса.

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

Что такое email-транспорт и как доставляются электронные письма

Email-транспорт – это набор сервисов и инструментов, которые отвечают за доставку электронных писем от отправителей до сервера получателя. Забрать или посмотреть письмо получатель может по-разному, это уже не транспортировка, а получение email.

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

Для реализации транспортировки email существует три основных подхода:

  1. Свой SMTP сервер. Если упростить, то это как покупать свой грузовик, нанимать водителя и самому строить маршрут поездки (заниматься логистикой). Дёшево на масштабе, но очень сложно и дорого, если говорить о разовых вложениях. Окупаемость может растянуться на несколько лет.
  2. Готовый SMTP Relay (на базе сервиса рассылок). Продолжая аналогию, это как аренда грузовика с проверенным водителем, где часть технических моментов всё равно на вас, но разовых вложений больше нет. Вы арендуете готовое решение.
  3. Email API (тоже только на базе сервиса рассылок). Это как отправка посылок через опытную службу доставки с сетью пунктов выдачи и штатными курьерами. Вы просто отдаёте коробку, а обо всём остальном заботится сервис.

Больше технических деталей о email-транспорте

Если вы знакомы с современными сайтами, то примерно должны понимать, что для их отображения требуется браузер, что страницы хранятся на серверах, и что при обращении к таким страницам по сети передаются данные с определённой разметкой – речь об HTML-коде. Протокол, который за это отвечает – HTTP(S).

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

  • Письма могут передаваться по цепочке из нескольких серверов, но в конечном счёте они должны оказаться на том почтовом сервере, к которому получатель может обратиться для их прочтения.
  • Для отображения содержимого нужен почтовый клиент (он может быть реализован в виде отдельной программы или в виде веб-интерфейса, который работает в браузере).
  • В качестве протокола передачи данных могут использоваться разные технологии – SMTP, POP, IMAP, HTTP(S). Они зависят от целей передачи данных и от направления потока.
  • В случае с сайтами, трафик маршрутизируется на основе домена и идентификатора (адреса) страницы. А в случае с почтой, для поиска почтового ящика получателя используется идентификатор пользователя (его логин/ник, то есть первая часть адреса до символа «@») и почтовый домен.

И там, и там участвуют домены, а значит и вся DNS-система.

Но, так как серверы, которые отвечают за работу с сайтом и с email, обычно физически разнесены, внутри DNS-системы применяются разные строки для указания нужного сервера. За адресацию почтовых серверов отвечают MX-записи.

Итак, чтобы доставить email, нужен целый стек технологий и соответствующие серверы. Их совокупность – это и есть email-транспорт (система доставки).

Теперь о технологиях:

  • Для забора письма (для получения email с конечного почтового сервера) может использоваться сразу два протокола – POP или IMAP.
  • Для отправки (то есть для транспортировки email) существует только один протокол – SMTP (расшифровывается как Simple Mail Transfer Protocol). Но из-за его технических ограничений, так как приём и передача email осуществляется только поштучно, разработчики всё чаще применяют альтернативный подход – HTTP API.

Давайте остановимся на способах транспортировки email и расскажем о каждом с мини-примерами.

Email-транспорт на основе SMTP

SMTP – это главный и единственный протокол для пересылки почты между серверами.

Работает он примерно так:

  1. Почтовая программа отправителя (это может быть ваш почтовый сервис с веб-интерфейсом, профильное программное обеспечение или любая система автоматизации, например, движок/CMS сайта, CRM-система, сервис рассылок и т.п.) подключается к своему почтовому серверу и передает ему письмо. Подключение осуществляется по SMTP-протоколу, например, через адрес smtp.mail.ru, smtp.gmail.com, smtp.yandex.ru, smtp.rusender.ru и т.п.
  2. Далее этот сервер находит сервер получателя (через DNS-записи – на основе MX-строк) и передаёт письмо ему. Тот принимает его и кладёт в почтовый ящик получателя (технически это может быть специальная папка, а может быть и база данных).

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

  1. Источник: Привет (начало сессии)
  2. Принимающая сторона: Добро пожаловать (сессия установлена)
  3. Источник: Данные отправителя
  4. Принимающая сторона: Отправитель принят
  5. Источник: Вот адрес получателя
  6. Принимающая сторона: Получатель найден/принят
  7. Источник: Сейчас буду передавать данные/содержимое
  8. Принимающая сторона: Жду
  9. Источник: <Атрибуты и содержимое письма>
  10. Принимающая сторона: Принято
  11. Источник: Конец сессии
  12. Принимающая сторона: ОК

Email-транспорт по API

API расшифровывается как Application Programming Interface – это программный интерфейс приложения. API не является транспортным протоколом и у него нет никаких строгих стандартов, если не считать каких-то внутриотраслевых архитектурных стилей, типа RESTful API.

API позволяет «разговаривать» напрямую с почтовым сервером, чтобы быстро и эффективно обмениваться данными в удобном формате, со специальной разметкой.

Но есть нюанс – по API можно обратиться только к сервисам email-рассылок и только, если у них есть такой интерфейс. В дальнейшем такой сервис всё равно перейдёт на SMTP-протокол, чтобы отправить письмо на сервер получателя. Однако, процесс формирования задания на рассылку можно ускорить в разы. Как это может выглядеть (если упростить):

  1. Источник: ДАННЫЕ – <от кого> <список получателей: email1, email2, … email999> <Содержимое письма … {здесь тег для персонализации}> <Дополнительные атрибуты> <Особенности задания на рассылку>
  2. Принимающая сторона: Принято, вот ИДЕНТИФИКАТОР рассылки (если не принято, то возвращается код ошибки)

В реальности данные в сервис рассылок передаются по HTTP-протоколу, поэтому подход называется HTTP API.

Сравнение API vs SMTP

Давайте сразу соберём всё в сводную таблицу:

КритерийSMTPHTTP API
Сложность интеграцииПростая.
Многие CRM и CMS системы имеют модули или готовые настройки для подключения по SMTP.		Сложная.
Код интеграции нужно будет писать с нуля, при этом у каждого сервиса рассылок могут быть свои особенности команд и синтаксиса.
Скорость отправкиНизкая.
Из-за необходимости устанавливать соединение и последовательно отправлять команды для каждого письма.		Очень высокая.
Отправка возможна одним HTTP-запросом, который может содержать десятки тысяч email-адресов получателей.
Функциональность и аналитикаМинимальная.
Отправляется только «сырой» email. Соответственно, отследить можно только системные параметры.		Богатая.
Возможна поддержка шаблонов, тегов, сегментов. Детальная аналитика (открытия, клики, отписки, жалобы на спам), но всё это зависит напрямую от возможностей сервиса рассылки.
Персонализация писемНет.
Одно письмо – один получатель (если не считать копии)		Да.
Внутри писем можно использовать синтаксис для полей персонализации (сервис рассылки сам подставит актуальные данные в зависимости от получателя).
Обработка ошибокОбычно примитивная.
Часто можно получить лишь общий код ошибки (например, «5xx — Server error»).		Детальная.
API возвращает четкие ответы с кодами ошибок и понятными сообщениями для каждого email в запросе.

В каких ситуациях и какой подход будет лучше:

  • SMTP-транспорт будет удобен для подключения корпоративной почты (например, для интеграции с CRM или CMS-системой), а также сервисов рассылок, если речь идёт о разовых/точечных письмах и о небольшом объёме отправок, до 10 тыс. в день. Типичная ситуация – транзакционные рассылки: технические уведомления, оповещения и т.п.
  • Рассылки по API будут интересны при работе с массовыми рекламными/маркетинговыми рассылками и при постановке задач ESP-сервису, в том числе при большом объёме транзакционных и триггерных рассылок, несколько десятков тысяч email в день и более.

Зачем использовать SMTP сервиса рассылок, если транзакционные письма можно отправлять через сервер корпоративной почты?

Очень каверзный вопрос с не самым очевидным ответом.

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

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

  1. Ограничения корпоративной почты. Корпоративный сервер обычно рассчитан на переписку сотрудников и клиентов, а не на массовую отправку. И это чётко оговаривается условиями использования сервиса. У корпоративной почты могут быть лимиты на количество писем, отправляемых в сутки или в час, здесь нет никакой особой оптимизации для высокой скорости доставки. Как только объём транзакционных писем станет большим, корпоративная почта может «захлебнуться» или, что хуже, заблокировать ваши отправления.
  2. Репутация и доставляемость. Провайдеры общей почты (Gmail, Яндекс, Mail.ru и др.) очень строго проверяют письма. Но главное не это. У каждого отправителя есть репутация, которая считается по совокупности факторов. Анализируются не только ошибки и жалобы, но и история IP, с которого ведётся рассылка. У проверенных сервисов рассылки, если они выступают в роли транспортного слоя, больше шансов попасть во входящие. В то время как стандартные отправки через серверы корпоративной почты чаще будут попадать в спам, даже если соблюдены все другие технические условия. Подробнее о прогреве доменов и почтовых серверов.
  3. Масштабируемость и стабильность. Профильные сервисы умеют обрабатывать десятки и даже сотни тысяч писем в час, равномерно распределяя нагрузку. А если письмо триггерное, то оно получает наивысший приоритет и доставляется клиенту практически мгновенно. В отдельных моментах это может быть критично, например, при отправке второго фактора безопасности или кода для восстановления доступа.
  4. Подробная отчётность и аналитика. SMTP-отправки внутри сервисов рассылок могут дать детальную информацию об ошибках, жалобах и других аспектах: сколько писем доставлено и в какие дни, сколько открыто, какие ответы сервера были получены и пр. В корпоративной почте никакой аналитики нет.

Предметные инструкции для API и SMTP RuSender

До 100 транзакционных писем в месяц по API и SMTP в RuSender можно отправлять бесплатно.

Максимум деталей по использованию Email API с примерами для разных языков программирования смотрите в разделе для разработчиков. Отдельная инструкция – как получить ключ для API.

Сводный материал о начале работе с SMTP. Там же ссылки на инструкции по подключению разных внешних сервисов: CRM и CMS-систем.

Дата публикации Дата публикации: 25 сентября 2025

Автор статьи

Дарья Л.

Написано статей: 116

Контент-менеджер и email маркетолог в RuSender.

Поделиться статьёй