Mailgun, Sendgrid, Postmark vs Postfix: что выбрать для SMTP-рассылки

Почтовая инфраструктура давно перестала быть «чем-то простым вокруг SMTP». Чтобы письма действительно доходили до ящиков пользователей, а не гнили в спаме или очереди, нужно учитывать репутацию IP, DNS-записи, DMARC, ретраи, мониторинг, объёмы, а иногда и юридические нюансы.

На практике у админа или девопса чаще всего два пути:

• поднять свой MTA (чаще всего Postfix) и управлять всем самостоятельно;
• использовать специализированный облачный сервис доставки писем: Mailgun, Sendgrid, Postmark и им подобные.

Разберёмся, как эти варианты выглядят с точки зрения архитектуры, стоимости, времени и, главное, deliverability. А заодно — какие гибридные схемы SMTP работают лучше всего.

Задачи, которые вы решаете почтой

Перед тем как сравнивать Postfix и внешние сервисы, важно честно ответить на вопрос: какую именно почту вы отправляете и насколько она критична для бизнеса.

• Транзакционная почта: подтверждение регистрации, смена пароля, чеки, нотификации из приложений, двухфакторка.
• Маркетинговые рассылки: дайджесты, промо-акции, abandoned cart, «вернись к нам».
• Системная/служебная почта: алерты мониторинга, отчёты cron, письма админам.

У этих потоков очень разный профиль:

• транзакционная почта чувствительна к задержкам и deliverability;
• маркетинговая — к жалобам на спам, отпискам, репутации домена и лимитам отправки;
• служебная — к надёжности, логам и понятной диагностике (очереди, ретраи).

Именно от профиля нагрузки зависит, насколько вам подойдёт свой Postfix, и имеет ли смысл подключать Mailgun, Sendgrid или Postmark.

Postfix: контроль, гибкость, ответственность

Postfix — де-факто стандартный MTA в мире Linux. На VDS его поднимают буквально везде, от маленьких проектов до крупных SaaS-платформ.

Основные плюсы собственного Postfix:

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

Но вместе с этим приходит и ответственность:

• поддерживать записи SPF, правильный PTR, DKIM, DMARC;
• следить за репутацией IP-адресов;
• работать с blocklist-ами (Spamhaus, SORBS, UCEPROTECT и т.д.);
• тюнинговать ретраи и лимиты, чтобы не попасть под «temporary deferral» крупными провайдерами;
• делать мониторинг очередей и бэкапы конфигов.

Технически поднять Postfix как SMTP — несложно. Сложно долго удерживать хорошую репутацию и стабильную доставку, особенно при больших объёмах рассылаемой почты.

Deliverability со своим Postfix

С deliverability свой MTA чаще всего проигрывает готовым почтовым платформам.

Почему так происходит:

• ваш IP-адрес «молодой» и не имеет истории отправки почты;
• многие крупные почтовики негативно относятся к одиночным IP без репутации;
• любой всплеск жалоб на спам, даже небольшой, может сильно просадить доставку.

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

Если вы строите доставку с нуля и хотите разобраться глубже, посмотрите материал про практический тюнинг Postfix и SPF/PTR: тюнинг Postfix и базовая доставляемость.

Mailgun, Sendgrid, Postmark: что дают облачные SMTP-сервисы

Mailgun, Sendgrid, Postmark и другие в этом классе продают не столько SMTP, сколько репутацию и инструменты управления доставкой.

Ключевые преимущества:

• Готовая инфраструктура SMTP: IP-пулы, прогрев IP, многозонная география, отказоустойчивость.
• Deliverability из коробки: отслеживание жалоб, отписок, фидбеки от провайдеров, управление репутацией.
• Глубокая аналитика: статистика доставок, open/click tracking, webhooks со статусами.
• Инструменты разработчика: удобные SDK, API, тестовые песочницы, лог-экспорт.

Минусы тоже есть:

