SMTP relay: SendGrid vs Amazon SES vs Mailgun

Вам нужно отправлять письма в объёме. Не через Outlook и не через встроенный почтовик хостинга, который упирается в 500 писем в сутки. Нужен SMTP-релей, то есть сервис, который принимает ваши письма и доставляет их через инфраструктуру, собранную под большие объёмы. В любом разговоре всплывают три имени: SendGrid, Amazon SES, Mailgun. Задачу они решают одну и ту же, но делают это достаточно по-разному, чтобы неверный выбор потом стоил месяцев переезда.

Кто кому подходит

SendGrid — когда нужна рабочая инфраструктура без глубокого погружения в DevOps. Маркетинговые команды, SaaS- продукты на ранней стадии, компании без выделенного инженера по email. Подключили, настроили DNS-записи, отправляете. Минус: на объёмах свыше миллиона писем начинаете платить за удобство заметно больше, чем конкуренты берут за аналогичную пропускную способность.

Amazon SES — когда объёмы большие, бюджет ограничен, а в команде есть инженеры, знакомые с AWS. Финтех, e-commerce с миллионами транзакционных уведомлений, платформы с user-generated email. Стоимость на порядок ниже. Но всю обвязку — мониторинг, алерты, обработку bounce — строите сами.

Mailgun — когда важен баланс между удобством и контролем. Разработчики, которые ценят чистый API, но не хотят разворачивать SNS-топики и лямбды. Средние объёмы, необходимость inbound-парсинга, европейские данные. На больших масштабах уступает SES по цене, но экономит инженерные часы.

Что общего у всех трёх

Ни один из этих сервисов не решает проблему качества списка. SendGrid, SES и Mailgun — это транспорт. Они доставляют то, что вы им дали. Если в базе 20% невалидных адресов, relay послушно отправит все двадцать процентов, получит bounce, зафиксирует жалобы — и ваша репутация домена пойдёт вниз. При этом сам сервис может заблокировать ваш аккаунт за высокий bounce rate. SendGrid делает это автоматически. SES снижает sending quota. Mailgun присылает предупреждение, а потом приостанавливает отправку.

Механизм разный, результат один: грязная база ломает любой relay.

SMTP relay — это труба. Если в трубу заливать мусор, на выходе будет мусор. Качество списка определяет результат больше, чем выбор конкретного сервиса.

Подводные камни при переезде

Миграция между relay-сервисами выглядит простой на бумаге: поменять SMTP-хост и креденшелы. На практике — несколько ловушек.

Первое — IP-репутация. На старом сервисе вы наработали репутацию конкретного IP-адреса. На новом — начинаете с нуля. Если берёте dedicated IP, нужен warmup. Если остаётесь на shared — зависите от соседей по пулу.

Второе — suppression lists. У каждого сервиса свой список адресов, на которые он отказывается отправлять: hard bounce, жалобы, отписки. Эти списки не переносятся между платформами. Если вы перешли с SendGrid на Mailgun и не экспортировали suppression list, Mailgun попытается доставить письма на адреса, которые SendGrid уже пометил как мёртвые. Результат — всплеск bounce rate в первые дни после миграции.

Третье — DNS. DKIM-ключи привязаны к конкретному сервису. При переезде нужно сгенерировать новые ключи, добавить их в DNS, дождаться распространения. Если забыть убрать старые DKIM-записи, DMARC-проверка может давать неожиданные результаты.

Валидация как страховка

Перед подключением к любому из трёх сервисов стоит пропустить базу через валидатор. Не потому что так принято, а потому что это прямо влияет на стоимость отправки и на сохранность аккаунта.

На SES с его $0.10 за тысячу разница не кажется большой. Но SES жёстче всех реагирует на bounce rate: порог — 5%, после которого аккаунт уходит в review, а при повторных нарушениях — блокировка. На SendGrid автоматическая приостановка аккаунта при аномальном bounce rate может произойти посреди важной рассылки. На Mailgun предупреждение придёт, но к этому моменту репутация домена уже пострадала.

Проверка базы до отправки — самый дешёвый способ сохранить аккаунт в рабочем состоянии. Дешевле, чем разбираться с тикетами в поддержке SendGrid. Дешевле, чем поднимать sending quota в SES после блокировки. Дешевле, чем прогревать новый IP с нуля.

Практические рекомендации

Не привязывайтесь к одному relay. Архитектура, в которой смена транспорта требует переписывания половины кода, — уязвимая архитектура. Абстрагируйте слой отправки: интерфейс с методами send, get_status, handle_bounce. Под капотом — конкретный провайдер. Замена провайдера — замена одной реализации.

Мониторьте bounce rate в реальном времени. Все три сервиса предоставляют webhook-события. Подключите их к алертам. Если bounce rate после очередной рассылки превысил 2% — это сигнал остановиться и проверить сегмент, а не ждать, пока сервис заблокирует аккаунт.

Разделяйте потоки. Транзакционные письма (подтверждение заказа, сброс пароля) и маркетинговые рассылки должны идти с разных поддоменов и, в идеале, через разные IP. Если маркетинговая рассылка получит жалобы, это не должно затронуть доставляемость транзакционных писем. SendGrid и Mailgun поддерживают несколько доменов из коробки. На SES это настраивается через configuration sets.

И главное: валидируйте базу перед каждой крупной отправкой. Адреса умирают быстрее, чем кажется — 20-25% базы за год. Quarterly validation — минимум. Перед миграцией на новый relay — обязательно.