Два продукта слали с одного IP: жалобы на один убили доставку второго

MAATRIX

Два разных продукта, один почтовый сервер, один исходящий IP — типичная экономия на инфраструктуре, пока всё работает. А потом у одного из продуктов резко растут жалобы на спам, и вслед за ним в спам начинает улетать вообще всё, что уходит с этого IP, включая письма второго продукта, у которого с настройками всё в порядке. Разбираем именно такой инцидент: что видели саппорт и логи, какие версии проверили и отбросили, где на самом деле была причина и что изменили в инфраструктуре, чтобы это не повторилось.

Что случилось: одна инфраструктура, два продукта, один IP

Ситуация типична для растущей компании. Есть основной продукт — назовём его продукт A, SaaS-сервис с транзакционными письмами: подтверждение регистрации, сброс пароля, чеки об оплате, уведомления о событиях в аккаунте. И есть второй продукт — продукт B, отдельное направление той же компании, с собственной email-рассылкой для подписчиков: дайджесты, акции, реактивационные письма для тех, кто давно не открывал сообщения.

Технически оба продукта отправляли почту через один и тот же почтовый релей на одном VPS, с одного исходящего IP и одной PTR-записи. Домены у продуктов разные, SPF и DKIM настроены отдельно для каждого домена, DMARC стоит в режиме p=quarantine. На бумаге всё выглядело правильно — валидная аутентификация, разные домены, разные DKIM-селекторы. Экономия была в другом: один сервер, один IP, одна очередь Postfix на двоих, потому что так проще администрировать и дешевле по ресурсам.

В конце августа 2026 года в течение одной недели саппорт продукта A начал получать обращения: пользователи не получают письма для сброса пароля. Ни одного релиза в это время у продукта A не было — код не менялся, конфигурация SMTP не трогалась, домен не переезжал. То есть с точки зрения продукта A ничего не происходило, а доставляемость почты просела.

Что видели в логах и метриках

Первым делом посмотрели на сторону отправителя — очередь и логи Postfix.

mailq
postqueue -p | tail -n 40
grep "to=<" /var/log/mail.log | grep "producta.example" | tail -n 100

Картина была неоднородной, и это сразу спутало версии. Часть писем действительно отбивалась с явными кодами:

postfix/smtp[18422]: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[...]:25,
  delay=1.2, status=deferred (host gmail-smtp-in.l.google.com said: 421-4.7.0
  [TEMPFAIL] Our system has detected an unusual rate of unsolicited mail...)

А часть писем логировалась как успешно принятые:

postfix/smtp[18455]: to=<user@outlook.com>, relay=outlook-com.olc.protection.outlook.com[...]:25,
  delay=0.8, status=sent (250 2.0.0 OK ...)

Именно вторая группа сначала сбивала с толку: в логе отправителя стоит 250 2.0.0 OK — почтовый сервер принял письмо и не сообщил об ошибке. Но пользователи всё равно не видели этих писем ни во «Входящих», ни в «Спаме» первое время, а часть находилась в спам-папке. Это нормальное поведение крупных провайдеров: они могут принять письмо на этапе SMTP-диалога, а решение о папке и видимости принять позже, на основе репутационной оценки — и это решение никак не отражается в логе отправителя. Поэтому смотреть только на mail.log со стороны своего сервера недостаточно — он показывает лишь то, что происходило на этапе передачи, а не судьбу письма дальше.

Проверили заголовки одного из «застрявших» писем, которое пользователь всё же нашёл в папке «Спам» и переслал в саппорт:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@producta.example header.s=default;
  spf=pass (google.com: domain of noreply@producta.example designates ... as permitted sender);
  dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=producta.example

И вот это было ключевой зацепкой: DKIM проходит, SPF проходит, DMARC проходит. С точки зрения аутентификации письмо абсолютно легитимно. Значит, проблема не в том, что письмо подделано или неправильно подписано — она в чём-то другом, что стоит уровнем выше аутентификации.

Какие гипотезы отбросили

Первая версия — сломалась подпись DKIM или устарел ключ. Проверили вручную:

dig txt default._domainkey.producta.example +short
opendkim-testkey -d producta.example -s default -k /etc/opendkim/keys/producta.example/default.private -vvv

