Управляемая отправка является разумным вариантом по умолчанию, а собственный SMTP служит альтернативой. При управляемой отправке другой оператор следит за репутацией IP, списками блокировки и циклами обратной связи и реагирует, если общий IP попадает в такой список глубокой ночью. Для большинства отправителей это выгоднее, чем заниматься всем самостоятельно.
При собственном SMTP исходящая почта направляется через вашу учетную запись Amazon SES, SendGrid, Mailgun или Postmark. Этот вариант действительно лучше в трех конкретных ситуациях. Его также нередко выбирают по двум причинам, которые при проверке оказываются ошибочными.
Разберем, к какой группе относитесь вы и как работает маршрутизация собственного SMTP для каждого домена.
Что в действительности меняет собственный SMTP
Меняется только исходящий маршрут. Входящая почта по-прежнему поступает на наши серверы через ваши записи MX, проходит фильтрацию и попадает в тот же ящик. Изменяется последняя точка передачи при отправке: вместо нашей инфраструктуры сообщение после аутентификации передается вашему поставщику.
Все дальнейшее становится его зоной ответственности: IP-адреса, репутация, ограничения скорости, обработка возвратов и список подавления. Вы заменяете одного оператора другим и принимаете на себя отношения с новым поставщиком.
На вашу сторону переходят следующие задачи:
| Вопрос | Управляемая отправка | Собственный SMTP |
|---|---|---|
| Репутация IP | Поддерживаем мы | Принадлежит поставщику и зависит от вашей активности |
| Ограничения скорости | Дневные и часовые лимиты тарифа | Лимиты вашего поставщика |
| Обработка возвратов и жалоб | Обрабатывается и отображается в панели | Консоль и вебхуки поставщика |
| Удаление из списков блокировки | Занимаемся мы | Занимаетесь вы вместе с поставщиком |
| Стоимость сообщения | Включена | Выставляется поставщиком |
Три веских причины использовать собственный SMTP
1. Объем выше предусмотренного тарифом. Лимиты тарифов доходят до нескольких тысяч сообщений на ящик в день. Если ежемесячно отправляются сотни тысяч транзакционных сообщений, специализированный поставщик обычно дешевле и лучше приспособлен к задаче. Не стоит пропускать массовую нагрузку через платформу почтовых ящиков.
2. У вас уже налажены отношения с поставщиком. Если приложение отправляет чеки и сбросы паролей через SES с прогретым выделенным IP, маршрутизация почты сотрудников через тот же сервис объединит репутацию вместо разделения между двумя отправителями. Станет меньше компонентов и останется одна консоль для поиска проблем.
3. Вы используете Nano. В Nano нет управляемой отправки, поэтому собственный SMTP является предусмотренным способом отправки, а не обходным решением.
Две неубедительные причины
«Я улучшу доставляемость». Обычно нет, а сначала нередко происходит обратное. Общий пул зрелого поставщика имеет репутацию, сформированную тысячами отправителей. У новой дополнительной учетной записи SES ее нет: вы начинаете с нуля, и крупные получатели считают вас неизвестным отправителем, пока не появится история. Если объема недостаточно для прогрева и поддержания выделенного IP, устоявшаяся репутация меняется на пустую.
«Я хочу обойти лимиты отправки». Лимиты существуют потому, что большой объем с молодого домена похож на взломанную учетную запись, и получатели реагируют соответственно. Другой маршрут не меняет оценку Gmail для домена, который внезапно отправляет десять тысяч сообщений. Поставщик все равно применит собственный график увеличения и может при превышении приостановить учетную запись. Отменить такую блокировку вручную сложнее, чем дождаться снятия ограничения скорости. См. лимиты отправки и прогрев домена.
Собственный SMTP по доменам и повторно используемые профили
Собственный SMTP настраивается отдельно для каждого домена, что дает больше гибкости, чем может показаться.
Каждый домен указывает свой исходящий маршрут. Один может передавать почту через SES, другой использовать управляемую отправку, а третий совершенно иного поставщика. Агентство может предоставить клиенту его собственную инфраструктуру, не меняя настройки остальных.
Учетные данные сохраняются в виде профилей учетной записи, а не вводятся для каждого домена. Добавьте SES один раз и привяжите профиль к любому числу доменов. При ротации учетных данных они меняются в одном месте. Если ввести одинаковые данные шесть раз, пять копий легко оставить устаревшими.
Настройка: откройте вкладку SMTP домена, выберите сохраненный профиль собственного SMTP или создайте новый с именем хоста, портом, именем пользователя и паролем. Перед сохранением выполните проверку. Она открывает реальный сеанс SMTP и проходит аутентификацию. Не пропускайте ее: непроверенные данные могут отказать именно при отправке важного сообщения, и ошибку увидит пользователь, а не вы.
Часть с DNS, о которой часто забывают
Собственный SMTP меняет серверы, отправляющие почту от имени домена, и это должно быть отражено в DNS. Иначе аутентификация каждого сообщения завершится ошибкой.
SPF должен включать нового отправителя. Поставщик публикует механизм include, например include:amazonses.com, include:sendgrid.net или аналогичный. Его нужно добавить в существующую запись, а не публиковать второй. Две записи SPF на одном домене образуют недопустимую конфигурацию, и обе перестают работать.
Следите за лимитом запросов. SPF разрешает десять DNS-запросов. Каждый include расходует минимум один, а включения поставщиков часто бывают вложенными. При добавлении третьего отправителя домен может незаметно превысить лимит, после чего запись будет возвращать постоянную ошибку. См. ограничение запросов SPF.
Теперь DKIM предоставляет поставщик. Он подписывает исходящую почту собственным ключом, поэтому его запись DKIM должна существовать рядом с нашей. Большинство поставщиков выдают для публикации два или три CNAME. Почта, отправленная через них, но подписанная только нами, не пройдет DKIM.
Выравнивание DMARC по-прежнему должно работать. DMARC требует, чтобы SPF или DKIM был выровнен с видимым доменом From. Если поставщик подписывает своим доменом, а не вашим, DKIM пройдет, но выравнивание и DMARC завершатся ошибкой. Это одна из наиболее частых проблем миграции на собственный SMTP, которая остается незаметной до получения отчетов. См. выравнивание DMARC.
Настольные клиенты требуют отдельного решения
Маршрутизация собственного SMTP применяется к письмам из веб-почты или через наш API. Настольный клиент передает сообщение непосредственно тому SMTP-серверу, который в нем настроен.
Есть два разумных варианта. Направить клиентов к нам и применять маршрут домена, чтобы изменения выполнялись в одном месте. Либо направить клиентов напрямую поставщику, убрав одну точку передачи и немного ускорив путь.
Не стоит смешивать оба способа. Два исходящих маршрута дают два набора результатов аутентификации и два места для поиска пропавшего сообщения, а со временем сложно вспомнить, какой компьютер как настроен.
За что теперь отвечаете вы
Обработка возвратов. Жесткие возвраты у поставщика нужно подавлять у него же. Панель показывает наблюдения нашей инфраструктуры, но не видит его очередь.
Цикл обратной связи по жалобам. Жалобы на спам получает владелец отправляющего IP. Настройте у поставщика их пересылку или хранение и регулярно просматривайте. Рост доли жалоб является ранним предупреждением о возможном ухудшении доставляемости.
Ротация учетных данных. Просроченный пароль SMTP приведет к ошибке при следующей отправке. Обновите его в профиле и подтвердите кнопкой проверки до того, как проблему заметят пользователи.
Собственные правила поставщика. SES начинает работу в песочнице, из которой можно писать только на подтвержденные адреса. Для выхода требуется запрос в поддержку с описанием сценария. Это может неожиданно проявиться в середине пятничной миграции.
Часто задаваемые вопросы
Меняет ли собственный SMTP получение почты?
Нет. Меняется только исходящий маршрут. Входящая почта по-прежнему поступает через MX на наши серверы, проходит те же фильтры и попадает в тот же ящик.
Могут ли разные домены использовать разных поставщиков SMTP?
Да. Собственный SMTP настраивается по доменам: один может работать через SES, другой использовать управляемую отправку. Учетные данные сохраняются как повторно используемые профили уровня учетной записи.
Улучшит ли собственный SMTP доставляемость?
Сам по себе нет, а вначале часто наоборот. Новая дополнительная учетная запись поставщика начинает без репутации. Польза появляется, если объем позволяет прогревать и поддерживать выделенный IP или если у вас уже есть налаженные отношения с отправляющим сервисом.
Нужны ли мне записи SPF и DKIM?
Они еще важнее. SPF include поставщика нужно объединить с существующей записью, а его записи DKIM опубликовать. Почта через него, подписанная только нами, не проходит DKIM, а невыровненная подпись не проходит DMARC.
Убирает ли собственный SMTP лимиты отправки?
Вместо наших применяются лимиты поставщика. Его требования к постепенному росту обычно строже, а превышение может привести к приостановке учетной записи вместо ограничения скорости.
Что произойдет при сбое у поставщика?
Исходящая почта доменов на этом маршруте не будет отправляться до восстановления сервиса. Управляемая отправка не служит резервом: домен использует настроенный для него маршрут.
Нужен ли собственный SMTP на тарифе Nano?
Да. Nano не включает управляемую отправку, поэтому исходящая почта на этом тарифе отправляется через собственный SMTP.
Можно ли настроить собственный SMTP через API?
Да. Профили собственного SMTP и маршрутизация по доменам доступны через REST API и MCP, включая проверку соединения.
