SMTP или HTTP API: как отправлять письма из своей системы

Любая система, которая шлёт письма — CRM, аутрич-платформа, бэкенд продукта, — рано или поздно упирается в выбор: отправлять через классический SMTP или через HTTP API почтового провайдера. Оба способа доводят письмо до адресата, но по-разному устроены изнутри: у них разная скорость, разная обратная связь об ошибках и разная цена интеграции. Разберём различия без маркетинга и сформулируем, когда какой вариант выбирать — с поправкой на специфику B2B-аутрича, где писем немного, но каждое должно дойти.

Как устроены оба способа и в чём принципиальная разница

SMTP — протокол доставки почты, ровесник интернета: ваша система открывает соединение с сервером-релеем, проходит диалог (HELO, авторизация, MAIL FROM, RCPT TO, DATA) и передаёт письмо целиком — уже собранный MIME-документ со всеми заголовками, телом и вложениями. Релей дальше сам занимается доставкой до сервера получателя. Ключевое: вы формируете письмо на своей стороне и полностью контролируете его байты.

HTTP API — это обычный REST-вызов к сервису провайдера: POST-запрос с JSON, где поля from, to, subject, html, attachments. Провайдер сам собирает из этого MIME-письмо, подписывает его DKIM и ставит в свою очередь доставки. В ответ вы получаете структурированный результат: идентификатор сообщения, статус приёма, код ошибки — а дальше вебхуками прилетают события: доставлено, отклонено, открыто, жалоба.

Принципиальная разница не в «старый против нового», а в разделении ответственности. SMTP: вы отвечаете за сборку письма, провайдер — за доставку; интерфейс стандартный, содержимое непрозрачно для транспорта. API: провайдер забирает себе и сборку, и доставку; интерфейс проприетарный, зато обратная связь богатая. Все остальные различия — следствия этого разделения.

Аргументы за SMTP: универсальность, контроль, совместимость

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

Второй — полный контроль над письмом. Вы собираете MIME сами, а значит, управляете каждым заголовком: Message-ID, In-Reply-To и References для тредов переписки, кастомные заголовки, порядок частей multipart, кодировки. Для аутрича это не экзотика: фоллоу-ап, который почтовый клиент получателя показывает в той же ветке, что и первое письмо, требует корректных ссылочных заголовков — через SMTP это делается напрямую.

Третий аргумент специфичен для холодного B2B-аутрича: отправка через реальные почтовые ящики. Адресные кампании идут от имени живых аккаунтов на доменах компании — а у почтовых провайдеров наружу торчит именно SMTP (плюс IMAP для чтения ответов). Отправляя через SMTP ящика, вы получаете письма, неотличимые от написанных вручную: тот же сервер отправки, те же подписи, та же инфраструктура. Письмо от того же адреса, но ушедшее через API стороннего сервиса, отправлено с чужой инфраструктуры — и для спам-фильтров это заметная разница.

Аргументы за HTTP API: скорость, обратная связь, сервис

Первый аргумент — производительность на объёмах. SMTP-диалог — это несколько сетевых раунд-трипов на письмо, и хотя соединение можно переиспользовать, на тысячах писем в минуту это узкое место. HTTP API принимает батчи: один запрос — сотни персонализированных писем, плюс HTTP-инфраструктура (пулы соединений, HTTP/2, балансировка) отработана лучше. Для транзакционного потока продукта с пиками это весомо; для аутрича с его десятками писем в день с ящика — безразлично.

Второй — качество обратной связи. SMTP отвечает трёхзначным кодом и текстовой строкой, формат которой у каждого сервера свой; часть ошибок приходит позже асинхронным bounce-письмом, которое нужно ловить и парсить. API возвращает структурированные ошибки сразу («адрес невалиден», «в стоп-листе», «лимит исчерпан») и шлёт вебхуки по всему жизненному циклу письма: принято, доставлено, отклонено, открыто, клик, жалоба. Строить аналитику и автоматику поверх вебхуков на порядок проще, чем поверх парсинга bounce-писем.