Ключ на месте, подпись валидна, opendkim-testkey не выдал ошибок. Версию с DKIM закрыли — заголовки писем это тоже подтверждали.

Вторая версия — домен продукта A попал в чёрный список. Проверили через прямые запросы к DNSBL и через публичные чекеры:

dig +short 2.113.0.203.zen.spamhaus.org

Ответ пустой — значит, IP не в Spamhaus ZEN на момент проверки. Проверили ещё несколько популярных списков вручную — по домену продукта A ничего не нашли. Про репутацию домена и восстановление после попадания в списки мы уже разбирали в статье про чёрные списки IP и восстановление репутации — но в этом случае в явных публичных DNSBL адрес не числился, что тоже сбивало с толку: обычно жалобы получателей и попадание в списки идут рука об руку.

Третья версия — что-то не так с SPF-записью после недавних правок DNS. Перепроверили запись целиком:

dig txt producta.example +short

SPF был корректным, механизм include: указывал на актуальный релей, синтаксис проверили парсером SPF — ошибок нет. О типичных ошибках в SPF/DKIM/DMARC мы отдельно писали в статье SPF, DKIM и DMARC простыми словами, и ни одна из описанных там классических ошибок здесь не подтвердилась.

Четвёртая версия — массовые жалобы именно на продукт A: возможно, пользователи стали массово жать «Это спам» на письма от него. Подняли статистику обращений в саппорт и историю отписок по продукту A — всплеска не было. Люди жаловались не на содержание писем, а на то, что писем вообще нет или они не находятся.

Пятая версия — проблема с TLS-сертификатом на SMTP-соединении, из-за которой некоторые провайдеры могли занижать доверие к серверу. Проверили сертификат релея и STARTTLS-хендшейк вручную через openssl s_client -starttls smtp -connect mail.producta.example:25 — сертификат валиден, срок действия в порядке, цепочка выстраивается. Версию закрыли.

К этому моменту все локальные, «доменные» версии были исчерпаны. Оставалось признать: раз с доменом продукта A всё в порядке, а проблема есть — значит, дело не в домене, а в чём-то общем для обоих продуктов. Общим был только один компонент: исходящий IP.

В чём была реальная причина

Подняли логи Postfix за ту же неделю уже по продукту B — и сразу увидели резкий скачок объёма исходящей почты. У продукта B в те дни запустили реактивационную рассылку по старой базе подписчиков — тем, кто не открывал письма много месяцев. Часть адресов в такой базе неизбежно устаревает: превращается в спам-ловушки (spam traps) или просто вызывает раздражение у получателей, которые давно забыли о подписке и жмут «Это спам» вместо «Отписаться».

Провайдеры вроде Gmail, Outlook и Yahoo оценивают репутацию отправителя не по домену в отдельности, а в первую очередь по исходящему IP — сколько писем с него уходит, какая доля помечается как спам, какая доля бьётся об несуществующие ящики, стабилен ли объём отправки. Когда с одного IP резко вырастает объём рассылки и вместе с ним растёт доля жалоб, репутация IP проседает для всего трафика с этого адреса — независимо от того, с какого домена конкретное письмо отправлено и насколько корректно оно подписано DKIM.

Именно это произошло: рассылка продукта B по «уставшей» базе подняла долю жалоб на исходящем IP, провайдеры начали агрессивнее фильтровать и троттлить трафик с этого адреса, и транзакционные письма продукта A — с валидным DKIM, SPF и DMARC — попали под ту же раздачу просто потому, что уходили с того же IP и с той же PTR-записи. DKIM и SPF подтверждают, что письмо действительно от заявленного домена и не подделано, но они не защищают от репутационной фильтрации по IP — это разные механизмы, и один не компенсирует другой.

Как подтвердили диагноз

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

Первый — Google Postmaster Tools (postmaster.google.com), подключённый отдельно к домену продукта A. Там репутация домена показывалась как «Средняя», без резких провалов. А вот вкладка с данными по IP показывала выраженное ухудшение именно в дни рассылки продукта B — репутация IP просела, при этом домен продукта A формально оставался «чище» своего же исходящего адреса. Это расхождение — домен в порядке, IP хуже — и есть прямое подтверждение того, что проблема на уровне IP, а не домена.

