Транзакционные письма: SMTP, API или свой почтовый сервер

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

Сначала определите, что именно вы отправляете

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

Независимо от способа отправки вам понадобятся:

• домен отправителя, доступ к его DNS и адрес для ответов;
• настроенные SPF и DKIM, а также политика DMARC, согласованная с вашим доменом;
• очередь или иной механизм повторной отправки временно не доставленных писем;
• обработка постоянных отказов, жалоб и отписок там, где они применимы;
• метрики: попытки отправки, отказы, задержки и доля писем, принятых почтовым сервисом получателя.

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

Три варианта отправки

1. SMTP-реле почтового провайдера

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

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

2. API почтового провайдера

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

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

3. Собственный исходящий MTA

MTA — сервер, который передаёт почту другим почтовым серверам. Для самостоятельной отправки часто используют Postfix; здесь ориентир по ПО — Postfix 3.8, но статья не является инструкцией по его установке и настройке. Сверяйте версию с поддерживаемой веткой вашего дистрибутива и официальной документацией.

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

Универсальной цены здесь нет: провайдеры меняют тарифы, а стоимость собственного сервера зависит не только от аренды машины. Сравнивайте актуальную цену за нужный объём отправки, плату за дополнительные функции и стоимость времени команды на поддержку. Для самостоятельного MTA учитывайте также запасной IP или маршрут, если он нужен вашему сценарию.

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

Как выбрать без лишней миграции

1. Если приложение уже умеет надёжно отправлять SMTP-письма — начните с SMTP-реле. Проверьте, что библиотека передаёт корректные адреса и заголовки, а приложение не считает любой ответ сервера доказательством доставки. Результат проверки: тестовое письмо появляется в почте, а отказ отражается в логах или панели провайдера.
2. Если нужны статусы и события — сравните API. Убедитесь, что провайдер сообщает о временных и постоянных отказах, а ваша система умеет принимать эти события без повторной обработки. Результат: тестовый отказ меняет статус письма и не запускает бесконечный цикл отправок.
3. Выбирайте собственный MTA, только если есть владелец эксплуатации. До запуска назначьте ответственных за DNS, обновления, очереди и инциденты с доставкой. Результат: команда может определить, кто разбирает недоставку в нерабочее время, а не только кто однажды установил Postfix.
4. Прогоните тесты до переключения боевого потока. Отправьте письмо на адреса разных почтовых сервисов, проверьте заголовки аутентификации и смоделируйте отказ. Результат: вы видите, как приложение и мониторинг ведут себя при успешной отправке, временной ошибке и постоянном отказе.

Что ломается в реальной эксплуатации

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

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

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

Тестовые письма уходят реальным клиентам. Разделите тестовый и боевой режимы, ограничьте получателей тестового окружения и проверяйте домен отправителя перед релизом. Секреты SMTP или API храните в системе управления секретами либо защищённых настройках окружения, а не в репозитории.

Что делать дальше

Для большинства команд разумная отправная точка — SMTP-реле или API управляемого провайдера, а не самостоятельная доставка с собственного IP. Выбирайте SMTP, если важна простая интеграция; API — если нужны события и функции сервиса; собственный MTA — если у вас есть конкретное инфраструктурное требование и люди для поддержки.

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