Миграция домена и доставляемость почты

Что меняется при миграции домена

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

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

Доверие формируется медленнее, чем DNS. Если новый домен начинает отправлять 5 000 сообщений в первый же день, почтовые провайдеры могут воспринимать его как нового отправителя без истории. Бренд может сохранить логотип, тон и качество базы, но всё равно потерять попадание во входящие, потому что изменился домен и вместе с ним — модель отправки.

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

Распространённые проблемы с доставляемостью после миграции

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

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

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

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

Как миграция домена влияет на SPF, DKIM и DMARC

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

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

Иногда при миграции меняют только сайт, а почтовую платформу оставляют старой. Даже в этом случае аутентификация может сломаться. Изменение DNS-хостинга, новый поддомен или новый исходящий IP могут поменять весь маршрут. Если хотите аккуратно разложить техническую часть, статья о настройке DKIM SPF DMARC для транзакционных писем будет полезным дополнением, особенно для темы SPF DKIM DMARC после миграции домена.

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

Проверки DNS, MX и маршрутизации почты

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

Сначала проверьте MX-запись. Затем подтвердите записи A или CNAME, которые поддерживают почтовый хост, и убедитесь, что все поддомены, используемые для отправки, отслеживания или ответов, по-прежнему разрешаются. Запись, которая кажется безобидной в 9 утра, к полудню может сломать сброс пароля.

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

Для команд, которые отправляют и маркетинговые, и транзакционные письма, маршрутизацию нужно тестировать с обеих сторон. Неправильно настроенная MX-запись может не остановить рассылку, но способна заблокировать письма подтверждения аккаунта или уведомления о заказе. Если почтовый стек смешанный, сравните его с материалом о том, что такое SMTP relay для node.js, прежде чем считать путь отправки чистым.

Репутация отправителя и прогрев

Миграция домена может обнулить или ослабить сигналы репутации, даже если список адресов не менялся. Почтовые провайдеры читают паттерны, а не обещания. Если отправитель переходит с 200 писем в день на 20 000 на новом домене, такой скачок выглядит рискованно, особенно если вовлечённость ещё неизвестна.

Прогрев помогает, потому что распределяет риск на 7, 14 или 30 дней вместо того, чтобы заставлять новый домен доказывать себя сразу. Начните с самых вовлечённых получателей, а затем переходите к более старым сегментам только после того, как размещение стабилизируется. Это не эффектно, но работает чаще, чем большой стартовый залп.

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

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

Диагностика проблем с доставляемостью

Начните с сообщения о возврате. Прочитайте SMTP-код, текст для человека и любые заметки конкретного провайдера. Код 4xx означает временную проблему; код 5xx — жёсткий отказ. От этого зависит, повторять ли попытку, разбираться или вообще прекращать отправку на этот адрес.

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

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

Инструменты тестирования здесь экономят время. Запускайте проверки до и после каждого изменения и сравнивайте результаты, а не смотрите на один зелёный индикатор. Руководство по инструментам тестирования доставляемости email · YourTrend поможет выстроить эти проверки, особенно если проблема неочевидна только по одному ящику.

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

Как исправить доставляемость после миграции домена

Сначала исправьте записи. Опубликуйте правильные значения SPF include, при необходимости обновите DKIM-ключи и подтвердите выравнивание DMARC. Затем убедитесь, что платформа отправки действительно использует обновлённые записи, а не кэшированные настройки старого домена. Изменение DNS, которое так и не дошло до почтового сервера, ничего не меняет.

Далее исправьте инфраструктуру отправки. Обновите домен MAIL FROM, домен для ответов, ссылки отслеживания и все поддомены, которые используются для аутентификации или обработки возвратов. Если обработка возвратов всё ещё привязана к старому домену, жалобы и возвраты могут собираться не там, где нужно. Это создаёт медленную утечку.

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

Правила подавления нужно пересмотреть до повторной отправки чего-либо. Старые жалобы, отписки и жёсткие возвраты должны по-прежнему оставаться подавленными на новом домене. Если вам нужна более строгая политика, статья о управлении списком подавления email · YourTrend стоит внимания перед следующим запуском кампании.

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

Лучшие практики, чтобы предотвратить будущие проблемы с доставляемостью

Планируйте миграцию с учётом электронной почты с самого первого дня. Команды, отвечающие за сайт, часто рассматривают перенос домена как проект по контенту или хостингу, но у email есть собственные зависимости. Включите в процесс почтового провайдера, владельца DNS, команду поддержки и того, кто управляет аутентификацией. Четыре человека на одной встрече могут сэкономить 4 дня позже.

Сделайте предзапускной чек-лист. До переключения подтвердите SPF, DKIM, DMARC, MX, маршрутизацию reply-to, обработку возвратов и домены отслеживания. Затем протестируйте минимум у 2 крупных провайдеров, потому что одной проверки входящих недостаточно. Если нужен более широкий ориентир, доставляемость email как улучшить дают более общий базовый уровень для ежедневной работы с отправкой.

Прогрев нужно заложить в сам план миграции, а не добавлять после первой жалобы. Используйте поэтапный календарь с 3 группами получателей: очень вовлечённые пользователи, недавно активные пользователи и все остальные. Такая последовательность снижает вероятность того, что новый домен начнёт жизнь с избежимого ущерба.

Мониторинг должен оставаться активным как минимум 30 дней после запуска. Отслеживайте процент возвратов, жалобы на спам, проверки попадания во входящие и сбои аутентификации. Если запись ломается на 12-й день, команда должна увидеть это раньше пользователей. То же касается обработки отписки; если новый домен меняет путь ссылки или логику футера, разберитесь, почему лучшие практики отписки email важны, до следующей отправки.

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