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

MAATRIX

Письмо с кодом подтверждения не дошло вовремя — и человек не смог войти в аккаунт. А началось всё с того, что неделю назад с того же IP ушла промо-рассылка, на которую четверть получателей нажала «это спам». Если вы сажаете транзакционную и маркетинговую почту на одну инфраструктуру отправки, вы рано или поздно попадёте именно в эту ситуацию — и разбираться придётся не с рекламой, а с тем, что клиенты не могут сбросить пароль или получить чек.

Два типа писем — и зачем их вообще различать

С точки зрения бизнеса всё, что уходит из вашей системы на email, — это просто «письма». С точки зрения получателя и его почтового провайдера — это два принципиально разных потока.

Транзакционные письма — это уведомления, без которых сервис не работает:

• подтверждение регистрации и код для входа;
• сброс пароля;
• чек об оплате, счёт, квитанция;
• уведомление о статусе заказа, доставке, отправке;
• предупреждение о подозрительном входе в аккаунт.

Ключевая черта: их отправка — прямое следствие действия самого пользователя. Он нажал «забыли пароль» — и ждёт письмо. Он оплатил заказ — и ждёт чек. Он сам инициировал событие, письмо для него не сюрприз, а часть сценария, который он запустил.

Маркетинговые письма — это то, что инициируете вы:

• промо-предложения, скидки, распродажи;
• новостные рассылки (дайджест, блог, обновления продукта);
• реактивационные письма «мы соскучились»;
• анонсы новых функций и акций.

Пользователь мог подписаться на них полгода назад и с тех пор ни разу не открывать. Он не ждёт это письмо в конкретный момент — оно приходит по вашему расписанию, а не по его запросу.

Разница выглядит формальной, но она напрямую определяет, как получатели и антиспам-фильтры реагируют на письмо — и вот это уже не формальность.

Как реально ведёт себя получатель — и почему это важно

Возьмите статистику открытий (open rate) двух потоков за один и тот же месяц у одного и того же отправителя — разница будет разительной.

Транзакционные письма получатель ждёт и почти всегда открывает:

• он сам запросил сброс пароля — письмо открывается почти сразу;
• он оплатил заказ — чек открывают, чтобы свериться с суммой;
• пришло уведомление о входе с нового устройства — если это не он, откроет из тревоги, если он — из любопытства.

В сумме: стабильно высокая доля открытий, минимум жалоб на спам (жаловаться на письмо с кодом входа, который сам запросил, странно), минимум отписок. Для почтовых провайдеров (Gmail, Mail.ru, Yandex, Outlook) это ровно тот сигнал, который формирует хорошую репутацию отправителя — они видят: этому IP/домену доверяют, письма открывают, не жалуются, попадают точно к адресату.

Маркетинговые письма ведут себя иначе, и это не брак вашей рассылки, а нормальное поведение аудитории:

• часть подписчиков открывает промо только если тема цепляет здесь и сейчас;
• часть игнорирует письмо полностью — просто не тот момент;
• часть, даже подписавшись когда-то добровольно, жмёт «в спам» — не потому что рассылка плохая, а потому что удобнее пожаловаться, чем искать кнопку отписки, или просто раздражает частота.

В результате показатели маркетингового потока объективно более волатильны: одна кампания может дать 25% открытий и 0,1% жалоб, другая с той же базой — 8% открытий и 0,5% жалоб (это цифры для примера порядка величины, у вас будет иначе — ориентируйтесь на свою статистику, а не на чужие числа). Такова природа этого канала: получатель не обязан вам ничего, в отличие от транзакционного письма, которое он сам вызвал своим действием.

Почему смешивание — это не теоретический риск, а практическая проблема

Вот тут начинается главное. Репутация отправителя (sender reputation) у почтовых провайдеров привязана не к «типу письма», а к конкретному IP-адресу и/или домену, с которого письмо пришло. Провайдер не разбирает намерения — он видит: с этого IP/домена в сумме за период пришло N писем, из них открыто столько-то, в спам пожаловались столько-то, отписалось столько-то. Это агрегированная метрика.

Если транзакционные и маркетинговые письма уходят с одного и того же IP и домена, они попадают в одну и ту же «корзину репутации». Дальше сценарий такой:

