Postal подняли за вечер, письма ушли в спам — разбираем причины

MAATRIX

Установка Postal действительно занимает вечер: клонировали репозиторий, подняли контейнеры, прогнали пару CLI-команд — и вот уже открывается веб-панель, в ней создан первый mail-сервер, тестовое письмо самому себе доходит. На этом моменте кажется, что задача решена: свой SMTP-сервер для рассылок готов, экономия на подписке SaaS-сервиса очевидна. А потом первая боевая рассылка на пару тысяч адресов почти целиком оседает в папке «Спам» у Gmail, Outlook и Mail.ru — и разработчик, который час назад гордился быстрым деплоем, лезет в логи в поисках, что он сделал не так. Чаще всего — ничего не сломал, просто быстрый старт и готовность к боевой отправке — это два разных состояния системы, и документация Postal об этой разнице умалчивает.

Что видно при быстром запуске Postal и почему это обманчиво

Postal — открытый почтовый сервер, написанный вокруг Rails-панели и отдельного Go-компонента, который занимается непосредственно приёмом и отправкой SMTP. Под капотом — MariaDB для хранения сообщений и метаданных, RabbitMQ как очередь заданий между веб-процессом, воркерами и SMTP-сервером. Официальный путь установки — Docker Compose: поднимаете стек, инициализируете базу командой вида postal initialize, создаёте первого администратора postal make-user, и через postal start весь набор контейнеров встаёт в рабочее состояние. Дальше — веб-интерфейс, где вы заводите организацию, внутри неё mail-сервер, а внутри него домен отправки.

Ключевой момент, который быстрый старт скрывает по своей природе: Postal не отправляет письма через чужой сервис с уже наработанной репутацией, как это делает интеграция с внешним ESP через API. Postal — это ваш собственный исходящий SMTP, и письма уходят напрямую с IP-адреса вашего сервера на MX-серверы Gmail, Outlook, Mail.ru. Это одновременно и главное преимущество self-hosted решения (полный контроль, никаких лимитов подписки, данные не покидают вашу инфраструктуру), и главная причина, по которой первая же боевая рассылка проваливается: почтовые системы получателей судят не код Postal и не качество письма, а конкретный IP-адрес и домен, с которого пришло сообщение. А у свежего IP истории нет вообще никакой.

Тестовое письмо самому себе доходит почти всегда — крупные почтовики склонны доверять единичным сообщениям на собственный же адрес получателя, особенно если вы до этого переписывались с этим ящиком. Это создаёт ложное чувство «всё настроено правильно», хотя реальная проверка начинается только при объёме в сотни и тысячи сообщений на чужие домены, где включается репутационная фильтрация.

Почему письма уходят в спам в первый же день — и это не баг Postal

Три независимые причины обычно складываются вместе, и разбираться, какая из них сработала, приходится по очереди.

Причина первая: у IP и домена нет истории. Репутационные системы Gmail (Google Postmaster Tools внутри), Microsoft SNDS и репутационные базы вроде Spamhaus строят доверие по накопленным сигналам — сколько писем ушло, какой процент отметили спамом, отвечают ли получатели, нет ли резких скачков объёма. У только что арендованного VPS с только что установленным Postal этой истории физически не может быть. С точки зрения фильтра «чистый IP, который сразу шлёт тысячу писем» неотличим от паттерна, по которому действует свежий спамер: взять новый адрес и вылить с него максимальный объём, пока не забанили. Подробно про механику этого недоверия и про то, как накопить положительную историю, — в статье про прогрев IP для рассылок: без прогрева свежий Postal-сервер попадёт в спам почти гарантированно, вне зависимости от того, насколько правильно настроен остальной стек.

Причина вторая: диапазон IP хостинг-провайдера может быть предзаражён репутацией. Многие облачные и VPS-диапазоны исторически использовались для рассылки спама массово, и часть из них у крупных почтовиков находится под повышенным подозрением независимо от того, кто конкретно арендует конкретный адрес сейчас. Иногда это доходит до того, что даже безупречно настроенный сервер стартует не с нейтральной, а с отрицательной репутации — просто потому, что предыдущий арендатор того же адреса рассылал спам, а история IP тянется за адресом, а не за вами. Перед боевым запуском стоит проверить конкретный выданный IP по спам-базам заранее, а не постфактум, когда рассылка уже провалилась; если адрес всё же оказался в чёрных списках — по шагам, что делать, разобрано в статье про восстановление репутации IP.

