Как перенести почту на новый домен без потери репутации отправителя

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

Почему репутация не переезжает вместе с почтой

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

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

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

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

Подготовка: DNS и аутентификация до переключения

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

Отдельное внимание — DMARC-политике на старте: на новом домене разумно начинать с мягкой политики (наблюдение, без жёсткого отклонения), чтобы видеть отчёты о прохождении аутентификации и чинить проблемы, прежде чем ужесточать правила. Слишком строгая политика с самого начала на непроверенной настройке рискует блокировать собственные же легитимные письма.

• SPF-запись нового домена включает все реальные источники отправки, включая используемую платформу рассылок
• DKIM-подпись настроена и проверена тестовой отправкой на контрольные ящики всех целевых провайдеров
• DMARC начинается с политики наблюдения (p=none) с постепенным ужесточением по мере накопления чистой статистики
• MX-записи и PTR корректны и указывают на актуальную инфраструктуру
• Постмастер-инструменты провайдеров (где доступны) подключены к новому домену заранее

Прогрев нового домена параллельно со старым

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

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

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

На практике полезно фиксировать конкретные пороговые значения, при которых прогрев можно ускорить, а не полагаться на ощущение «вроде всё нормально»: доля писем во «Входящие» на контрольных ящиках выше определённого уровня несколько дней подряд, отсутствие жалоб и баунсов сверх обычного фона, чистая репутация в постмастер-инструментах. Формальные критерии снимают соблазн поторопить процесс под давлением сроков проекта.

Порядок переключения кампаний

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

Важно на этом этапе сохранить преемственность коммуникации: если получатель уже переписывался с конкретным адресом на старом домене, резкая смена адреса отправителя без объяснения выглядит подозрительно и может восприниматься как фишинг. Уместно короткое уведомление о смене адреса в последнем письме со старого ящика или явное указание в подписи нового.

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

Что может пойти не так

Самая частая ошибка — полное отключение старого домена сразу после запуска нового, без переходного периода: если на новом домене всплывает проблема (пропущенная DNS-запись, неожиданный всплеск жалоб), нет пути назад, и вся кампания простаивает, пока чинится инфраструктура.

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

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

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

Как перенос организован в LDM

В LDM при добавлении нового отправляющего домена система рассчитывает график прогрева индивидуально и не позволяет резко нарастить объём выше безопасного порога даже по ошибке пользователя — дневные лимиты растут постепенно по расписанию. Кампании можно вести параллельно с нескольких доменов и постепенно перераспределять сегменты между старым и новым адресом прямо в интерфейсе, а вся история переписки и ответов остаётся привязанной к контакту в CRM независимо от того, с какого домена ушло конкретное письмо — маршрутизация входящих не теряется при смене отправителя.

Это снимает с команды главный операционный риск переноса: даже если про перевод части сегментов забыли или график миграции сдвинулся из-за других задач, платформа не позволит домену выйти за пределы безопасного темпа, а история диалогов с контактами останется целостной и доступной в одном месте вне зависимости от того, сколько доменов было задействовано за время миграции.

Вопросы и ответы