Разделите рекламу и уведомления о заказах на отдельные потоки: назначьте им разные поддомены отправки, настройте аутентификацию и ведите отдельную аналитику. Так проще найти причину сбоев и снизить влияние рекламных кампаний на важные сообщения покупателям. Одного нового адреса отправителя недостаточно: проверьте, как сервис подписывает письма и через какую инфраструктуру их отправляет. Ниже разберём, какие сообщения куда отнести, что поручить техническому специалисту и как проверить результат до переноса всех отправок.
Какие письма отделить от рекламной рассылки?
Начните с перечня писем, которые бизнес отправляет клиентам. Для каждого укажите причину отправки: действие покупателя, изменение заказа или решение маркетолога запустить кампанию. По этому признаку проще разделить потоки, чем по названию шаблона в сервисе.
- В поток уведомлений отнесите подтверждение заказа, изменение его статуса и сообщение о доставке.
- Отдельно учтите технические письма: подтверждение адреса, восстановление доступа, предупреждение о входе.
- В маркетинговый поток направьте акции, подборки товаров, новости и предложения вернуться за покупкой.
- Письма со смешанной задачей пересмотрите: статус заказа оставьте в уведомлении, самостоятельное предложение покупки перенесите в маркетинговую цепочку.
Например, интернет-магазин сообщает, что заказ готов к выдаче. Покупателю нужны состав заказа, место получения и способ связаться с магазином. Если добавить большую подборку товаров со скидками, письмо начнёт решать ещё и рекламную задачу. Для управления отправками эти задачи лучше развести по разным шаблонам.
Автоматический запуск сам по себе ничего не определяет. Письмо о брошенной корзине тоже запускается по событию, но его задача — вернуть человека к покупке. Поэтому относите его к маркетинговому потоку. О том, как сочетать уведомления с дальнейшей коммуникацией, подробнее рассказано в статье про транзакционные письма и повторные продажи.
Как разделить потоки на уровне домена и сервиса?
Выделите поддомен для маркетинговых рассылок и поддомен для уведомлений. Поддомен — отдельное имя внутри домена компании, которое можно подключить к сервису отправки. Бренд остаётся узнаваемым, а настройки и отчёты по потокам проще проверять отдельно.
Смена части адреса до знака @ не создаёт такого разделения. Два разных имени отправителя на одном домене могут использовать одну подпись и один маршрут отправки. Чтобы понять реальную схему, посмотрите настройки сервиса и заголовки тестового письма.
- Закрепите за каждым потоком свой поддомен и понятное имя отправителя.
- Подключите поддомены в сервисе и добавьте DNS-записи по его инструкции. DNS-записи задают технические настройки домена.
- Настройте SPF и DKIM для каждого маршрута отправки, затем проверьте DMARC.
- Разведите шаблоны, сценарии запуска и отчёты, чтобы рекламная кампания не использовала настройки уведомлений.
- Уточните у сервиса, как он обрабатывает очередь писем и можно ли защитить уведомления от задержек во время массовой рассылки.
SPF помогает проверить, разрешена ли отправка с конкретного сервера. DKIM добавляет цифровую подпись письма. DMARC проверяет связь адреса отправителя с доменами, которые прошли SPF или DKIM, и задаёт правила обработки при сбое проверки. Практические действия собраны в инструкции по настройке SPF, DKIM и DMARC.
Не копируйте настройки между поддоменами вслепую: сервисы могут использовать разные значения записей. Также проверьте, какая политика DMARC действует для поддоменов. Настройки основного домена могут распространяться на них.
Поддомены помогают разделить потоки, но не создают полной изоляции репутации. Почтовые системы учитывают и другие признаки, в том числе инфраструктуру отправки. Отдельный сервис или IP-адрес тоже не гарантирует попадания во входящие. Для небольшого объёма писем сначала обсудите с провайдером доступную схему, без покупки выделенного IP по умолчанию.
Как перенести письма без сбоев в уведомлениях?
Составьте карту отправок до изменения настроек. Письма могут уходить из системы заказов, сайта и сервиса рассылок, хотя получатель видит одно имя компании. Если перенести только шаблоны в рассыльщике, часть сообщений продолжит идти прежним маршрутом.
Для каждого письма зафиксируйте источник, событие запуска, адрес отправителя и человека, который отвечает за настройку. Отдельно отметьте письма, без которых клиент не сможет завершить действие, например восстановить доступ или узнать статус заказа.
- Подготовьте новые поддомены и проверьте аутентификацию на тестовых письмах.
- Выполните тестовое действие на сайте и убедитесь, что оно запускает нужный шаблон с правильными данными.
- Проверьте письмо на телефоне: номер заказа, статус и основная ссылка должны читаться без поиска по всему сообщению.
- Переводите сценарии по очереди, сверяя журнал отправок с событиями в системе заказов.
- После проверки отключите старый маршрут для этого сценария, чтобы клиент не получал дубликаты.
Маркетинговый поток на новом поддомене запускайте постепенно, начиная с подписчиков, которые недавно проявляли интерес к письмам. Резкое увеличение объёма затруднит поиск причины проблем с доставкой. При сбоях приостановите расширение рассылки и проверьте ответы почтовых серверов.
Если настройку передаёте специалисту, результатом работы должны стать карта потоков, проверенные тестовые письма и понятный порядок возврата к прежнему маршруту. Так можно проверить работу без доступа ко всем техническим деталям. Скриншота с зелёными отметками в сервисе для этого недостаточно.
Как проверить, что разделение работает?
Смотрите отчёты по каждому потоку отдельно. Общая статистика скрывает различия: массовая акция и единичные уведомления решают разные задачи. Для письма о заказе сначала проверьте сам факт отправки, задержку и ошибки доставки.
Статус «доставлено» обычно означает, что принимающий сервер принял письмо. Он не подтверждает попадание во входящие. Проверяйте тестовые ящики и ответы серверов, а открытия используйте как дополнительный признак: отсутствие открытия само по себе не доказывает проблему с доставкой.
- Сверьте событие в системе заказов с записью в журнале отправок. Если записи нет, ищите сбой в сценарии или интеграции.
- Если сервис зафиксировал отказ, прочитайте его причину: адрес не существует, сервер временно недоступен или письмо отклонено.
- Если сервер принял письмо, но оно оказалось в спаме, проверьте аутентификацию, содержание и репутацию отправки.
- Сравните время события и время отправки, чтобы обнаружить задержку в очереди сервиса.
Если уведомления теряются даже при редких отправках, разберите причины отдельно. Для этого пригодится материал о том, почему письма о заказах попадают в спам. Небольшой объём сам по себе не подтверждает исправность настроек.
После переноса проверьте и ответы клиентов. Адрес для ответа должен вести в ящик, который сотрудники читают. Иначе письмо о заказе дойдёт, но вопрос покупателя останется без ответа.
Типичные ошибки при разделении писем
- Меняют только видимый адрес отправителя. Исправление: проверить домен подписи DKIM и настройки фактического маршрута отправки.
- Считают новый поддомен гарантией доставки. Исправление: проверить аутентификацию и постепенно запускать отправки с контролем ошибок.
- Оставляют акции внутри уведомлений. Исправление: вынести самостоятельные предложения в маркетинговые шаблоны и цепочки.
- Переносят сразу все сценарии. Исправление: проверять каждый маршрут отдельно и сохранять возможность вернуть прежнюю настройку.
- Оценивают уведомления только по открытиям. Исправление: сверять события, журналы отправок, задержки и причины отказов.
Начните с одного действия на две минуты: откройте последнее письмо о заказе и запишите, какая система его отправила. Если это непонятно, отправьте человеку, который поддерживает сайт, вопрос: «Через какой сервис уходят уведомления о заказах?»
