Перенос корпоративной почты: как выполнить миграцию без потери писем и простоя бизнеса

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

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

Необходимость сменить почтовую платформу обычно продиктована четырьмя факторами:

1. Импортозамещение и санкционные риски: Отзыв корпоративных лицензий, блокировки платежей и уход зарубежных платформ (Microsoft 365 / Exchange Online, Google Workspace) сделали миграцию с Exchange на отечественную почту первоочередной задачей для российского бизнеса. Компании массово переходят в облачные среды (Яндекс 360 для бизнеса, VK WorkSpace) либо разворачивают локальные отказоустойчивые решения на базе отечественного ПО (CommuniGate Pro, RuPost, МойОфис Почта).
2. Отказ от локального серверного оборудования: Поддержание устаревших on-premise серверов Microsoft Exchange требует существенных вычислительных ресурсов, лицензий и регулярного обслуживания DAG-кластеров. Перенос инфраструктуры в облако избавляет компанию от капитальных затрат на аппаратную часть.
3. Оптимизация расходов и смена провайдера: Переход на более гибкие тарифные сетки, консолидация подписок или смена ненадежного хостинг-провайдера на профильный корпоративный сервис.
4. Реорганизация бизнеса и слияния (M&A): Объединение разрозненных доменов нескольких филиалов в единый почтовый домен с общей адресной книгой.

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

Перед началом работ формируется детальный реестр:

• Активные учетные записи и псевдонимы (aliases): Фиксируются основные адреса сотрудников и привязанные к ним алиасы (например, sales@company.ru как алиас к ivanov@company.ru).
• Общие почтовые ящики (shared mailboxes) и группы рассылки: Оценивается, как реализована внутренняя переписка отделов (бухгалтерия, поддержка, склад).
• Объем данных и почтовый архив: Определяется суммарный объем данных и размер каждого ящика. Почтовые ящики объемом более 30–50 ГБ требуют персонального внимания, так как их копирование занимает продолжительное время.
• Почтовый клиент: Анализируется программное обеспечение на конечных рабочих станциях (Outlook, Thunderbird, The Bat!, мобильные приложения) и используемые протоколы (MAPI, Exchange Web Services, IMAP, POP3). Если пользователи годами работали по протоколу POP3, часть писем может храниться исключительно локально на ПК и отсутствовать на сервере.

Таблица маппинга пользователей представляет собой матрицу соответствия исходных учетных записей целевым аккаунтам:

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

Снижение TTL в DNS — базовое техническое требование, пренебрежение которым почти гарантированно приводит к временной потере сообщений.
Параметр TTL (Time to Live) определяет, сколько секунд сторонние DNS-серверы в интернете кешируют записи вашего домена. По умолчанию для MX-записей устанавливается значение 86400 секунд (24 часа) или 43200 секунд (12 часов). Если изменить MX-запись без предварительной подготовки, почтовые серверы отправителей по всему миру будут еще целые сутки отправлять письма на старый адрес.

За 3–5 дней до назначенной даты миграции необходимо уменьшить значение TTL для MX-записей и связанных с ними A/TXT-записей до минимального значения: 300 секунд (5 минут) или 600 секунд (10 минут). Когда придет время финального переключения, изменение DNS распространится по глобальной сети практически мгновенно, что сведет к минимуму период неопределенности маршрутов.

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

В панели управления целевого сервиса (например, при решении перенести почту на Яндекс 360 или VK WorkSpace) создается профиль организации. Далее подтверждается владение корпоративным доменом через добавление верификационной TXT-записи в DNS-зону у регистратора.

Используя ранее составленную таблицу маппинга, системный администратор заводит пользователей на новом сервере. Для крупных организаций (от 50–100 человек) оптимально использовать импорт через CSV-файл либо настроить сквозную синхронизацию с локальным каталогом Active Directory по протоколу LDAP/SAML.