• Стоимость растёт вместе с объёмом рассылки — модели тарификации сильно различаются, но «бесплатно и безлимитно» не бывает.
• Вендор-лок: вы завязываетесь на API и особенности конкретного сервиса.
• Ограничения на контент: агрессивный маркетинг, серые схемы и пограничные темы могут привести к бану или сильному урезанию лимитов.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Mailgun: гибкость для разработчиков и API-first

Mailgun исторически позиционирует себя как сервис для разработчиков. У него мощное API для отправки писем, управления доменами, логами и событиями.

• гибкие настройки маршрутизации и обработки входящей почты;
• сильный акцент на логах событий и webhooks (доставлено, сбой, жалоба, открытие, клик);
• удобные инструменты для A/B тестов и валидации адресов (e-mail validation).

Mailgun хорошо заходит там, где почта тесно интегрирована с логикой приложения: сложные workflow, сегментация, мелкая аналитика на уровне событий.

Sendgrid: массовые рассылки и маркетинговые фичи

Sendgrid силён в массовой рассылке и маркетинге. У него развитый UI, drag-and-drop редактор писем, сегментация базы.

• подходит для компаний, которые активно шлют промо-письма и дайджесты;
• имеются встроенные инструменты A/B тестирования контента, шаблонов, тем;
• есть готовые интеграции с популярными SaaS и CRM.

С точки зрения SMTP это тоже обычный relay с аутентификацией, но основная ценность — в маркетинговой надстройке и масштабируемой deliverability.

Postmark: фокус на транзакционных письмах

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

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

Если вам нужно «чтобы письма из приложения доходили всегда и быстро», Postmark часто оказывается хорошим компромиссом по deliverability, цене и простоте.

Архитектурные подходы: где тут Postfix и где Mailgun, Sendgrid, Postmark

По факту у вас не бинарный выбор «Postfix или внешние сервисы». Вариантов комбинаций довольно много, и во всех Postfix остаётся удобным локальным SMTP-шлюзом.

1. Только Postfix (полностью свой SMTP)

Классический вариант: веб-приложение отправляет почту через локальный Postfix, а он напрямую доставляет письма во внешний мир. Вы полностью отвечаете за:

• записи SPF, DKIM, DMARC;
• репутацию IP;
• мониторинг очередей и ретраев;
• анализ bounce-ов.

Подходит, когда:

• объёмы небольшие и рост не планируется;
• основная часть почты — служебные письма и уведомления внутри своей компании;
• вы готовы мириться с тем, что часть писем может стабильно улетать в спам у крупных провайдеров.

2. Postfix как смарт-хост к внешнему сервису

В этом сценарии ваш Postfix не доставляет письма напрямую конечным доменам. Он отправляет всё (или часть трафика) на Mailgun, Sendgrid или Postmark как на relayhost.

Архитектурно Postfix превращается в локальный SMTP-шлюз для ваших приложений, а «грязную» работу с deliverability делает облачный сервис.

Пример минимальной настройки relayhost в конфигурации main.cf:

relayhost = [smtp.mailgun.org]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes

Плюсы такого подхода:

• приложения продолжают использовать обычный SMTP (localhost:25), им не нужно знать о стороннем сервисе;
• вы можете централизованно логировать, фильтровать и маршрутизировать почтовый трафик на своём Postfix;
• легче мигрировать между сервисами — приложения не меняются, вы просто переключаете relayhost.

Минусы:

• двойной уровень ошибок (Postfix и внешний провайдер), нужна хорошая система логирования;
• в случае проблем с внешним провайдером трафик встанет, если не предусмотрен fallback.

3. Гибрид: свой Postfix и внешний сервис только для части доменов или типов почты

Распространённая и практичная схема:

• транзакционная почта и важные уведомления — через Mailgun, Sendgrid или Postmark;
• системные алерты, отчёты cron, внутренняя почта — через ваш Postfix напрямую;
• маркетинг — либо через отдельный сервис, либо через специализированную платформу.

Реализуется это с помощью таблиц маршрутизации в Postfix (transport maps, sender_dependent_relayhost и т.д.). Такой подход даёт хороший баланс:

• критически важная почта опирается на инфраструктуру с высокой deliverability;
• внутренняя и служебная почта не тратит ваш платный лимит у почтового провайдера;
• остаются стандартные SMTP-интерфейсы для приложений.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Стоимость и лимиты: когда внешний SMTP окупается

Многие админы интуитивно считают, что «свой Postfix дешевле, чем оплачивать сервис». Это верно только при очень небольших объёмах и в том случае, если вы не учитываете трудозатраты и риски.

Факторы затрат при своём Postfix:

• Время настройки: от пары часов для базового варианта до дней или недель для полноценной надёжной инфраструктуры с мониторингом и резервированием.
• Поддержка: расследование проблем с доставкой, работа с blocklist-ами, изменения политик у провайдеров.
• Риски: разовая ошибка конфигурации может привести к массовому падению deliverability, репутацию потом придётся восстанавливать.
• Железо и IP: если вам нужны выделенные IP или отдельные сервера только под почту.

У Mailgun, Sendgrid и Postmark цена более очевидна: вы примерно знаете стоимость нужного количества писем в месяц. Но они тоже вводят ограничения:

• лимиты по скорости отправки (rate limits);
• политики против спама и высоких bounce-рейтов;
• отдельная плата за выделенные IP, расширенный срок хранения логов, SLA.

На практике переход на внешний сервис окупается, когда:

• вы шлёте десятки тысяч и более писем в месяц на внешние домены;
• для вас критична deliverability (финтех, e-commerce, SaaS);
• команду разработки и админов не устраивает постоянная борьба с очередным провайдером, который начал резать ваш IP.

Deliverability: где выигрывают Mailgun, Sendgrid и Postmark

Качество доставки (deliverability) состоит не только из SPF, DKIM и DMARC. Большую роль играют:

• поведение получателей: жалобы на спам, открытия, клики, отписки;
• история IP: как давно он шлёт почту, с какими показателями;
• история домена: видел ли провайдер таких отправителей ранее;
• политики конкретного провайдера (Yahoo, Gmail, Outlook и т.д.).

Чем полезны облачные сервисы:

• они автоматически отслеживают жалобы и отписки, чтобы не продолжать слать письма на токсичные адреса;
• поддерживают FBL (Feedback Loop) с крупными провайдерами;
• имеют собственные внутренние метрики и лимиты для защиты от клиентов, портящих репутацию IP-пула.

Со своим Postfix всё это нужно реализовывать и мониторить самостоятельно: лог-парсеры, отчёты по bounce-ам, обработка DSN, собственная статистика открытий (если вы ей пользуетесь) и т.п.

Если хотите углубиться в сторону DMARC, BIMI и современных практик доверия к домену, посмотрите обзор: как усилить репутацию домена через DNS и DMARC.

Диагностика и логирование: где проще жить админу

С точки зрения диагностики проблем Postfix и облачные SMTP-сервисы дают разные уровни видимости и разный рабочий процесс.

Postfix

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

• полные логи в syslog или journal — можно отследить каждый шаг SMTP-сессии;
• можно хранить их столько, сколько нужно, и в том формате, который вам удобен;
• возможность гибкой настройки debug-уровней по отдельным доменам или параметрам.

Минусы:

• информация о причине отклонения часто ограничена тем, что вернул удалённый сервер;
• нужно строить свои дашборды и алерты поверх логов (Prometheus, ELK, Loki и т.д.);
• анализ bounce-ов и их классификацию вы делаете сами.

Mailgun, Sendgrid, Postmark

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

• готовый интерфейс с поиском по логам писем, статусам и причинам сбоев;
• webhooks для автоматической обработки доставок, сбоев и жалоб;
• экспорт логов в сторонние системы мониторинга через API.

Минусы:

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

Команда и компетенции: кого у вас проще найти — почтовика или API-инженера?

Решение «Postfix против Mailgun, Sendgrid, Postmark» часто упирается не только в технику и стоимость, но и в компетенции команды.

Для поддержки своего Postfix вам нужен человек, который:

• понимает SMTP-диалоги и коды ошибок;
• знает, как работают SPF, DKIM, DMARC, PTR и репутация отправителя;
• умеет разбираться с проблемами блокировок IP и списков рассылки;
• может поддерживать всё это в долгую, с учётом обновлений и изменений политик.

Для работы с Mailgun, Sendgrid или Postmark вам нужен человек, который:

• умеет интегрировать API и webhooks в приложение;
• понимает базовые вещи по DNS (SPF, DKIM, DMARC), но не обязательно является глубоким почтовиком;
• способен интерпретировать метрики deliverability и оптимизировать рассылки.

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

Практические сценарии выбора

Сценарий 1: Небольшое SaaS или веб-приложение, до 10–20 тысяч писем в месяц

Задачи:

• подтверждение e-mail;
• сброс пароля;
• уведомления о событиях.

Что выбрать:

• Postfix и внешний сервис как relay — хороший компромисс: приложения шлют на localhost, а дальше Postfix уходит в Mailgun, Sendgrid или Postmark. Если объём совсем маленький, можно слать напрямую через API без Postfix.
• полностью свой Postfix имеет смысл только если у вас очень жёсткий бюджет или регуляторные ограничения на использование внешних сервисов.

Сценарий 2: Крупный e-commerce, десятки и сотни тысяч писем

Задачи:

• рассылки по базе пользователей (промо, дайджесты);
• транзакционные уведомления о заказах, статусах и доставке;
• очень жёсткие требования к доходности писем.

Что выбрать:

• облачный сервис в качестве основного канала доставки маркетинговых и транзакционных писем;
• свой Postfix для служебной и внутренней почты, алертов и технических нотификаций;
• возможен выделенный IP-пул у провайдера для важных доменов.

Попытка тащить такую нагрузку на одном-двух своих Postfix без серьёзных компетенций в deliverability почти гарантированно закончится проблемами с доставкой.

Сценарий 3: Внутренние сервисы и корпоративная почта

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

Здесь важнее:

• надёжность и резервирование;
• интеграция с внутренними системами аутентификации и каталогами;
• контроль над данными и перепиской.

Deliverability во внешний мир в этом случае вторична и может быть решена, например, отдельным шлюзом или ограниченным использованием внешнего сервиса.

Итого: как выбирать между Postfix и Mailgun, Sendgrid, Postmark

Чтобы не утонуть в деталях, можно свести выбор к нескольким ключевым вопросам:

1. Сколько писем вы шлёте во внешний мир и как быстро это будет расти?
2. Насколько критична доставляемость (deliverability) именно сейчас?
3. Есть ли у вас в команде человек, который реально понимает SMTP и почтовую репутацию?
4. Готовы ли вы инвестировать время в постоянную поддержку собственной MTA-инфраструктуры?
5. Насколько для вас важен контроль над данными и независимость от вендора?

Упрощённый ориентир:

• малые и средние проекты с внешней рассылкой — чаще всего выигрывают от использования Mailgun, Sendgrid или Postmark (через API или через Postfix как relay);
• проекты с высокой чувствительностью к данным и регуляторике — нередко строят свой Postfix, иногда с частичным использованием внешних сервисов под неперсональные рассылки;
• чисто внутренняя почта и служебные уведомления — традиционная зона Postfix без внешних сервисов.

При этом полностью отказываться от Postfix на стороне приложения не всегда разумно. Он остаётся удобным локальным SMTP-шлюзом, за которым можно спрятать реальную сложность: менять relayhost, добавлять фильтры, строить очереди и fallback-ы, не трогая код приложений.

Оптимальная стратегия для большинства команд — начинать с внешнего сервиса (получить нормальную deliverability и сокращение трудозатрат), а уже затем, по мере роста, строить вокруг него свою MTA-архитектуру на базе Postfix, если появляются специальные требования по контролю, логированию или маршрутизации. А инфраструктуру под это проще держать на надёжном облачном VDS или использовать готовый виртуальный хостинг с поддержкой почты, если задачи скромнее.