Переезд на новую инфраструктуру отправки: как не потерять репутацию и прогрев

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

Что именно переезжает при смене инфраструктуры отправки

Под инфраструктурой отправки в B2B-аутриче понимается связка из нескольких слоёв: домены для рассылки (часто отдельные от основного корпоративного домена), почтовые ящики на этих доменах, DNS-записи аутентификации (SPF, DKIM, DMARC), инструмент или платформа отправки и, отдельно, база контактов со всей историей взаимодействия.

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

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

План миграции: последовательность, а не одномоментное переключение

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

Второй шаг — постепенный перевод объёма, а не полное переключение в один день. Если ежедневно уходит, скажем, 300 писем со старой инфраструктуры, разумно начать с 10–15% объёма на новой и наращивать долю в течение двух-трёх недель, параллельно снижая объём на старой — но не выключая её резко, пока новая не выйдет на стабильные показатели.

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

Четвёртый шаг — контрольный период в 2–4 недели, когда обе инфраструктуры работают параллельно на сниженном режиме, прежде чем полностью отключить старую. Это страховка: если на новой стороне вскроется проблема с доставляемостью, у вас остаётся рабочий канал, пока чинится новый.

Прогрев новых доменов и ящиков в рамках миграции

Если переезд включает смену доменов, прогрев обязателен и не подлежит обходу никакими техническими трюками. Логика прогрева одна и та же независимо от повода: начинать с малого ежедневного объёма (10–20 писем на ящик), постепенно наращивать его на протяжении 4–6 недель, следя за метриками доставляемости и жалоб на каждом шаге.

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

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

Технические проверки перед переключением

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

• SPF-запись домена включает все реальные источники отправки, старые записи от предыдущего провайдера удалены
• DKIM-подпись настроена и проходит проверку на тестовых отправках через сервисы валидации заголовков
• DMARC-политика установлена хотя бы в режиме мониторинга (p=none) на старте, чтобы видеть проблемы без блокировки легитимных писем
• Обратная DNS-запись (PTR) для IP-адреса соответствует домену отправки, если используется выделенный IP
• Тестовые письма проверены на попадание в inbox по нескольким крупным провайдерам (Gmail, Яндекс, Mail.ru, корпоративные фильтры), а не только на факт доставки
• Прежние домены и ящики не удаляются мгновенно — держите их читаемыми ещё несколько недель на случай ответов на старые письма

Частые ошибки при переезде

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

• Резкое переключение всего объёма на новую инфраструктуру в первый же день без прогрева
• Удаление старых доменов и ящиков сразу после переезда — теряются ответы на уже отправленные письма
• Копирование DNS-записей от старого провайдера без адаптации под новый (например, старый SPF include остаётся, новый не добавлен)
• Перенос базы контактов без статусов и стоп-листов — повторная отправка тем, кто уже отказался
• Отсутствие контрольного параллельного периода — при проблеме с новой инфраструктурой нет запасного канала
• Смена сразу нескольких переменных одновременно (платформа + домены + база) без возможности понять, что именно вызвало проблему при её появлении

Организационные и договорные моменты миграции

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

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

Полезно также заранее зафиксировать критерии успеха миграции в измеримых терминах: например, deliverability на новой инфраструктуре не ниже 95% в течение двух недель подряд, reply rate не хуже, чем на старой системе за тот же период. Это превращает субъективное ощущение «переезд прошёл нормально» в проверяемый факт и позволяет вовремя увидеть, если что-то пошло не так, а не убедить себя, что всё в порядке, потому что очень хотелось закрыть проект переезда.

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

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