Email‑транспорт: как устроена доставка писем через SMTP и API

Письмо, которое вы отправляете, не сразу оказывается в ящике подписчика. Между нажатием на кнопку «отправить» и доставкой работает отдельная техническая прослойка — email‑транспорт. Он отвечает за то, чтобы письмо дошло быстро, без ошибок и точно по адресу. 

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

Что такое email‑транспорт

Email‑транспорт — это способ передать ваше письмо из сервиса рассылок (или CRM) к получателю. Это совокупность технологий и протоколов (SMTP или HTTP‑API), которые передают письмо от вашей системы после нажатия кнопки «Отправить» на сервер, откуда письма поступают адресатам.

Это как курьерская служба — от того, насколько она быстрая и надёжная, зависит, дойдёт ли письмо, и когда оно будет доставлено. Представьте: вы написали письмо и хотите, чтобы его точно доставили адресату. Нанимаете курьера. Он берёт письмо, проверяет, куда именно его нести, выбирает маршрут, уточняет, доступен ли получатель, и только потом вручает письмо в руки. Хороший курьер доставит быстро и аккуратно. Плохой — потеряет письмо или оставит у охраны.

Как устроена доставка email‑сообщений

Почтовая доставка состоит из нескольких этапов:

1. Письмо создаётся в системе. Это может быть сервис email-рассылок (ESP), CRM, сайт. На этом этапе формируется содержание письма: тема, текст, заголовки, список адресатов, вложения и параметры персонализации.
2. После нажатия кнопки «отправить» письмо уходит в email‑транспорт — технический уровень, который занимается его доставкой. Их два вида.

SMTP — сетевой протокол, который обменивается командами между серверами. Работает стабильно, но даёт меньше гибкости и настроек.

HTTP-API — набор инструментов и протоколов, через который вы отправляете письмо в виде одного конкретного запроса. Такой подход позволяет быстро масштабировать рассылки и получать расширенную аналитику.

3. Транспорт проверяет, правильно ли оформлено письмо, ставит его в очередь на отправку, выбирает нужный сервер назначения и начинает передачу. Если сервер временно недоступен — транспорт откладывает отправку и пробует снова через несколько минут.
4. Письмо доходит до почтового сервера (например, Gmail или Яндекс Почты). Там оно проходит фильтрацию: проверяется доменная репутация, заголовки, контент, наличие DKIM, SPF и DMARC. После этого письмо либо принимается, либо отклоняется, либо попадает в спам.
5. Email‑транспорт сохраняет, что произошло с письмом: было ли оно доставлено, отклонено, отложено. Эта информация доступна в логах и отчётах — она помогает маркетологу понять, как работает рассылка.

Почему иногда нужно подключать транспорт отдельно от сервиса рассылок

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

Вы регулярно отправляете много писем. При больших объёмах (десятки и сотни тысяч писем в день) важно контролировать скорость доставки и не зависеть от общей очереди сервиса. Отдельный email‑транспорт позволяет выстроить собственный график отправки и моментально отправлять письма всем подписчикам.

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

Выделенный VS общий IP для email-рассылок: чем отличаются и как выбрать

Вы используете собственную систему или приложение для отправки писем. Если у вас есть свой сайт, CRM или сервис и вы хотите отправлять письма оттуда, подключение отдельного транспорта (через SMTP или API) позволяет сделать это напрямую, без захода в интерфейс сервиса рассылок.

Вы хотите отделить разные типы писем. Например, чтобы маркетинговые рассылки шли по одному каналу, а сервисные письма (чеки, уведомления, пароли) — по другому. Это снижает риск того, что важное письмо попадёт в спам: в требованиях почтовиков зачастую прописано, что транзакционные и маркетинговые письма должны идти отдельно, как минимум — с разных адресов.

Вы хотите быть уверены, что письма будут отправляться даже при сбоях. Если основной сервис по какой-то причине временно недоступен, отдельный email‑транспорт можно использовать как резервный канал — чтобы важные письма всё равно доходили до получателей.

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

Чем SMTP отличается от API  и что выбрать

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

Особенности SMTP

SMTP (Simple Mail Transfer Protocol) — это сетевой протокол, с помощью которого письма передаются от сервера отправителя к серверам получателей. Он появился ещё в 1980‑х, и до сих пор остаётся базовым стандартом для доставки email‑сообщений.