Причина третья: DNS-записи не готовы к моменту первой отправки. Быстрый старт Postal заводит домен в организации и показывает страницу с DNS-записями — но эта страница ничего не отправляет за вас, записи нужно вручную добавить на стороне регистратора или DNS-провайдера, и они не подхватываются мгновенно, а требуют времени на распространение и проверку. Если рассылка ушла до того, как SPF и DKIM реально стали резолвиться из интернета, — она ушла без аутентификации, и это худший возможный первый контакт с почтовым провайдером получателя.

PTR, SPF, DKIM, DMARC в Postal: что именно нужно настроить

Общая механика этих четырёх элементов — обратная запись, отправитель-политика, цифровая подпись и правило для получателей — подробно разобрана в статье про Postfix и попадание в спам, и повторять теорию здесь смысла нет. Разница в том, что у Postal своя конкретная механика, которую общая теория не описывает.

PTR — вне Postal, но обязателен. Postal сам не может выписать обратную запись — это делается на стороне провайдера, который выдал вам IP, через панель управления или тикет в поддержку. PTR должен резолвиться в тот же хостнейм, который Postal использует как HELO/EHLO при отправке (обычно это хост вашего mail-сервера в организации, например mail.example.com). Расхождение между PTR и HELO — частая причина отказов даже при формально правильных SPF и DKIM.

SPF и DKIM — Postal генерирует записи сам. Во вкладке домена в веб-интерфейсе Postal есть раздел с DNS-записями, которые нужно добавить: SPF-запись, включающая хост Postal как разрешённый источник отправки для вашего домена, и DKIM TXT-запись с уникальным селектором и сгенерированным публичным ключом — приватный ключ Postal хранит и подписывает им исходящие письма автоматически. Панель показывает статус проверки каждой записи (обнаружена/не обнаружена), но проверяет она факт резолва, а не то, что запись синтаксически безупречна для всех получателей — стоит свериться с общим разбором формата в статье про настройку SPF, DKIM и DMARC на VPS, особенно если у домена уже есть другой источник отправки (например, транзакционные письма через другой сервис) и записи нужно объединять, а не дублировать.

Return-Path и tracking-домен — специфика Postal, о которой часто забывают. Postal умеет использовать отдельный поддомен для return-path (обработки bounce-сообщений) и отдельный поддомен для трекинга открытий и кликов, если он включён. Оба указываются в настройках домена и требуют своих DNS-записей — если их не добавить, bounce-обработка и статистика открытий будут частично нерабочими, само по себе это не топит письма в спам, но лишает вас данных для управления рассылкой дальше.

DMARC — Postal не публикует его за вас. DMARC-запись создаётся вручную в DNS домена и не входит в автогенерируемый список Postal. Начинать стоит с политики наблюдения (p=none), чтобы собрать отчёты и убедиться, что легитимная почта проходит SPF и DKIM, и только потом переходить к более строгой политике — резкий переход на p=reject без периода наблюдения может неожиданно отрезать часть легитимного трафика, если в SPF-записи забыт какой-то источник отправки.

Прогрев: почему нельзя сразу слать всю базу через Postal

Даже с идеально настроенными PTR, SPF, DKIM и DMARC свежий IP всё ещё остаётся чистым листом для репутационных систем получателей — а Postal сам по себе прогрев не делает и никак не ограничивает объём по умолчанию: если в настройках mail-сервера не выставлены лимиты, ничего не мешает поставить в очередь всю базу в первый же час после установки.

Практическая логика прогрева для Postal выглядит так же, как для любого self-hosted SMTP, но с одним нюансом — Postal позволяет управлять этим через несколько mail-серверов и IP-пулы внутри одной организации:

• начинайте с малого объёма (для ориентира — низкие десятки или первые сотни писем в день, точная цифра зависит от базы и провайдера) и с самой заинтересованной части базы — тех, кто открывает письма и переходит по ссылкам чаще остальных;
• увеличивайте объём постепенно на протяжении нескольких недель, а не дней, ориентируясь на реальные метрики доставляемости, а не на календарный план;
• если Postal обслуживает и транзакционные письма (сброс пароля, уведомления), и маркетинговые рассылки — разведите их по разным mail-серверам или доменам отправки внутри Postal. Провальная маркетинговая кампания не должна тянуть за собой репутацию критичных писем о доступе в аккаунт;
• если хостинг-провайдер предоставляет несколько выделенных IP, у Postal есть механизм IP-пулов — можно закрепить конкретный домен или mail-сервер за конкретным адресом и не смешивать разные потоки на одном IP.