Третий — сервисная обвязка: очереди с ретраями, шаблоны с подстановкой, автоматическая обработка отписок, дашборды доставляемости. С API вы получаете это из коробки; со SMTP-релеем значительную часть придётся строить самим. Если команда маленькая, а письма — не ядро продукта, эта экономия инженерного времени решает.

Сравнение по критериям, которые реально влияют на выбор

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

Заметьте, чего в списке нет: доставляемости как таковой. Вопреки распространённому мифу, сам по себе способ передачи письма провайдеру на попадание в инбокс почти не влияет — судьбу письма решают домен, репутация, контент и база. Влияет косвенное: через API провайдер подписывает письма и управляет заголовками сам (сложнее ошибиться), а через SMTP собственного ящика вы наследуете инфраструктуру почтового сервиса (что для аутрича плюс). Выбирайте транспорт по инженерным критериям, доставляемость делайте отдельно.

• Переносимость: SMTP — стандарт, смена провайдера тривиальна; API — код привязан к вендору
• Скорость на объёмах: API заметно быстрее за счёт батчей; SMTP упирается в диалог протокола
• Контроль заголовков и MIME: SMTP — полный; API — в рамках возможностей провайдера
• Обратная связь: API — структурированные ошибки и вебхуки; SMTP — коды ответов и парсинг bounce
• Отправка от реальных ящиков компании: SMTP — да, нативно; API — нет
• Треды переписки (In-Reply-To/References): SMTP — напрямую; API — если провайдер разрешает эти заголовки
• Сервис из коробки (очереди, шаблоны, дашборды): API — да; SMTP — строите сами
• Порог входа: SMTP — конфиг в любой библиотеке; API — интеграция с SDK конкретного вендора

Что выбирать под конкретные сценарии

Транзакционные письма продукта — регистрации, сбросы паролей, счета, уведомления: HTTP API специализированного провайдера. Объёмы рваные, нужна скорость, ретраи и мониторинг, контроль заголовков не нужен, письма идут с технического домена. Это родная территория API, и городить здесь свой SMTP-конвейер незачем.

Холодный B2B-аутрич: SMTP реальных ящиков на доменах компании. Объёмы малые (30–50 писем в день с ящика — здоровый потолок), критична неотличимость от ручной переписки, нужны треды для фоллоу-апов и IMAP для приёма ответов. API-провайдеры массовых рассылок для этого сценария не предназначены и прямо запрещают холодные базы в своих правилах — аккаунт забанят по первым жалобам. Вся серьёзная аутрич-инфраструктура, включая нашу, строится на SMTP/IMAP-подключениях к боевым ящикам.

Маркетинговые рассылки по подписной базе: обычно API сервиса рассылок — там живут шаблоны, сегменты и отписки. Гибридный случай — своя CRM, из которой уходят и уведомления, и деловые письма менеджеров: правильный ответ — оба транспорта за одним внутренним интерфейсом. В коде продукта — абстракция «отправить письмо», под ней — драйверы SMTP и API, выбор по типу письма и настройкам. Такая архитектура стоит один-два дня разработки и навсегда снимает вопрос миграции: транспорт становится конфигурацией, а не архитектурным решением.

Типичные ошибки интеграции — у обоих способов

Со стороны SMTP. Отправка без переиспользования соединений — коннект на каждое письмо в цикле: медленно и похоже на поведение спам-бота. Игнорирование кодов ответа: 4xx (временная ошибка) требует ретрая с задержкой, 5xx (постоянная) — исключения адреса; ретраить 5xx или бросать 4xx — обе ошибки болезненны. Отсутствие обработки асинхронных bounce: письмо принято релеем, отклонено дальше, а ваша система об этом так и не узнала и продолжает слать на мёртвый адрес.

Со стороны API. Жёсткая привязка к SDK вендора по всему коду вместо одной точки интеграции — миграция превращается в рефакторинг всего проекта. Игнорирование rate-лимитов и отсутствие очереди на своей стороне: при пике API начинает отвечать 429, и письма молча теряются. Невалидация вебхуков: обработчик событий без проверки подписи — это дыра, через которую кто угодно «доставит» или «отпишет» что угодно в вашей базе.

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

Вопросы и ответы