Mailgun vs Postmark vs SES для транзакционной почты

Какую проблему пытаются решить команды

Большинство команд начинают сравнивать почтовых провайдеров после того, как маленький сбой превращается в обращение в support. Сброс пароля приходит через 20 минут. Квитанция так и не появляется. Код для входа попадает в спам. Пользователям не важно, какой сервис отправил письмо. Они думают, что сломался ваш продукт.

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

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

Понятные event logs помогают команде проследить одно письмо без догадок. Предсказуемые retry не дают временным сбоям превращаться в потерянных пользователей. Лучше попадание во входящие означает меньше тикетов с текстом «Я так и не получил письмо для сброса пароля».

Даже небольшое SaaS-приложение чувствует это очень быстро. Один неудачный reset пароля может убить пробный период. Несколько пропавших receipts могут создать проблемы в финансах. Нечёткое сообщение о bounce может съесть полдня у разработчика, который вместо этого должен был делать продукт.

Когда вы сравниваете Mailgun, Postmark и SES, на минуту забудьте про голое количество функций. Лучше спросите о практичном: какой сервис даёт вашей команде достаточно контроля над доставкой, понятный процесс отладки и такую email-операционку, которую можно поддерживать без найма отдельного специалиста по почте?

Чем эти три сервиса отличаются в общих чертах

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

Postmark чаще всего подходит командам, которые хотят как можно более плавный старт. Он узко сфокусирован на транзакционной почте, поэтому продукт специально кажется простым. Для password reset, receipts, login alerts и похожих сообщений приложения это часто самый лёгкий вариант для запуска и понимания.

Mailgun подходит командам, которым нужно больше пространства для настройки отправки, но без построения всей почты с нуля. Он даёт больше параметров и больше способов управлять routing, доменами и более широким использованием email. Такая свобода помогает, когда приложение растёт, но за неё приходится платить временем на изучение продукта.

Amazon SES подходит командам, которым комфортно работать ближе к инфраструктуре, особенно если большая часть стека уже живёт в AWS. SES даёт много контроля и часто более низкую стоимость отправки на больших объёмах, но ощущается менее направляющим, чем Postmark. Обычно вам нужно связывать больше частей самим — от мониторинга до отдельных элементов support и отладки.

Небольшие команды быстро чувствуют разницу. Postmark меняет гибкость на ясность и скорость. Mailgun находится посередине. SES даёт самый прямой контроль, но и требует больше всего от команды.

Кривая обучения идёт тем же порядком. Postmark осваивается легче всего. Mailgun требует больше чтения и тестов. SES лучше всего работает, когда в команде уже понимают AWS, DNS и базовые принципы репутации отправителя.

Вот и весь компромисс. Более простой сервис скрывает больше сложности. Более гибкий сервис оставляет больше решений и больше обслуживания на вашей стороне.

Контроль доставки в реальной работе

Контроль доставки начинается с обычной настройки. Вы подтверждаете домен, добавляете SPF и DKIM и обычно настраиваете политику DMARC, чтобы почтовые сервисы доверяли вашим письмам. Это важнее, чем название бренда. Если DNS устроен неаккуратно или приложение смешивает receipts с массовой почтой, даже хороший сервис для транзакционных писем будет буксовать.

Эти три провайдера отличаются тем, сколько контроля они дают после этой настройки.

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

Mailgun даёт больше свободы для разделения доменов, маршрутов и правил отправки. Вы можете настраивать, как разные приложения отправляют письма, но при этом появляется больше параметров, которые нужно поддерживать, и больше решений, к которым придётся возвращаться позже.

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

Shared sending и dedicated sending звучат драматичнее, чем есть на самом деле. В общем пуле ваша почта уходит вместе с письмами других клиентов, а провайдер следит за здоровьем этого пула. Для password reset, invoice и account alerts это часто нормально. На выделенном IP вы строите свою собственную репутацию. Это полезно только тогда, когда вы отправляете достаточно писем и делаете это стабильно, чтобы появилась понятная история. Если объём низкий, выделенный IP может даже ухудшить результат.

Вот где выбор перестаёт быть вопросом списка функций и становится вопросом времени команды. Postmark даёт меньше свободы, но его настройки по умолчанию хорошо подходят многим SaaS-продуктам. Mailgun имеет смысл, когда вам нужен больший контроль над доменами, поведением suppression и разделением трафика. SES подходит командам, которые уже живут в AWS и не против делать больше почтовой работы сами.

Дополнительный контроль помогает, когда у вас несколько продуктов, отправка идёт с нескольких доменов или нужно изолировать репутацию одного приложения от другого. Он добавляет работы, когда всё приложение отправляет только welcome emails, receipts и reset links. В таком случае важнее чистая аутентификация, suppression list, который блокирует bounced адреса, и стабильная отправка, чем продвинутая настройка.

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