Второй источник — Microsoft SNDS (Smart Network Data Services) для IP, отправляющих на Outlook/Hotmail. В панели SNDS виден статус жалоб (complaint rate) и общий индикатор доверия к IP по цветовой шкале. В дни всплеска рассылки продукта B индикатор по этому IP ухудшился — и это совпало по времени с обращениями пользователей продукта A.

Дополнительно подняли отчёты обратной связи (Feedback Loop, FBL) от почтовых провайдеров — если они подключены, каждый раз, когда получатель жмёт «Это спам», отправителю приходит отчёт с исходным письмом. Просмотр этих отчётов за проблемную неделю показал: почти все жалобы относились к письмам продукта B, ни одной — к письмам продукта A. То есть источник жалоб был точно определён, а страдал от последствий другой продукт на общем IP. Подробнее о том, как устроены такие отчёты и зачем их вообще подключать, мы разбирали в статье про обратную связь от почтовых провайдеров (FBL).

Совпадение по времени (запуск реактивационной рассылки продукта B — просадка IP-репутации в Postmaster Tools и SNDS — жалобы пользователей продукта A) и отсутствие жалоб на сам продукт A в FBL-отчётах вместе дали однозначную картину: два продукта делили один IP, и репутационный ущерб от одного лёг на оба.

Что изменили после

Главное решение — разделить исходящие IP-адреса по типу и по продукту, чтобы репутационные проблемы одного канала физически не могли задеть другой.

Заказали второй выделенный IP у провайдера и настроили для него отдельную PTR-запись, указывающую на собственное имя хоста для рассылок продукта B, отдельно от почтового имени продукта A. Затем развели трафик в Postfix через привязку к разным исходящим адресам:

# /etc/postfix/master.cf
transactional  unix  -       -       n       -       -       smtp
    -o smtp_bind_address=203.0.113.10

bulk            unix  -       -       n       -       -       smtp
    -o smtp_bind_address=203.0.113.20

И указали, какой отправитель через какой транспорт должен уходить:

# /etc/postfix/sender_transport
@producta.example      transactional:
@productb.example       bulk:

# /etc/postfix/main.cf
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport

После правки таблицы обязательно пересобрать hash-базу и перечитать конфигурацию:

postmap /etc/postfix/sender_transport
postfix reload

Для продукта B дополнительно вынесли рассылки на отдельный поддомен (news.productb.example) с собственным DKIM-селектором и отдельной DKIM-парой ключей, не пересекающейся с транзакционным доменом. Это дало вторую границу изоляции: даже если поддомен рассылок снова получит жалобы, основной домен и транзакционные письма формально остаются отдельной сущностью для DMARC-агрегации и для части эвристик провайдеров, которые учитывают репутацию поддомена отдельно от родительского домена.

Отдельно пересмотрели процесс самих рассылок продукта B: реактивационные кампании по «холодным» адресам теперь не отправляются одним залпом на всю базу. Список сначала прогоняют через верификацию адресов, отправку разбивают на постепенный прогрев нового IP (наращивание объёма малыми порциями в течение нескольких дней вместо одномоментного большого объёма), а для по-настоящему давно не открывавших писем адресов ввели отдельный сегмент с более осторожной частотой отправки. Точные объёмы и сроки прогрева каждый раз разные и зависят от истории конкретного IP и провайдера, поэтому конкретную схему прогрева стоит согласовывать по ситуации, а не переносить чужие цифры один в один.

Из мониторинга добавили: подключили Google Postmaster Tools и Microsoft SNDS на оба IP отдельно и завели ручную еженедельную проверку показателей репутации и доли жалоб, плюс договорились, что перед любой крупной рассылкой продукта B кто-то из ответственных за инфраструктуру in the loop — простое правило «сообщи заранее» оказалось дешевле, чем повторное расследование инцидента. О похожих причинах, из-за которых письма вообще уходят в спам, у нас есть отдельный разбор в статье Postfix: письма уходят в спам, причины и решение — стоит держать её под рукой как чек-лист на будущее.

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