Подробный график прогрева по неделям, с объяснением, почему резкий скачок объёма выглядит для фильтров как признак спам-атаки, разобран в статье про прогрев IP для рассылок — механика применима к Postal без изменений, разница только в том, где именно вы настраиваете лимиты и сегментацию потоков.

Что Postal показывает в статистике, а что оставляет на вас

У Postal есть встроенный журнал сообщений — по каждому письму видно статус (доставлено, мягкий отказ, жёсткий отказ, удержано) и SMTP-ответ принимающего сервера. Это полезный диагностический инструмент: если письмо не дошло, ответ сервера получателя обычно прямо называет причину — просроченная репутация, не пройденная аутентификация, превышен лимит отправки. Не гадайте по косвенным признакам, а смотрите в этот журнал в первую очередь, как только замечаете рост отказов.

Дальше — то, что журнал показывает, но не решает автоматически:

• Список подавления (suppression list). Postal сам добавляет адрес в список подавления после жёсткого отказа или жалобы на спам и больше не пытается слать на него — но это защита постфактум, уже после того как урон репутации нанесён. Список чужих контактов, купленный или собранный давно, всё равно стоит проверять на актуальность до первой отправки, а не полагаться на то, что Postal тихо отфильтрует мёртвые адреса сам.
• Уровень жалоб на спам. Postal фиксирует bounce-статистику через собственный SMTP-диалог, но жалобы через кнопку «Это спам» в почтовом клиенте получателя доходят до вас только если настроены feedback loop с почтовыми провайдерами (там, где они вообще предлагаются) — это отдельная настройка вне коробки Postal, и без неё вы узнаёте о проблеме только по падению доставляемости, а не по прямому сигналу.
• Регистрация в программах постмастеров. Google Postmaster Tools и Microsoft SNDS — это внешние сервисы, куда стоит добавить домен и IP отдельно от Postal. Они показывают репутацию именно с точки зрения конкретного почтовика — то, что панель Postal физически не может знать, потому что у неё нет доступа к внутренним репутационным метрикам Gmail и Outlook.

Чек-лист перед первой боевой рассылкой

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

1. Проверить выданный IP по спам-базам заранее, до того как он стал вашим адресом отправки — если в базах уже есть след, договориться с провайдером о замене или начать с процедуры восстановления репутации.
2. Заказать PTR-запись через панель или поддержку провайдера, убедиться, что она резолвится в тот же хостнейм, что указан в настройках HELO у mail-сервера Postal.
3. Добавить SPF и DKIM из вкладки домена в Postal, дождаться, пока панель подтвердит их обнаружение, и отдельно проверить резолв записей публичным DNS-инструментом — не только глазами Postal.
4. Опубликовать DMARC с p=none и понаблюдать за отчётами хотя бы пару недель, прежде чем ужесточать политику.
5. Настроить return-path и tracking-домен, если планируете отслеживать открытия, клики и bounce через Postal, а не только смотреть журнал сообщений вручную.
6. Разделить транзакционные и маркетинговые потоки по разным mail-серверам или IP-пулам внутри Postal — до, а не после того, как маркетинговая рассылка потянет за собой репутацию писем о доступе в аккаунт.
7. Зарегистрировать домен и IP в Google Postmaster Tools и Microsoft SNDS, чтобы видеть репутацию глазами получателей, а не только журнал отправителя.
8. Прогреть IP постепенно, начиная с малого объёма на самой заинтересованной части базы, и только затем выходить на плановые объёмы.
9. Прогнать тестовое письмо через внешний диагностический сервис (не только на собственный ящик) прямо перед стартом кампании — это последняя проверка, которая ловит то, что панель Postal не показывает.

Пункты 1-5 закрывают техническую готовность и делаются один раз при настройке домена. Пункты 6-9 — это уже про дисциплину эксплуатации, и именно её выпускают в первую очередь, когда экономят время на быстром старте.

Частые вопросы