Как выглядит отладка, когда с письмом что-то не так

Первый вопрос простой: приложение не смогло передать письмо или провайдер принял его, а потом позже отложил, отклонил, заблокировал или убрал в suppression? Хорошая отладка начинается с одного message ID, который проходит от логов приложения до почтового провайдера. Без этого ID любой dashboard кажется запутанным.

Postmark обычно легче всего читать в напряжённой ситуации. Можно найти получателя или сообщение, открыть activity record и быстро увидеть, было ли письмо отправлено, доставлено, отклонено или заблокировано правилом suppression. Подробности о complaint и bounce тоже легко найти, поэтому разработчик часто может проследить жалобу пользователя за несколько минут.

Mailgun тоже даёт хорошие данные по событиям, включая поиск сообщений, event logs и webhooks, которые показывают полный след. У него часто больше ручек, чем у Postmark, и это полезно, когда нужна детализация, но компромисс в том, что приходится чуть глубже копаться в dashboard и собственных логах. Если ваша команда уже сохраняет webhook payload, работать с Mailgun становится заметно проще.

SES может быть быстрым, но только если вы хорошо его настроили. Из коробки путь отладки часто проходит через SES, configuration sets и event destinations вроде SNS или EventBridge. Для команды, которая живёт в AWS, это нормально. Для всех остальных это может ощущаться как погоня за одним письмом через три разных консоли.

Как выглядит неудачная отправка на практике

Обычно путь такой:

1. В логах приложения появляется «accepted», и сохраняется message ID провайдера.
2. Вы ищете этот ID в Postmark, Mailgun или в вашем SES event pipeline.
3. Проверяете следующее событие: delivered, deferred, bounced, complaint или suppressed.
4. Читаете причину и решаете, нужно ли повторить отправку, исправить контент или остановить отправку.

Тестовые инструменты важнее, чем думают многие команды. У Postmark есть test server, который хорошо подходит для безопасного тестирования приложения. У Mailgun есть sandbox и test mode, которые помогают во время настройки и базовой проверки процесса. У SES есть sandbox для настройки аккаунта и mailbox simulator для проверки bounce, complaint и результатов доставки без реальных inbox.

Replay — слабое место у всех трёх. Ни один сервис не заменит нормальную систему повторных попыток внутри вашего приложения. Postmark упрощает ручную проверку, Mailgun даёт хороший доступ к событиям, а SES лучше всего подходит, когда вы уже повторно запускаете задачи из собственной очереди и храните историю событий внутри AWS.

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

Операционная нагрузка для небольшой команды

Небольшие команды редко застревают на API-вызове. Они застревают на рутине вокруг него: DNS-записи, ротация секретов, очистка bounce и попытка понять, какое приложение отправило плохое письмо в 2 часа ночи.

Для ежедневной работы Postmark обычно самый удобный. Mailgun находится посередине. SES на больших объёмах может стоить дешевле, но требует больше настройки в AWS и больше аккуратности от команды.

DNS — первое препятствие. Всем трём нужны подтверждение домена, SPF и DKIM. SES часто занимает больше времени, потому что вы ещё работаете с идентичностями AWS, регионами и правилами IAM. Mailgun и Postmark обычно кажутся проще для маленькой команды, которой нужен один домен для production и другой для staging.

Управление доступами становится сложным, когда есть web app, worker и staging-среда. Postmark решает это аккуратно с отдельными servers и token. Mailgun тоже может оставаться организованным, но команде нужно более осознанно относиться к доменам, API key и доступам. SES даёт очень точный контроль через IAM users и roles — это хорошо для безопасности, но небольшие команды платят за это временем настройки.

Мониторинг и обработка bounce создают самую большую разницу после запуска. У Postmark есть дружелюбная история событий, понятные webhook events и простые экраны по bounce. Mailgun даёт сильные логи и данные по событиям, но процесс может ощущаться тяжелее, когда вы управляете несколькими приложениями. SES часто требует дополнительной связки через SNS, CloudWatch или собственные инструменты, прежде чем отладка станет удобной.

Управление шаблонами тоже влияет на ежедневную работу. Postmark хорошо подходит, если шаблоны должны редактировать коллеги, которые не пишут код, не трогая само приложение. Mailgun тоже поддерживает шаблоны, но многие команды всё равно оставляют больше логики шаблонов в кодовой базе. С SES команды часто строят больше вокруг шаблонов, особенно если несколько приложений отправляют разные типы писем.

