О чём спор: hosted SMTP/API vs self-hosted MTA
Когда нужно отправлять исходящие письма (транзакционные уведомления, алерты, маркетинговые кампании), выбор обычно сводится к двум подходам.
- Hosted SMTP/API — подключаете внешний сервис и отправляете письма по SMTP или HTTP API. Провайдер держит MTA, очереди, мониторинг, лимиты, репутацию IP-пулов и часть deliverability-рутины.
- Self-hosted — поднимаете свой MTA (чаще
postfixилиexim) на сервере и управляете маршрутами, логами и политиками отправки сами. Вместе с этим на вас ложится ответственность за доставляемость и репутацию.
Вопрос «что лучше» на практике упирается в риски блокировок, требования к контролю и в то, чем вы готовы платить: деньгами за сервис или временем (и инцидентами) за собственную инфраструктуру.
Deliverability: почему это не “отправил и забыл”
Email deliverability — это не только «принял ли сервер письмо», а ещё и куда оно попало: «Входящие», «Спам», «Промоакции». Доставляемость складывается из трёх групп факторов:
- Репутация отправителя: домен, IP, динамика объёмов, жалобы, отписки, проценты отказов.
- Аутентификация: SPF, DKIM, DMARC и согласованность доменов (alignment).
- Техническая гигиена: PTR (reverse DNS), корректный HELO/EHLO, TLS, стабильная работа очередей, отсутствие «подозрительных» паттернов отправки.
Если вы выбираете self-hosted, вы берёте на себя не только установку postfix/exim, но и ежедневную работу с репутацией и реакцию на инциденты: попадание в блок-листы, всплески bounces, компрометацию приложения, проблемы с DNS.
Hosted SMTP/API: сильные стороны и ограничения
Плюсы hosted SMTP/API
- Быстрый старт: часто достаточно домена и корректных DNS-записей.
- Репутация и прогрев: у провайдера обычно уже есть «наработанный» IP-пул и инструменты для warm-up.
- Автоматика deliverability: подавление повторных отправок на hard bounce, трекинг жалоб, события по доставке.
- Масштабирование: пики отправки переживаются проще — очереди и rate limit берёт на себя сервис.
- Меньше эксплуатации: меньше «железных» задач вроде контроля очередей, базовых лимитов и типовой диагностики.
Минусы hosted SMTP/API
- Ограниченный контроль: вы зависите от правил провайдера (лимиты, типы контента, антифрод, скорость разблокировок).
- Shared reputation: общий пул может страдать из-за чужого трафика (в первую очередь там, где провайдер допускает «серые» кейсы).
- Стоимость на объёмах: при больших рассылках плата за 1000 писем, выделенные IP и аналитику может стать заметной.
- Vendor lock-in: API, шаблоны и события привязывают интеграцию к конкретному поставщику.
Если вы строите инфраструктуру вокруг своего приложения, часто удобнее держать вычислительную часть на своём сервере, а почту отдавать наружу. Для приложений и очередей под такие задачи обычно используют VDS, где можно гибко ограничивать доступ к SMTP, логировать и быстро реагировать на аномалии.
Self-hosted Postfix/Exim на VDS: что вы реально покупаете
Свой MTA на сервере — это не «экономия на SMTP», а покупка контроля и прозрачности. Но почта — среда с агрессивными антиспам-фильтрами, поэтому контроль неизбежно превращается в регулярную эксплуатацию.
Плюсы self-hosted
- Полный контроль исходящей почты: маршрутизация, политики TLS, очереди, лимиты, отдельные IP под разные потоки (транзакционка vs маркетинг).
- Первичные логи: у вас есть реальные ответы удалённых серверов, тайминги, ретраи, причины 4xx/5xx.
- Гибкая интеграция: подпись, перезапись заголовков, разные домены/поддомены, собственные пайплайны обработки.
- Контроль данных: содержимое писем и метаданные не проходят через сторонний SMTP/API сервис (важно для части моделей угроз и внутренних политик).
Минусы self-hosted
- Deliverability — ваша зона ответственности: IP reputation, прогрев, реакция на блокировки, гигиена базы.
- Новый IP часто “подозрительный”: свежие адреса и некоторые диапазоны могут иметь низкое доверие у крупных почтовых экосистем.
- Эксплуатационная нагрузка: мониторинг очередей, лимиты, обновления, алерты, расследования.
- Компрометация приложения = катастрофа: одна уязвимость — и сервер начинает рассылать мусор, после чего восстановление репутации может занять недели.
Postfix или Exim: если всё-таки self-hosted
Выбор postfix vs exim часто обсуждают эмоционально, но для исходящей почты важнее не название, а дисциплина эксплуатации и контроль источников отправки.
- Postfix выбирают за предсказуемость, «строгость» архитектуры и распространённость — проще найти готовые, проверенные практики.
- Exim ценят за гибкость маршрутизации и условий обработки, но эта же гибкость повышает риск «работает, но небезопасно/неправильно».
С точки зрения deliverability оба варианта могут работать отлично, если вы держите в порядке DNS, аутентификацию и паттерны отправки.
IP reputation: фактор, который чаще всего недооценивают
IP reputation — это «кредитная история» отправителя. В hosted-модели репутация часто частично «арендована» у провайдера (или разделена с пулом). В self-hosted вы строите её сами: долго и аккуратно.
Что ломает репутацию быстрее всего:
- высокий процент hard bounce (невалидные адреса);
- резкие всплески объёма (вчера 50 писем, сегодня 50 000);
- жалобы пользователей («Это спам»);
- несогласованность доменов и заголовков (проваливается alignment);
- отправка с IP без корректного PTR и с «плавающим» HELO;
- компрометация веб-форм/скриптов и рассылка на «старую» базу.
Если бизнес критично зависит от писем «во Входящие», относитесь к репутации как к продакшен-сервису: лимиты, мониторинг, план реакции и регулярная гигиена адресной базы.
TCO: стоимость владения — где на самом деле “дорого”
По запросам вроде hosted smtp vs self hosted многие ищут «что дешевле». Но корректнее считать TCO (total cost of ownership): деньги + время + риски.
Компоненты TCO для hosted SMTP/API
- оплата за объём писем и опции (выделенный IP, аналитика, дополнительные домены);
- время на интеграцию и поддержку (API, события, шаблоны);
- стоимость ограничений провайдера (лимиты, задержки разблокировок, инциденты на стороне сервиса).
Компоненты TCO для self-hosted на VDS
- стоимость сервера, резервного копирования и мониторинга;
- время админа: настройка MTA, обновления, разбор доставок;
- deliverability-операционка: прогрев, сегментация потоков, чистка базы, контроль жалоб;
- стоимость репутационных провалов: простой уведомлений, потери в конверсиях;
- безопасность: защита приложений, чтобы outbound не стал «спам-пушкой».
На малых объёмах hosted обычно выигрывает по скорости запуска и предсказуемости. На средних/больших объёмах self-hosted может быть выгоднее по прямым расходам, но только если у вас есть процессы и человек, реально отвечающий за почту.
Типовые сценарии: что выбирать
Когда чаще подходит hosted SMTP/API
- нужен быстрый и стабильный канал для транзакционки;
- нет выделенного админа под почту;
- нужны метрики доставки и события по каждому письму;
- объёмы плавают и бывают пики;
- важнее скорость внедрения, чем контроль каждого параметра MTA.
Когда оправдан self-hosted Postfix/Exim на VDS
- есть требования к контролю маршрутизации, логам и данным;
- несколько потоков писем, которые нужно жёстко разделять (разные домены/поддомены/IP);
- высокие объёмы и предсказуемая нагрузка, где стоимость hosted растёт непропорционально;
- команда умеет сопровождать MTA и понимает, что deliverability — это процесс.
Если self-hosted: минимальный чек-лист “чтобы не убить доставляемость”
Ниже — базовые пункты, без которых запуск исходящей почты на своём сервере часто заканчивается блокировками и «вечными» 4xx/5xx.
1) DNS и идентичность отправителя
- PTR (reverse DNS) для IP должен быть настроен; дополнительно проверьте FCRDNS (forward-confirmed reverse DNS).
- HELO/EHLO должен быть стабильным и соответствовать DNS-имени (и логике PTR).
- MX не обязателен для outbound, но нужен, если вы принимаете ответы на адреса домена.
2) Аутентификация: SPF, DKIM, DMARC
- SPF: разрешите отправку с вашего IP (или ваших релеев), избегайте слишком широких правил.
- DKIM: подпись уже стала «гигиеническим минимумом»; ротация селекторов — хорошая практика.
- DMARC: начинайте с мониторинга, а ужесточение делайте после анализа отчётов.
Deliverability часто ломается не потому, что «DKIM не настроен», а потому что домены в заголовках не согласованы и alignment не проходит. Сверяйте домены в From, envelope-from (Return-Path) и d= в DKIM.
Про ротацию DKIM и практические нюансы TTL можно почитать отдельно: как планировать ротацию DKIM-селекторов и TTL записей.
3) Политики исходящей отправки и очереди
- задайте rate limit и лимиты параллелизма (особенно на старте прогрева);
- разделяйте потоки (транзакционные письма отдельно от массовых);
- настройте ретраи и TTL очереди так, чтобы письма не «умирали» слишком рано и не висели вечность.
4) Мониторинг и реакция на аномалии
- контроль размера очереди и скорости её роста;
- алерты на всплеск отправки в минуту/час;
- сигнализация по росту bounces и 4xx/5xx;
- раздельная атрибуция отправителей (если писем отправляют несколько приложений или клиентов).
5) Безопасность приложения важнее, чем “идеальный postfix”
Самая частая причина репутационного провала self-hosted — не ошибки MTA, а компрометация сайта/CRM и массовая отправка мусора. Минимум, который стоит сделать:
- разрешайте отправку только через аутентифицированный submission; ограничивайте источники по IP/ACL;
- ставьте лимиты на уровне MTA и на уровне приложения (не доверяйте одному слою);
- регулярно обновляйте ПО и следите за секретами (ключи, токены, пароли).
Если вы делаете собственную инфраструктуру исходящей почты, почти всегда потребуется нормальная доменная «гигиена»: домен, DNS, TLS. Доменные задачи (включая управление записями для SPF/DKIM/DMARC) удобнее вести там же, где у вас регистрация доменов.
Гибридный вариант, который часто выигрывает
Во многих проектах оптимален компромисс:
- Транзакционные письма (логины, чеки, уведомления безопасности) — через hosted SMTP/API ради стабильной deliverability.
- Сервисные/внутренние (алерты мониторинга, письма в техподдержку, системные отчёты) — через self-hosted на VDS, где важнее контроль и логи, а объёмы малы.
Так вы снижаете риски: даже если ваш сервер столкнётся с репутационными проблемами, ключевая бизнес-почта продолжит доходить.
Как принять решение: короткая матрица
Чтобы выбрать быстро, ответьте себе на пять вопросов:
- Сколько писем в сутки и насколько ровный график?
- Критичность Inbox: потеря 5% писем — это боль или допустимо?
- Есть ли ресурсы на эксплуатацию: человек, процессы, мониторинг?
- Нужен ли контроль данных и маршрутизации (безопасность, комплаенс, аудит)?
- Готовы ли вы жить с репутацией IP: прогрев, блокировки, разбор инцидентов?
Если хотя бы по двум пунктам ответ «не знаю», hosted SMTP/API обычно безопаснее. Если требования понятны и почта для вас — полноценный продакшен-сервис, self-hosted postfix/exim на VDS даст больше контроля и может снизить TCO на длинной дистанции.
Вывод
Hosted SMTP/API — это скорость, предсказуемость и частично «аренда репутации». Self-hosted — это контроль и гибкость ценой постоянной ответственности за deliverability, IP reputation и безопасность источников отправки. Выбирайте подход не по идеологии, а по рискам, объёму и готовности команды сопровождать исходящую почту как критичный сервис.