SMTP работает как диалог между отправителем и почтовым сервером. Когда вы отправляете письмо, система пошагово обменивается с сервером командами: сначала сообщает, кто отправитель, потом — кто получатель, потом — передаёт само сообщение. Сервер принимает эти данные по очереди и решает, доставлять письмо или нет. Именно поэтому такой способ работает стабильно, но не так быстро, как современные альтернативы.

В некотором смысле можно сравнить этот подход с телеграфом или обменом служебными сообщениями по рации. Вот как выглядит диалог между отправителем и сервером по SMTP:

Преимущества SMTP:

✅ Простота подключения: его можно использовать практически в любой системе: от CMS до кастомных CRM.

✅ Универсальность: SMTP поддерживают все почтовые сервисы и email‑платформы.

✅ Не требует сложной настройки.

Недостатки SMTP:

❌ Недостаток гибкости. Через SMTP сложно передать дополнительные данные — например, разделить письма по типам («рассылка», «чек», «уведомление») или привязать их к конкретным пользователям в вашей системе.

❌ Может работать медленно при больших объёмах. SMTP отправляет письма по одному, как будто вручную. При массовой рассылке (например, на 100 000 человек) это может занять много времени. Иногда письма встают в очередь и расходятся волнами.

❌ Меньше встроенной статистики. SMTP может передать письмо, но сам по себе он не собирает подробную аналитику: сколько писем было открыто, по каким ссылкам кликали, какое письмо вызвало ошибку доставки. Всё это можно реализовать вручную — например, с помощью трек‑пикселя (в сервисах рассылок он встроен по умолчанию) или своих технических решений.

SMTP отлично подходит, если:

• интеграция с сервисом должна быть максимально простой,
• вы работаете с небольшим объёмом писем (например, до 10 000 в день),
• вам не нужна специфическая статистика по каждому письму.

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

Через API гораздо проще настроить такие сценарии: вы можете передавать данные о пользователе и его действиях прямо в момент отправки — подставлять имя, товары из корзины или персональную ссылку. К тому же, если вы работаете не через сервис рассылок, а из собственной системы — например, запускаете письма напрямую из интерфейса сайта или CRM — API может отправлять письма автоматически, без ручного запуска из стороннего сервиса.

Особенности API

HTTP–API — это способ отправки писем через программные запросы. Вы как бы говорите сервису: «отправь вот такое письмо вот такому человеку», передавая все данные через один запрос по протоколу HTTP (по нему же работают сайты и веб‑формы).

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

Преимущества API:

✅ Гибкость. С API вы можете передавать вместе с письмом дополнительные данные — например, имя пользователя, номер заказа или ID клиента. Также можно отмечать письма по категориям: «рекламное», «транзакционное» и т.д. Это упрощает персонализацию и аналитику.

✅ Скорость. Можно отправлять много писем одновременно, без очередей и задержек.

✅ Удобство для разработчиков. API легко интегрируется с сайтами, мобильными приложениями и backend‑системами.

✅ Расширенная аналитика. При отправке через API статистика собирается автоматически: вы получаете готовые данные о доставке, открытиях, кликах, ошибках — и всё это сразу можно связать с конкретным пользователем.

Недостатки API:

❌ Избыточен для простых задач. Если вам нужно просто отправить письмо раз в неделю — API будет лишним.

❌ Сложнее подключить и настроить. Чтобы подключить API, нужен разработчик. Хорошая новость в том, что сервисы, предлагающие email-транспорт, чаще всего помогают в настройке — именно так, например, устроена работа в Unisender Go.

Чтобы было проще выбирать подходящий email-транспорт, мы составили таблицу:

Почему важно использовать российский email‑транспорт

При выборе email‑транспорта один из самых важных критериев — чтобы письма обрабатывались на российских серверах. Вот три основные причины, почему зарубежные варианты не подойдут:

Данные не должны уходить за границу. Если письма отправляются через зарубежные сервисы, информация о ваших подписчиках — например, их email‑адреса — может передаваться на иностранные серверы. А это уже считается трансграничной передачей персональных данных, что может противоречить российскому законодательству (в частности, закону № 152‑ФЗ).

Подробнее об этом рассказали в статье о штрафах за обработку персональных данных для тех, кто занимается email- и CRM-маркетингом.