Если у вас несколько приложений, появляется ещё один слой. Если один продукт отправляет receipts, другой — login codes, а staging ни в коем случае не должен касаться реальных пользователей, Postmark делает такое разделение очень наглядным. Mailgun справляется, но нужны правила именования и дисциплина. SES тоже может это сделать, хотя настройка растёт быстрее, чем ожидают многие команды из двух человек.

Если смотреть на постоянное обслуживание, расклад довольно понятный. Postmark требует меньше всего присмотра, Mailgun — умеренно, а SES — больше всего, если только ваша команда уже не проводит много времени в AWS и не имеет хорошего мониторинга.

Практичный способ выбрать

Начните с того, как у вас реально устроена почта, а не с прайсинга. SaaS-приложение, которое отправляет login codes, receipts и password resets, имеет другие потребности, чем сервис, который рассылает миллионы account alerts каждый день. Посчитайте месячный объём, пиковые всплески и типы сообщений, которые вы не можете позволить себе потерять.

Лучше работает короткий процесс принятия решения, чем огромная таблица функций:

1. Разделите почту по группам. Поместите password resets, magic links, invoices, invites и system alerts в разные корзины. Так станет понятно, нужен ли вам строго транзакционный сервис или что-то более широкое.
2. Запишите, какие логи нужны команде ещё до первой поломки. Большинству команд нужны поиск сообщений, события доставки, причины bounce, история suppression, webhook events и raw headers. Если ваша команда не может быстро ответить на вопрос «мы отправили письмо, сервер получателя его принял и что сломалось дальше?», support будет страдать.
3. Выберите свой рабочий стиль. Если команде хочется меньше настройки и более понятных значений по умолчанию, обычно выигрывает управляемая простота. Если команда готова связывать между собой мониторинг, retries, права доступа и дополнительный tooling, прямой контроль может того стоить.
4. Проведите короткий пилот на реальном трафике. Возьмите один поток сообщений или одну часть продукта на две–четыре недели. Измеряйте обработку bounce, обработку complaint, время на диагностику неудачного письма, надёжность webhooks и то, сколько времени команда тратит на поддержку системы.

Стоимость по-прежнему важна, но она должна идти после соответствия задачам. Более дешёвый сервис может обойтись дороже, если инженеры тратят часы на поиск пропавших событий или support не может объяснить, почему клиент не получил receipt.

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

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

Простой пример на основе SaaS-приложения

Представьте небольшое SaaS-приложение с тремя важными письмами каждый день: подтверждение регистрации, ежемесячные счета и сброс пароля. В команде два разработчика и один человек в support. Когда клиент говорит: «Я так и не получил счёт», support не нужен длинный урок про email. Нужен быстрый ответ.

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

С Postmark разработчик обычно открывает исходящий поток сообщений и ищет получателя. Первые проверки простые и рядом друг с другом: sent, delivered, bounced, complaint или suppression. Если счёт попал под блокировку, support часто может сразу ответить понятной причиной.

С Mailgun разработчик ищет в логах и событиях тот же адрес. Смотрят на accepted, delivered, temporary failure, bounce, complaint или suppressed recipient. Плюс в том, что есть больше контроля и больше деталей. Минус в том, что ответ может занять больше времени, когда команде нужно разбираться в дополнительных настройках и истории событий.

С Amazon SES первая проверка часто происходит вне dashboard SES, если команда заранее не настроила публикацию событий как следует. Разработчику, возможно, придётся смотреть в логи приложения, CloudWatch, уведомления SNS, account suppression list и verified identity. SES может работать очень хорошо, но пропавший счёт часто превращается в небольшую операционную задачу.

На практике support-путь обычно выглядит так: Postmark — поиск получателя, чтение статуса, ответ клиенту. Mailgun — поиск получателя, просмотр цепочки событий и проверка suppression. SES — подтверждение, что приложение отправило письмо, а затем трассировка событий и suppression через инструменты AWS.

Для этой команды Postmark, вероятно, был бы лучшим вариантом. Их письма транзакционные, support нужны быстрые ответы, а команда маленькая. SES может быть дешевле на больших объёмах, Mailgun даёт больше контроля, но Postmark делает проблему со счётом короткой и скучной. Обычно это лучший исход.

Типичные ошибки, которые допускают команды

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

Цена важна, но важны и усилия на обслуживание. Многие недооценивают часы, которые уходят на настройку, мониторинг, проверку DNS, обработку webhooks и очистку репутации, когда что-то ломается.

Ещё одна частая ошибка — отправлять всё через одну и ту же настройку. Password resets, invoices, welcome emails, promo campaigns и product updates ведут себя по-разному. Если маркетинговый трафик тянет вниз репутацию отправителя, транзакционная почта может начать сбоить в самый плохой момент, например, когда пользователю нужен login code.

