Перенос корпоративной почты на Яндекс 360
Инструкция · 2026-09-03 · 10 мин чтения
Почту переносят по одному и тому же сценарию: подготовили домен, открыли доступ к старым ящикам, перенесли письма, переключили приём почты на новый сервис. Всё, что обычно идёт не так, укладывается в три-четыре места — про них и поговорим подробнее, чем принято.
Речь про Яндекс 360 для бизнеса: почта на своём домене, диск, документы и видеовстречи. Механика ниже проверена по документации сервиса; где есть ограничения — говорим о них прямо, а не «всё переносится автоматически».
Замена Microsoft 365: что совпадает, а что проверить
Чаще всего на 360 приходят именно из Microsoft 365, и причин обычно две. Практическая: для российских компаний продлить подписку Microsoft и оплатить её привычным способом уже не получается, а поддержки нет. И вторая, более приземлённая — считать стало проще: оплата в рублях, договор с российским юрлицом, закрывающие документы.
Как замена 360 закрывает почти весь привычный набор: почта на своём домене, облачный диск, документы онлайн, календарь, видеовстречи, мессенджер и админка с правами и политиками. Плюс важное для многих: сервис входит в реестр российского ПО, то есть годится там, где требуется отечественное — а с этим требования постепенно ужесточаются.
Но честно о разнице. Полноценных настольных Word и Excel здесь нет — работа с документами идёт в браузере. Для большинства офисных задач этого достаточно, а вот если у вас есть тяжёлые файлы с макросами, сложными сводными таблицами или самописными надстройками, проверьте их на своих документах до переезда, а не после. Это касается любого перехода с Microsoft, не только на 360; подробнее мы разбирали это на примере офисных пакетов.
Разумный порядок: сначала переносите почту, а документы и диск — вторым шагом, когда люди привыкнут. Пытаться пересадить компанию сразу на всё — верный способ получить сопротивление там, где его могло не быть.
Переезд начинается не с писем, а с домена
Первый этап — доказать, что домен ваш, и переключить на него приём почты. Всё это записи в DNS:
- TXT для подтверждения — сервис выдаёт значение, вы добавляете его в зону домена; - MX — та самая запись, которая определяет, куда приходит почта. Пока она смотрит на старый сервер, письма идут туда; - DKIM — подпись, которой Яндекс подписывает исходящие письма, чтобы их не считали подделкой; - DMARC — политика, что делать с письмами, которые подпись не прошли.
И отдельно — SPF, на котором спотыкаются чаще всего.
Одна SPF-запись, а не две
SPF перечисляет, кому разрешено отправлять почту от имени вашего домена. Логика подсказывает добавить запись Яндекса рядом с существующей — и вот это ломает почту.
У домена должна быть ровно одна SPF-запись. Если их две, стандарт предписывает считать конфигурацию некорректной, и часть получателей начнёт отклонять ваши письма. Со стороны выглядит странно: почта переехала и работает, а письма клиентам возвращаются.
Правильно — слить значения в одну строку. Если у вас уже отправляет рассылочный сервис, CRM или сайт, их разрешения нужно сохранить и дописать к ним значение Яндекса, а не заводить вторую запись.
Здесь стоит остановиться и проверить результат, прежде чем идти дальше.
Как переносятся письма
Инструмент миграции живёт в панели администратора: Почта → Миграция. Если вы переезжаете не с другого известного сервиса, а со своего сервера или хостинга, выбирается источник «Другой сервер», и дальше нужно указать:
- адрес IMAP-сервера, - порт и тип шифрования, - пароли пользователей.
Письма переносятся с сохранением структуры папок — вложенность и названия остаются, разбирать заново ничего не придётся.
Перенос идёт в фоне и не требует, чтобы люди перестали работать: старый ящик продолжает жить, пока MX не переключён.
Главная засада: пароли и IMAP по каждому ящику
Этот пункт определяет сроки переезда сильнее, чем объём почты.
Инструменту нужны пароли сотрудников от старых ящиков. Не пароль администратора — пароли пользователей. На практике это означает одно из трёх: администратор задаёт всем временные пароли перед переездом, собирает существующие, либо переезд идёт по частям, по мере того как люди их сообщают. Ни один из вариантов не быстрый, и планировать его надо заранее, а не в день переключения.
И второе: включить IMAP и доступ по портальному паролю разом для всех ящиков нельзя. Это делается по каждому ящику отдельно. На пяти сотрудниках незаметно, на тридцати — отдельный этап работы, который стоит времени.
Если вам обещают «переедем за вечер, ничего не нужно» — спросите, как именно решается этот пункт. Ответ покажет, делал ли человек это хоть раз.
Что не переносится вовсе
Что придётся делать руками:
- Архивные ящики Exchange Online Archiving. Инструмент их не поддерживает. Содержимое выгружается в PST и загружается отдельно, руками. - Файлы из общих сетевых папок. Это не почта, и через почтовую миграцию они не поедут — переносятся отдельно, через приложение Диска или по WebDAV. - Календари, контакты и правила обычно требуют отдельного внимания: что-то переносится, что-то придётся пересобрать. Проверяйте на одном сотруднике до того, как обещать результат всем.
Сколько это занимает на самом деле
Само переключение MX — минуты. Дальше играет роль то, что от вас не зависит: обновление DNS у провайдеров занимает от нескольких минут до нескольких часов, и всё это время часть писем ещё приходит на старый сервер. Поэтому старый ящик нельзя выключать сразу — пусть поработает параллельно хотя бы несколько дней.
Реалистичная картина для компании на два-три десятка человек: подготовка домена и записей — день, включение IMAP и сбор паролей — самая долгая часть, перенос писем — фоном, сутки-двое в зависимости от объёма. Плюс неделя, когда старый сервер ещё жив на всякий случай.
Своя почта или облако
Облако нужно не всем, и это стоит сказать до того, как вы за него заплатите.
Облако подходит, когда почта должна просто работать: не нужен сервер, обновления и админ, доступ с телефона из коробки, письма не теряются при поломке железа. Для большинства компаний до сотни человек это разумный выбор.
Свой сервер оправдан, когда есть требование хранить переписку у себя, когда почта завязана на внутренние системы, или когда компания достаточно велика, чтобы содержать инфраструктуру и человека при ней.
Мы держим собственный почтовый сервер — для себя, потому что у нас уже есть и инфраструктура, и дежурный администратор. Клиентам чаще советуем облако, и причина не в цене железа: сервер стоит недорого, дорого стоит внимание человека, который следит за очередями, местом на диске, репутацией IP и обновлениями. Если такого человека в компании нет, почта на своём сервере рано или поздно ломается в самый неподходящий момент.
Чтобы не сломать почту в день переезда
Порядок действий, который снимает большую часть рисков:
1. Выпишите все сервисы, которые шлют письма от вашего домена — рассылки, CRM, сайт, бухгалтерия. Их разрешения должны попасть в общую SPF-запись. 2. Заведите ящики заранее и проверьте на одном сотруднике весь путь: получение, отправка, телефон. 3. Включите IMAP на старом сервере и решите вопрос с паролями — это самая долгая часть. 4. Запустите перенос писем до переключения MX. Люди продолжают работать на старом ящике, а данные уже едут. 5. Переключите MX и следите за отправкой: первые письма наружу покажут, всё ли в порядке с SPF и DKIM. 6. Не выключайте старый сервер неделю. Дешёвая страховка.
Коротко
- Переезд начинается с DNS: TXT, MX, DKIM, DMARC — и одна-единственная SPF-запись, объединённая, а не вторая рядом. - Инструмент миграции: панель администратора, Почта → Миграция, источник «Другой сервер» по IMAP. - Письма переносятся с папками; архивы Exchange и файлы общих папок — нет. - Самое долгое — не перенос, а пароли сотрудников и включение IMAP по каждому ящику отдельно. - Старый сервер держите живым неделю после переключения.
Посмотреть состав и тарифы Яндекс 360 для бизнеса можно на сайте сервиса — мы участвуем в их партнёрской программе.
Если переезжать самим некогда или боязно — напишите нам. Посмотрим, откуда переезжаете, соберём DNS, перенесём письма и побудем рядом первую неделю. Для клиентов на ИТ-поддержке это входит в обслуживание.