Российские серверы дают меньше рисков блокировок и сбоев. Почтовые провайдеры (Яндекс, Mail.ru и др.) могут с осторожностью относиться к письмам, отправленным с иностранных IP‑адресов. Это повышает шанс, что письмо попадёт в спам, особенно если вы отправляете массово. Российский email‑транспорт помогает сохранить доверие почтовых сервисов и стабильно попадать во «Входящие».

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

Что ещё нужно учитывать при выборе email‑транспорта

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

Наличие авторизации домена (DKIM, SPF, DMARC). Эти настройки подтверждают, что вы отправляете письма от своего имени, а не кто-то от вашего лица. Без них письма могут попадать в спам или отклоняться почтовыми сервисами. Хороший email‑транспорт позволяет настроить это один раз и использовать автоматически.

Поддержка выделенного IP-адреса. Если вы отправляете большие объёмы писем, лучше использовать отдельный IP, а не делить его с другими пользователями сервиса. Это помогает контролировать репутацию и снижает риск того, что ваши письма попадут в спам из‑за чужих рассылок.

Статистика и отчёты. Проверьте, предоставляет ли сервис данные о доставке, открытиях, кликах и ошибках. Это поможет понять, как работают ваши рассылки и вовремя заметить проблемы.

Очереди и контроль скорости отправки. При массовой рассылке важно, чтобы письма не уходили все одновременно — это может вызвать подозрение у спам-фильтров. Транспорт должен уметь дозировать отправку, распределяя её по времени и обеспечивая стабильную доставку.

Обратная связь от почтовых сервисов. Хорошо, если транспорт может передавать вам технические события в реальном времени — например, что письмо отклонено, пользователь отписался или нажал на «спам». Это поможет оперативно реагировать и корректировать стратегию.

Поддержка и документация. Даже если всё настроено правильно, могут возникнуть вопросы. Важно, чтобы у сервиса была понятная документация и служба поддержки, которая разбирается не только в маркетинге, но и в технических нюансах email‑доставки.

Возможность гибкой интеграции. Если вы планируете отправлять письма из своей системы — через сайт, CRM или приложение — проверьте, поддерживает ли транспорт разные варианты подключения: SMTP, API, SDK, Webhooks и др. Чем больше вариантов, тем проще будет масштабироваться в будущем.

SDK — это готовый набор кода для разработчиков, который помогает быстро подключить email‑транспорт к сайту или приложению. Он упрощает работу с API: не нужно разбираться в каждом запросе — можно использовать уже собранные функции.

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

Кейсы: как email‑транспорт помогает маркетологам и продуктовым командам

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

Brandlink x Ferrero. Агентство Brandlink разработало масштабную акцию с участием продукции Kinder. Покупатели сканировали чеки, регистрировали их на сайте, получали кешбэк и сразу узнавали, получили ли они подарок — от мерча до крупных призов. Участие в акции было завязано на быструю обратную связь: после регистрации кода пользователь должен моментально получить письмо или SMS с результатом. Задержка на этом этапе могла повлиять на доверие к бренду. Чтобы обеспечить мгновенную и надёжную отправку сообщений независимо от нагрузки, команда подключила отдельный email‑транспорт, который работал параллельно с основными рассылками.

НКО «ЖИВИ». Фонд активно использует рассылки для коммуникации с донорами и подписчиками: это и новости, и просьбы о поддержке, и отчётность. Но когда к массовым кампаниям добавились триггерные и сервисные рассылки, стало понятно, что всё это не должно отправляться одним потоком. Чтобы не мешать маркетинговым письмам и не терять важные уведомления в общей очереди, команда фонда подключила отдельный email‑транспорт. Он позволил чётко разделить коммуникацию: массовая рассылка осталась на ESP, а сервисные и CRM‑письма — ушли в отдельный канал, где отправляются быстро, адресно и с полной аналитикой.

Handbox x ЦНОИ. Образовательные проекты, которым и является ЦНОИ («Центр непрерывного образования и инноваций») — это отдельный специфический сегмент, и без триггерных писем здесь не обойтись. Допустим, анонсировать вебинар можно и через обычную массовую рассылку. Но вот отправить подтверждение регистрации на событие или диплом после него желательно как можно быстрее, а письмо с уведомлением о начале вебинара и вовсе должно уходить точно в назначенное время всем получателям. Эту проблему и решало агентство Handbox при помощи триггерных рассылок, настроенных при помощи email-транспорта Unisender Go. Его интегрировали с платформой обработки данных клиентов и Google Календарем, что позволило автоматизировать большую часть писем и существенно облегчило работу команды ЦНОИ.