Как сменить провайдера отправки холодных писем и не потерять доставляемость

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

Почему смену провайдера нельзя делать одним днём

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

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

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

С чего начать: аудит причины перехода

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

От причины зависит план проверки: если уходите из-за лимитов — тестируйте объём и скорость прогрева нового провайдера; если из-за блокировок — изучайте политику разбора жалоб и репутацию его IP-диапазонов; если из-за интеграций — начинайте с проверки API и вебхуков, а не с домена.

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

Пошаговый план миграции

Полный переход стоит растянуть на несколько недель — это не то место, где стоит экономить время в ущерб доставляемости.

• Шаг 1. Завести аккаунт у нового провайдера и протестировать его на одном-двух второстепенных доменах, не затрагивая основную рассылку
• Шаг 2. Настроить SPF, DKIM и DMARC для тестовых доменов на новой инфраструктуре и проверить корректность через почтовые тестеры
• Шаг 3. Прогреть тестовые домены на новом провайдере с нуля — небольшой объём с постепенным ростом, как для нового домена
• Шаг 4. Запустить параллельную отправку: часть кампаний через старого провайдера, часть — через нового, и сравнить доставляемость на одинаковых сегментах
• Шаг 5. Постепенно переводить остальные домены пачками, а не разом, продолжая мониторить репутацию каждого
• Шаг 6. Отключать старого провайдера только после того, как новый подтвердил стабильную доставляемость на полном объёме

Что переносится вручную и требует особого внимания

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

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

Перенос истории переписки и статусов контактов

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

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

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

Как контролировать репутацию во время перехода

На протяжении всего периода миграции стоит ежедневно отслеживать несколько показателей: попадание тестовых писем в спам через специальные проверочные ящики, динамику bounce rate, наличие домена в основных чёрных списках, а также цифры open и reply rate в сравнении с показателями до перехода.

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

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

Частые ошибки при смене провайдера

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

• Перевод всех доменов и всего объёма отправки в один день без параллельного тестового периода
• Копирование старой SPF-записи без добавления инфраструктуры нового провайдера
• Отключение старого провайдера до полного подтверждения стабильности нового
• Отсутствие прогрева на новой инфраструктуре, даже если домены давно прогреты у прежнего провайдера
• Смена провайдера одновременно с другими крупными изменениями — новым доменом, новой CRM, новым текстом писем, — что не даёт понять, какая именно перемена повлияла на результат

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