Новости и разборы
Смена почтового домена: как подготовить рассылки к ребрендингу
План смены почтового домена: инвентаризация отправителей, SPF, DKIM и DMARC, перенос исключений, постепенный запуск и контроль доставки.
Новый домен уже работает, логотип заменён, а письма с подтверждением заказа всё ещё приходят от старого бренда. Простая замена адреса отправителя кажется последним штрихом. Но у почтовой программы собственная инфраструктура, история взаимодействий и ожидания получателей. Их нужно перенести вместе с названием.
В руководстве Litmus по ребрендингу от 4 августа 2026 года смена домена рассматривается как событие, влияющее на доставляемость. Практический вопрос для команды: как изменить идентичность отправителя и при этом сохранить работающие уведомления, согласия и возможность обнаружить ухудшение?
Сначала решить, что действительно переносится
Ребрендинг не всегда требует немедленно менять все адреса. Составьте карту отправителей: маркетинговые кампании, подтверждения операций, восстановление доступа, счета, напоминания и письма сотрудников. Для каждого потока укажите систему, текущий домен, адрес ответа, назначение и ответственного. Отдельно отметьте ссылки, изображения и домен отслеживания переходов.
Допустим, компания меняет название и переносит сайт. В этом сценарии транзакционные письма нельзя считать частью обычной рекламной кампании: потерянное уведомление об оплате создаёт другую проблему, чем непрочитанная подборка. Поэтому последовательность перехода определяется значимостью потока, его объёмом и готовностью инфраструктуры. Согласуйте, какие отправители временно останутся на старом домене и как получатель узнает связь между брендами.
Полезно проверить все системы, которые отправляют письма от имени компании, включая небольшие скрипты. Схема Mailgun и Google Apps Script показывает, как уведомления могут быть связаны с Forms, Calendar и Sheets. Это контекст для инвентаризации; опубликованное описание не подтверждает использование нового домена или нынешнюю эксплуатацию проекта.
Проверить аутентификацию каждого потока
Для нового отправителя понадобятся настройки, согласованные с почтовым сервисом. SPF определяет разрешённые источники отправки, DKIM позволяет проверить подпись, а DMARC связывает проверки с доменом видимого отправителя и задаёт политику обработки. Наличие записей в DNS ещё не подтверждает правильную работу конкретного письма.
Отправьте тест из каждой участвующей системы и проверьте заголовки, результаты аутентификации и согласование доменов. Не копируйте пример DNS из статьи без подстановки данных своего сервиса. Особенно важно учитывать уже существующие записи и источники отправки: слишком жёсткая политика, введённая до инвентаризации, может затронуть легитимный поток.
Litmus также рекомендует получать агрегированные DMARC-отчёты, чтобы видеть источники отправки. Определите, кто их разбирает и как найденная проблема превращается в задачу. В плане эксплуатации инфраструктуры должны быть сохранённые настройки, ответственные и понятный порядок возврата конфигурации. Проверку почты стоит включить в приёмку ребрендинга рядом с проверкой сайта.
Перенести отношения с получателями
Перенос базы означает больше, чем копирование адресов. Сохраните отписки, причины исключения, разрешённые темы, частоту, историю согласий и связь получателя с сегментом. Новая платформа или домен не дают оснований снова отправлять человеку письма, от которых он отказался.
Предупредите действующую аудиторию через узнаваемого отправителя. Объясните новое название, будущий адрес и официальный сайт. Если меняется вход в кабинет, отдельно сообщите, какое действие действительно требуется. Не придумывайте необходимость сменить пароль ради объявления о бренде. Получатель должен понимать переход без подозрительных ссылок и дополнительных поисков.
Центр предпочтений email полезен именно здесь: темы и частота должны сохраниться после изменения бренда. Проверьте старые ссылки отписки и новые формы на нескольких тестовых контактах. Если одна система продолжает хранить старое разрешение, а другая уже получила отказ, миграция ещё не завершена.
Разделить изменения и наблюдать запуск
Не объединяйте в один момент новый домен, новый сервис отправки, полностью другую вёрстку и резкий рост объёма. При ухудшении результата будет трудно понять причину. Сохраните знакомые элементы первого письма, а дизайн и сегментацию меняйте отдельно, если это позволяет план бренда.
Начните с ограниченного потока и недавно активной аудитории. Размер первых отправок и темп увеличения нужно согласовать с сервисом и собственной историей: числовые примеры Litmus не являются универсальным безопасным режимом. До запуска установите критерии остановки: ошибки аутентификации, необычные возвраты, жалобы или проблемы с критичными уведомлениями. Человек с полномочием приостановить кампанию должен быть известен заранее.
В разборе доставляемости Litmus от 20 июля 2026 года отдельно объясняется разница между принятием письма сервером и попаданием во входящие. Поэтому отчёт «доставлено» не закрывает проверку. Сравнивайте возвраты и жалобы по провайдерам, доступные наблюдения о размещении письма и выполнение действия по ссылке. Открытия используйте осторожно: они не равны чтению или коммерческому результату.
Сохранить проверяемый итог перехода
Создайте журнал миграции: поток, дата переключения, использованная конфигурация, тестовые письма, замеченные отклонения и решение ответственного. Сверяйте сопоставимые сегменты, а не общую долю успеха до и после смены аудитории. Исторический проект аналитики Mailwizz показывает работу с возвратами и исключениями; его статус delivered по правилам отчёта не был независимым подтверждением входящих.
Если перенос затрагивает API почтового сервиса, дополните план проверкой контрактов интеграции. Изменения событий доставки, идентификаторов и ссылок могут разрушить отчётность даже при работающей отправке. Проверьте, что новое событие относится к правильному письму и не создаёт повторную запись.
Переход можно считать завершённым, когда все согласованные потоки используют ожидаемые адреса, отписки продолжают действовать, критичные сообщения проходят проверку, а команда видит отклонения и знает, как реагировать. Успешная первая рассылка — только одна проверка. Ребрендинг требует наблюдения за последующими отправками и сохранения ответственности после окончания дизайн-проекта.