Чтобы исходящие письма с нового сервера не попадали в спам-листы контрагентов, защитные записи формируются заранее:

• SPF (Sender Policy Framework): Запись указывает, каким серверам разрешено отправлять почту от имени домена. На этапе миграции SPF-запись должна временно разрешать отправку как со старого, так и с нового сервера одновременно:
• v=spf1 include:_spf.yandex.net include:spf.protection.outlook.com ip4:195.xxx.xxx.xxx ~all
• DKIM (DomainKeys Identified Mail): В DNS добавляется TXT-запись с публичным криптографическим ключом, предоставленным новой системой (селектор вида mail._domainkey.company.ru). На целевом сервере активируется цифровая подпись исходящих сообщений.
• DMARC: Публикуется базовая политика со сбором отчетов без жесткой блокировки:
• v=DMARC1; p=none; sp=none; rua=mailto:dmarc-reports@company.ru

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

1.IMAP-миграция (Синхронизация по протоколу IMAP):
Целевой почтовый сервер подключается к старой системе по протоколу IMAP и постранично копирует папки и сообщения. Это универсальный способ, подходящий для большинства платформ. Он не требует остановки работы пользователей, сохраняет статусы прочтения писем и структуру каталогов. Для его реализации необходим список паролей пользователей либо поддержка мастер-пароля (Master Password / Superuser) на исходном почтовом сервере.

2.Прямой перенос через API вендоров (Автомиграция):
Использование готовых облачных инструментов миграции. Облачный провайдер связывается с Microsoft 365 или Google Workspace через сервисные аккаунты администратора по API. Данный метод не требует сбора паролей рядовых сотрудников и переносит не только письма, но и метаданные вместе со структурой учетных записей.

3.Перенос календарей и контактов:
Протокол IMAP передает исключительно почтовые сообщения, поэтому адресные книги и записи календаря переносятся отдельно. В случае Exchange/Microsoft 365 календари и контакты экспортируются в форматы iCal (.ics) и vCard (.vcf), либо передаются через API-миграторы. Если парк клиентов использует Outlook, контакты экспортируются локально в файл данных PST.

Финальный шаг переключает глобальную маршрутизацию почты на новые рельсы.

Настройка MX-записей при переезде почты выполняется в панели управления DNS-зоной домена. Старые строки с высоким приоритетом удаляются, а взамен прописываются адреса целевой системы:

• Для Яндекс 360: приоритет 10, значение mx.yandex.net.
• Для VK WorkSpace: приоритет 10, значение mxs.mail.ru.
• Благодаря тому, что на первом этапе TTL был заблаговременно снижен до 300 секунд, глобальное обновление маршрутов займет не более 5–15 минут.

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

1. Серверная переадресация (Forwarding): На старом сервере для всех ящиков активируется безусловная переадресация входящих писем на технические адреса нового сервера.
2. Дельта-синхронизация: Спустя 24 часа после смены MX-записи системный администратор запускает повторную итерацию IMAP-миграции. Процесс сканирует исходные ящики и переносит только те сообщения, которые успели поступить на старый сервер в переходный период.
3. Финальная корректировка SPF: Из SPF-записи в DNS удаляются адреса старого сервера, а в DMARC-политике параметр p=none переводится в режим карантина p=quarantine или полной защиты p=reject.

Самостоятельный перенос почтовой системы — это высокий риск потерять важные архивы переписки с клиентами, столкнуться с блокировкой писем спам-фильтрами или оставить компанию без связи на несколько дней. Инженеры Net Admin проведут полный цикл миграции корпоративной почты «под ключ»: от аудита старых серверов и настройки DNS/SPF-записей до бесшовного переноса гигабайт писем, контактов и календарей в новое облако (Яндекс 360, VK WorkSpace) или на ваш локальный сервер. Мы гарантируем нулевой простой и сохранность каждого письма. Доверьте ИТ-инфраструктуру профессионалам.