Язык
Сайт уже открывается на новом сервере, но письмо сотрудника перестало доходить адресату. Объявлять миграцию завершенной рано. Web-хостинг и почта могут находиться у разных провайдеров, а DNS-зона - в третьей системе. Эти границы нужно выделить в самом начале.
Накануне: составьте инвентарь
Установите, где зарегистрирован домен, где настроена делегация nameserver, кто обслуживает DNS-зону и кто хранит почтовые ящики. Отдельно отметьте origin сайта. Наличие нескольких услуг в одной панели не доказывает единство их технического управления.
Назначьте ответственных и владельцев доступа. У разработчика может быть доступ к DNS без разрешения переносить почту. Пароли в рабочую таблицу не записывайте: достаточно владельца доступа и согласованного безопасного способа передачи.
Укажите названия систем и ответственного за каждую. Фраза «есть доступ к домену» неоднозначна: она может означать только кабинет регистратора без права менять DNS-зону. Панель хостинга может управлять файлами сайта, в то время как MX указывают на другого поставщика.
Внесите A/AAAA, CNAME, MX и почтовые TXT-записи, включая DKIM selectors. Для каждой укажите TTL, значение, назначение и необходимость изменения. Сохраните verification-записи других бизнес-сервисов. Если доступно, сделайте датированный экспорт зоны.
До изменения сохраните полный экспорт зоны или запись, позволяющую восстановить каждое значение. Скриншот не всегда показывает длинный TXT целиком. Особого внимания требуют поддомены, записи подтверждения сторонних сервисов и DKIM selectors. Перенос сайта не является причиной удалять их.
Почте нужна отдельная договоренность
Заранее решите, переезжают ли ящики. Если почта остается у прежнего провайдера, это должно быть явной целью: изменить web-адрес, сохранив маршрутизацию почты. Если переезжают и ящики, отдельно спланируйте объем, синхронизацию, учетные данные и устройства пользователей. Копирование старых писем и прием новых являются разными проверками.
MX указывает принимающий почтовый сервис. SPF описывает разрешенных отправителей для соответствующего домена; несколько отдельных SPF-политик с одним именем публиковать неправильно. Несколько текстовых фрагментов внутри одной TXT-записи являются другим случаем.
DKIM проверяет криптографическую подпись, связанную с доменом: открытый ключ находится в DNS, закрытый остается секретным. DMARC проверяет согласованность успешной SPF- или DKIM-идентификации с видимым доменом From. Успех одного механизма не подтверждает остальные условия автоматически.
Учтите всех законных отправителей: сотрудников, формы сайта, счета и маркетинговые платформы. Не включайте строгую DMARC-политику без проверки этих потоков. Изменение согласуйте с ответственным почтовым провайдером, а не рассматривайте как обычную правку сайта.
Окно переключения
Приведенная ниже последовательность - организационный пример. Конкретные действия зависят от DNS-провайдера, хостинга и почтовой системы. Отделяйте изменение от его проверки и условия продолжения. Несколько одновременных непроверенных изменений усложняют поиск причины сбоя.
- Проверьте новое окружение до изменения DNS и сохраните результаты.
- Выполните согласованные последнюю синхронизацию и план управления записью.
- Меняйте только запланированные web или mail records; полная замена зоны требует отдельного решения.
- Сопоставьте ответы authoritative DNS и обычного resolver; временное различие не всегда означает ошибку.
- Завершите раздельные приемочные тесты web и почты до закрытия окна изменений.
Предположим, условный example.com размещает сайт на одном хостинге, а почту у отдельного провайдера. Для переноса сайта может понадобиться новая origin-запись при прежнем MX. Сам перенос веб-сайта не делает смену nameserver обязательной.
При этом отдельно проверьте SMTP контактной формы. Если она начинает отправлять письма через локальный mail transport нового сервера, прежние настройки аутентификации могут больше не соответствовать маршруту. Используйте проверенный канал отправки и его документацию.
Не принимайте новый хост только по главной странице. Проверьте важный внутренний адрес, загрузку файла и операцию записи в базу. Выберите способ проверки, при котором две среды не накопят противоречащие друг другу реальные данные. Для работающего магазина особенно важны последняя синхронизация и окно записи.
Работающий сайт - повод отдельно проверить почту
Снижение TTL не отменяет мгновенно уже сохраненные ответы resolver. После согласованного изменения сравните authoritative-ответы и рекурсивные resolver нужных пользователей. Правильный ответ на одном устройстве не подтверждает завершение перехода во всех сетях.
При смене mail provider согласуйте первоначальное копирование, последнюю синхронизацию и время переключения. Отдельно проверьте aliases, forwarding, общие ящики и SMTP/IMAP на устройствах. Создание пустого ящика не переносит историю сообщений.
Проверки входящей и исходящей почты фиксируйте отдельно. Согласованным тестовым письмом проверьте обмен с внешним адресом, результат authentication в принятом сообщении и SMTP-учетную запись самого сайта. Работающий ящик сотрудника не доказывает правильность SMTP-настроек формы.
Определите, что именно означает возврат
Возврат DNS-записи не переносит обратно письма, уже принятые другой системой. План должен показывать, где на каждом этапе находятся новые сообщения, кто завершает синхронизацию и когда можно отключить прежнюю услугу. Не удаляйте данные только потому, что сайт открылся.
Для rollback недостаточно одного ограничения по времени. Если возврат потеряет полученные в новой системе письма или созданные заказы, восстановления DNS-адреса уже мало. Заранее определите источник данных, способ сверки изменений и ответственного за решение.
Что должно остаться при сдаче работы
При сдаче оставьте короткую понятную запись: где работает сайт, где осталась или куда перешла почта, кто управляет зоной и какие тесты прошли. Непроверенное укажите отдельно. Следующему сотруднику не придется заново выяснять, какую систему собирались менять.
Для миграции хостинга приложите инвентарь и явно определите объем работы с ящиками. При выборе web-хостинга уточните, какие работы входят в предложение, а какие согласуются отдельно.
О выборе окружения после переноса: Как выбрать web hosting для бизнес-сайта: 7 вопросов до цены.
Техническая основа DNS и почтовой authentication: IETF - SPF, RFC 7208; IETF - DKIM, RFC 6376; IETF - DMARC, RFC 9989.
