Поддомены и потоки: как разделить рассылки и не уронить репутацию домена

1. Зачем вообще разделять потоки

У типичной компании три разных по поведению получателей потока: транзакционные письма (подтверждение регистрации, сброс пароля, чеки), сервисные уведомления (статусы заказа, ответы поддержки) и маркетинговые рассылки (акции, дайджесты, реактивация). Транзакционные письма пользователи ждут и открывают почти всегда. Маркетинговые рассылки собирают жалобы на спам на порядки чаще.

Если все три потока идут с одного адреса и одного домена, жалобы на рассылки снижают репутацию всего домена целиком, и под удар попадают письма о сбросе пароля. Google в рекомендациях для отправителей прямо указывает держать долю жалоб ниже 0,1% и не допускать 0,3%: у массовых рассылок эти пороги пересекаются чаще, чем у транзакционной почты. У Mail.ru пороги зависят от месячного объема: до 10 000 писем в месяц допустимо 1,1% жалоб, до 500 000: 1%, до 10 000 000: 0,8%, до 50 000 000: 0,5%, свыше 50 000 000: 0,3%.

Разделение по поддоменам изолирует риск: проблемная маркетинговая кампания бьет по репутации news.example.com, а mail.example.com с транзакционными письмами продолжает работать.

2. Как связаны репутация поддомена и основного домена

Почтовые провайдеры оценивают отправителя по нескольким идентификаторам: IP-адрес, домен в подписи DKIM (тег d=), домен в адресе From. Репутация считается на уровне домена, и поддомен получает собственную историю, но полностью от основного домена он не изолирован: при системных нарушениях фильтры учитывают и организационный домен.

Важная деталь про DKIM: статистика в кабинетах Postmaster привязана к домену в теге d= подписи. Если вы подписываете и рассылки, и транзакционные письма одним d=example.com, провайдер видит их как один поток, даже если адреса From разные. Смена селектора (тег s=) ситуацию не меняет: селектор это просто указатель на ключ в DNS. Чтобы потоки разошлись в статистике, у каждого должен быть свой домен в d=, например d=news.example.com и d=mail.example.com.

Отсюда практический вывод: разделять потоки нужно не только в адресе отправителя, но и в конфигурации DKIM вашего ESP или почтового сервера. Иначе вы получите разные адреса, но общую репутацию.

3. Схемы разделения: поддомен, новый домен или один домен

Выбор зависит от того, насколько потоки различаются по риску и по бренду. Таблица ниже покрывает типовые ситуации.

Схема "несколько брендов, один почтовый домен" рабочая, но требует дисциплины: у каждого бренда свой поддомен, свой DKIM d= и свои ссылки в письмах. Если бренды разделяют и поддомен, и инфраструктуру, жалобы на один бренд отразятся на всех.

4. Настройка DNS и аутентификации для поддоменов

Каждый поддомен, с которого идут письма, должен пройти SPF, DKIM и DMARC. Пример минимального набора записей для маркетингового поддомена news.example.com:

SPF: news.example.com TXT "v=spf1 include:_spf.example-esp.com -all" DKIM (публичный ключ выдает ESP): s1._domainkey.news.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..." DMARC: отдельная запись на поддомене не обязательна. Если на _dmarc.example.com есть запись, она действует и на поддомены. Управлять политикой поддоменов можно тегом sp=:

_dmarc.example.com TXT "v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc@example.com"

Здесь p=quarantine применяется к основному домену, а sp=reject: ко всем поддоменам, у которых нет собственной DMARC-записи. Если для маркетингового поддомена нужна мягкая политика на период внедрения, создайте отдельную запись _dmarc.news.example.com, она будет иметь приоритет над sp=.

Проверка после публикации: dig TXT news.example.com dig TXT _dmarc.news.example.com dig TXT s1._domainkey.news.example.com

Команды по SPF и DKIM должны вернуть ровно одну осмысленную запись каждая: две TXT-записи SPF на одном имени это ошибка, провайдеры трактуют ее как permerror. С _dmarc.news.example.com иначе: если вы не создавали отдельную запись, а политика поддомена управляется тегом sp= в записи основного домена, ответ будет пустым, и это нормально, а не ошибка. Подробности разбора записей есть в статьях про настройку SPF и внедрение DMARC без потери писем.

5. Отдельный домен для транзакционных писем и поддержки

Запрос "отдельный домен для транзакционных писем" обычно означает на практике одно из двух. Первое: транзакционный трафик идет через другого провайдера (например, рассылки через маркетинговую платформу, а чеки через SMTP-сервис), и нужно понять, как это оформить в DNS. Второе: нужна изоляция репутации.

Для первого случая отдельный домен не нужен вообще: достаточно поддомена mail.example.com, на котором ESP транзакционной почты публикует свои SPF include и DKIM-ключи. Для второго случая поддомен тоже почти всегда достаточен, потому что изоляция репутации на уровне поддомена работает, если у потоков разные домены в DKIM d=.

С поддержкой ситуация похожая. Если заявки приходят в helpdesk и ответы уходят автоматически, оформите support.example.com с корректными MX и аутентификацией. Отдельный домен для поддержки имеет смысл, только если поддержка выделена в отдельный юридический или продуктовый бренд.

Обратите внимание на DMARC alignment: чтобы письмо прошло DMARC, домен в From должен совпадать (или быть в relaxed-совпадении на уровне организационного домена) с доменом SPF или DKIM. Если From: support@example.com, а подпись DKIM стоит d=support.example.com, relaxed-режим alignment это допускает, потому что организационный домен общий. Строгий режим (adkim=s) уже нет.

6. Типичные ошибки при разделении потоков

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

7. Как проверить, что разделение работает

Первый шаг: убедиться, что каждый поток подписывается своим DKIM d=. Отправьте письмо из каждой системы на тестовый адрес и посмотрите заголовки. В поле Authentication-Results найдите строку dkim=pass с указанием header.d=: это и есть домен, к которому привязана статистика. Быстро разобрать заголовки можно в бесплатном анализаторе заголовков письма: разбор выполняется в браузере.

Второй шаг: подключить каждый поддомен к кабинетам Postmaster. В Google Postmaster Tools и Mail.ru Postmaster домены добавляются отдельно, и поддомены там показывают собственную статистику. Сверьте: у маркетингового поддомена должны быть видны объемы и жалобы рассылок, у транзакционного: только сервисный трафик. Если в статистике одного поддомена виден чужой трафик, где-то осталась общая подпись.

Третий шаг: отслеживать пороги жалоб по каждому потоку раздельно. У Gmail ориентиры 0,1% и 0,3%, у Mail.ru: от 1,1% до 0,3% в зависимости от месячного объема. PostmastersTool собирает данные Google Postmaster Tools API v2 и Mail.ru Postmaster по всем подключенным доменам и поддоменам, показывает историю по дням и присылает уведомление в Telegram или на почту, когда доля жалоб или доля прохождения SPF, DKIM, DMARC пересекает заданный порог. Так вы увидите, что проблема локализована в одном потоке, а не гадаете по общей открываемости.

Контрольный сценарий: запустите тестовую маркетинговую кампанию на сегмент с заведомо слабой вовлеченностью и проверьте, что статистика транзакционного поддомена в тот же день не изменилась. Если изменилась, потоки где-то пересекаются: чаще всего в общем DKIM d= или в общем IP.