Разделение IP-пулов для транзакционных и маркетинговых писем: почему смешивать нельзя

Маркетолог нажал «Отправить» — и OTP перестали доходить

14:00, маркетинг запускает промо-кампанию на 200 000 адресов. К 14:40 в саппорт летят тикеты: «не приходит код подтверждения», «сброс пароля висит в спаме». В коде транзакционного сервиса ничего не менялось. Изменился сосед по IP.

Это не гипотетика, а типовой инцидент, который я разруливал не один раз. Корень у него всегда один: транзакционка и маркетинг уходят с одного отправляющего идентификатора. Владельцы сервиса списывают это на «капризные спам-фильтры Gmail», но фильтры отработали ровно так, как спроектированы.

Ключевой факт, который меняет всё: приёмник ведёт репутацию не по вашему домену, а по кортежу `sending IP + DKIM d= + Return-Path (MAIL FROM)`. Gmail Postmaster и Microsoft SNDS считают статистику именно по этому потоку. Когда с него за 40 минут прилетает 200k писем, у части которых complaint rate 0.2–0.3%, а часть отскакивает от мёртвых адресов, репутация IP проседает целиком. И письмо «Ваш код: 481920», у которого complaint rate около нуля и open rate 85%, наследует эту просадку — потому что физически идёт по тому же кортежу.

Транзакционка и маркетинг — статистически разные распределения. Смешивая их, вы усредняете метрики в худшую сторону: хороший поток тянет плохой вверх ровно до момента, пока плохой не утянет хороший вниз. Изоляция потоков — это не best-practice ради галочки в аудите, это изоляция отказов. За письмом с OTP стоит живой человек, который ждёт код здесь и сейчас; он не может «подождать, пока прогреется репутация».

Два потока — два профиля риска