Как перенести корпоративную почту: план миграции

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

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

Определите объём и критерии успеха

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

Полезная таблица содержит минимум следующие поля:

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

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

Проведите аудит текущей конфигурации

Сохраните действующие MX, SPF, DKIM и DMARC, а также TTL этих записей. Зафиксируйте их текстом или экспортом зоны, а не только снимком экрана. Если после переключения возникнет серьёзная проблема, точные прежние значения понадобятся для возврата.

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

• форма обратной связи на сайте;
• CRM и система счетов;
• уведомления приложения;
• сервис массовых или транзакционных рассылок;
• сканеры и другие офисные устройства.

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

Проверьте, где фактически управляется DNS. Доступ к кабинету регистратора не поможет, если зона делегирована другим NS-серверам. Роли записей и типовые ошибки подробно разобраны в материалах MX-запись для почты и SPF, DKIM и DMARC.

Подготовьте новый контур до переключения

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

До изменения MX проверьте вход в веб‑почту, IMAP и SMTP. Почтовые приложения лучше настроить заранее как отдельный аккаунт, не удаляя старый. Тогда пользователь сможет видеть оба контура в переходный период и сравнивать папки.

На этом же этапе новый провайдер выдаёт значения MX, SPF, DKIM и DMARC. Сверьте имена, типы записей и приоритеты. Политику DMARC нельзя усиливать вслепую: сначала все реальные источники отправки должны корректно проходить SPF или DKIM с нужным выравниванием домена.

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

Скопируйте архив по IMAP

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

Перед копированием проверьте:

1. доступность IMAP на старой и новой стороне;
2. корректность паролей или специальных паролей приложений;
3. достаточный объём нового ящика;
4. список папок и их кодировку;
5. ограничения скорости и количества соединений;
6. локальные папки, которые не видны на сервере.

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

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

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

Переключите MX в согласованное окно

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

DNS использует кэширование. Разные отправляющие серверы могут увидеть новое значение не одновременно, поэтому в переходный период письма способны приходить в оба контура. Уменьшение TTL заранее сокращает время хранения новых ответов, но не удаляет запись из уже существующего кэша.

После публикации нового набора MX проверьте ответы через независимые DNS-резолверы. Затем проведите тесты:

• отправьте письмо с внешнего сервиса на несколько адресов домена;
• ответьте через веб‑почту нового сервиса;
• повторите отправку через настроенный SMTP-клиент;
• проверьте папки «Входящие», «Отправленные» и «Спам»;
• посмотрите результаты SPF, DKIM и DMARC в заголовках;
• убедитесь, что старые ящики всё ещё доступны.

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

Подготовьте план возврата

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

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

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

Проведите приёмку и только потом отключайте старую почту

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

Старый сервис можно отключать, когда одновременно выполнены условия:

1. публичные DNS-записи стабильны;
2. входящая и исходящая переписка проверена;
3. владельцы подтвердили согласованные архивы;
4. ошибки миграции разобраны или задокументированы;
5. локальные данные, контакты и календари сохранены отдельно;
6. прошёл согласованный контрольный период.

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

Короткий сценарий без импровизации

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

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

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

Источники

• RFC 9051: Internet Message Access Protocol
• RFC 5321: Simple Mail Transfer Protocol
• RFC 7208: Sender Policy Framework
• Google: требования к отправителям писем
• Microsoft Learn: аутентификация электронной почты