1. Вы запускаете агрессивную промо-кампанию — например, распродажу с рассылкой по всей базе, включая давно неактивных подписчиков.
2. Часть получателей игнорирует письмо, часть жалуется на спам — процент жалоб выше обычного (скажем, вместо привычных 0,05% получаете 0,3-0,5% — конкретные пороги у каждого провайдера свои и не публикуются официально).
3. Почтовые провайдеры фиксируют это как ухудшение сигнала именно с вашего IP/домена и начинают строже фильтровать всю последующую почту с этого источника — не только маркетинговую.
4. Через день-два с того же IP/домена уходит транзакционное письмо — код сброса пароля. Провайдер видит "подозрительный" источник и либо кладёт письмо в спам, либо задерживает доставку, либо (в худшем случае) отклоняет.
5. Пользователь не получает код вовремя, не может войти в аккаунт, пишет в поддержку — или просто уходит к конкуренту.

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

Разделение инфраструктуры — стандартная практика, а не паранойя

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

Практическая реализация — два независимых потока:

Если вы отправляете почту через собственный сервер (Postfix, Exim) или через SMTP-relay, разделение делается на уровне поддоменов и, где возможно, отдельных исходящих IP:

# пример: два поддомена, каждый со своей DKIM-подписью
# /etc/opendkim/KeyTable
transactional._domainkey.transactional.example.com transactional.example.com:transactional:/etc/opendkim/keys/transactional.private
news._domainkey.news.example.com news.example.com:news:/etc/opendkim/keys/news.private

# /etc/postfix/transport — маршрутизация по отправляющему домену на разные smtp-относы/IP
transactional.example.com smtp-transactional:
news.example.com smtp-news:

# пример инстанса smtp-относа с привязкой к конкретному исходящему IP
# /etc/postfix/master.cf
smtp-transactional unix - - n - - smtp
  -o smtp_bind_address=203.0.113.10

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

Для каждого поддомена — своя запись SPF, свой селектор DKIM, и оба поддомена подчиняются общей DMARC-политике родительского домена (или собственной, если хотите разную строгость). Как это настроить с нуля — разобрано в статье про SPF, DKIM и DMARC простыми словами.

Если вы используете внешний сервис транзакционных писем (Amazon SES, Postmark, SendGrid и подобные) — там разделение делается ещё проще: заводите два отправляющих домена/поддомена в настройках сервиса, каждому назначается своя репутация, и это ровно та же логика, просто без ручной настройки Postfix.

Прогрев — двух потоков, а не одного

Отдельный нюанс, который часто упускают даже при правильном разделении инфраструктуры: оба потока нужно прогревать по отдельности, даже если это один и тот же бизнес и один и тот же физический сервер.

С точки зрения принимающих почтовых провайдеров новый IP или новый поддомен — это неизвестный источник без истории. Не важно, что у вас уже есть основной домен с отличной репутацией десять лет — поддомен news.example.com с новым IP для провайдера отдельная сущность, у которой пока ноль истории. То же самое верно и для transactional.example.com, если вы выделяете под него новый IP.

Это значит: запуская новую инфраструктуру отправки, вы прогреваете не один IP, а фактически два независимых источника — с разным темпом и разной логикой, потому что и объём, и характер писем у них разный:

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

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

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

Практический план внедрения разделения

Если сейчас у вас всё уходит с одного IP и домена, переход стоит делать поэтапно, а не одним днём:

1. Выделите второй IP под сервер или добавьте его как дополнительный публичный адрес на существующий VPS (у большинства провайдеров это делается за отдельную плату — для критичной инфраструктуры это оправданная стоимость).
2. Заведите два поддомена — например notify. для транзакционных и news. для маркетинговых писем.
3. Настройте отдельные SPF/DKIM для каждого поддомена, привяжите каждый поддомен к своему исходящему IP.
4. Прогрейте оба потока параллельно, но по разным графикам — транзакционный обычно догоняет естественным ростом использования, маркетинговый — управляемым наращиванием объёма кампаний.
5. Мониторьте репутацию раздельно — через Google Postmaster Tools и подобные инструменты для каждого поддомена отдельно, а не суммарно.
6. Не смешивайте базы получателей в рассылочном ПО — если используете один и тот же инструмент массовой рассылки для обоих типов писем, убедитесь, что он поддерживает разные отправляющие домены/IP для разных типов кампаний, иначе разделение окажется формальным. Как настроить массовую рассылку на VPS с нуля — в статье как установить и настроить массовую рассылку с сервера на VPS.

Технически такое разделение требует либо одного VPS с двумя выделенными IP, либо (что надёжнее) двух отдельных серверов — тогда даже проблема на уровне самого сервера (не только репутации) не затронет второй поток.

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