Одни и те же ошибки повторяются снова и снова. Команды игнорируют bounce и spam complaints, пока клиенты не начинают спрашивать, почему письма перестали приходить. Они держат маркетинговый и транзакционный трафик на одном домене или одном пути отправки, потому что так кажется проще. Они выбирают самую низкую цену в списке, не считая время поддержки и инженерную работу. Они считают, что самый дешёвый вариант останется самым дешёвым, даже если прибавить дополнительный tooling, alerts и уборку после проблем.

Скрытая стоимость обычно сидит в email operations, а не в счёте. SES — хороший пример. Стоимость отправки может выглядеть крошечной, но небольшая команда может потратить куда больше времени на управление правилами доступа, event pipeline, suppression logic и шагами отладки, чем ожидала. Postmark часто стоит дороже за сообщение, но многие команды компенсируют это более быстрой диагностикой. Mailgun во многих настройках оказывается посередине, особенно когда команде нужна большая гибкость без создания почти всей инфраструктуры вокруг сервиса.

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

Короткий чеклист перед выбором

Сервис транзакционной почты может выглядеть почти одинаково на странице с ценами. Разница проявляется тогда, когда reset пароля приходит поздно, receipt не доходит или команда не может понять, где именно произошёл сбой. Перед выбором проверьте то, на что будете опираться каждую неделю.

• Настройте SPF, DKIM и, если возможно, DMARC на реальном тестовом домене. Затем отправьте письма с того же шаблона адреса, который планируете использовать в production. Хорошая доставляемость начинается с аутентификации отправителя, а не с логотипа поставщика.
• Откройте event log и проследите одно сообщение от действия в приложении до финального результата. Если вам часто приходится разбираться с bounce, задержками, complaint или блокировками, убедитесь, что провайдер показывает эти события понятно и быстро.
• Проверьте письма, которые люди замечают первыми: password resets, receipts, invite emails и security alerts. Посмотрите скорость доставки, форматирование, имя отправителя, поведение reply и то, попадает ли письмо во входящие или в спам.
• Назначьте ответственного за мониторинг и дальнейшие действия. Кто-то должен смотреть за failed webhooks, suppression lists, предупреждениями о квоте и резкими падениями доставки, даже если продукт маленький.

Проведите одну полную репетицию до запуска. Отправьте reset, сделайте тестовую покупку и пошлите alert в несколько разных inbox, например Gmail, Outlook и корпоративный домен. Потом задайте себе три простых вопроса: отправило ли приложение письмо, принял ли его провайдер и куда его положил почтовый сервис получателя?

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

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

Если вам нужен самый короткий путь к надёжной отправке, Postmark часто оказывается самым удобным вариантом. Если вашей команде нужен больший контроль и важны собственные маршруты, Mailgun даёт больше пространства. Если цена важнее удобства и команда готова к более сложной настройке, SES обычно становится практичным выбором.

Не меняйте провайдера вслепую. Email затрагивает больше частей приложения, чем многие ожидают. Password resets, receipts, invite flows, retry logic, очереди неудачных задач, обработка bounce и support logs — всё это зависит от того, как ваше приложение отправляет и отслеживает сообщения. Если вы меняете провайдера, пересмотрите worker очередей, обработку webhooks, alerts и то, как команда проверяет проблемы с доставкой.

Небольшой план миграции работает лучше, чем резкое переключение:

• Составьте карту всех типов писем, которые отправляет приложение, и расставьте их по уровню риска.
• Перенесите сначала один малорисковый поток, например приглашения в аккаунт или login codes.
• Следите за метриками успеха одну–две недели: delivery rate, bounce rate, complaint rate, временем отправки и временем на отладку неудачного письма.
• Оставьте старого провайдера активным на время теста, чтобы можно было быстро откатиться.
• Переносите billing, password reset и другие чувствительные потоки только после того, как первая часть стабильно работает.

Для большинства небольших SaaS-команд хороший результат выглядит скучно. Тикетов о пропавшей почте становится меньше. Инженеры быстро находят неудачные сообщения. DNS-записи понятны. Мониторинг показывает очередь, ошибки webhooks и проблемы доставки, не заставляя команду копаться в трёх разных инструментах.

Если ваш email-стек уже кажется запутанным, провайдер, скорее всего, только часть проблемы. Часто это указывает на более широкую проблему в архитектуре приложения: очереди, наблюдаемость, retries и ответственность. Олег Сотников из oleg.is работает как внештатный CTO и советник для стартапов, и именно в таких случаях внешний архитектурный разбор может сэкономить небольшой команде очень много времени.