Как перенести корпоративную почту с Яндекс 360: варианты, сроки, порядок работ и риски

Перенос почты с Яндекс 360 на собственный сервер — самый надёжный способ перестать зависеть от чужих аварий. Облачная почта — это переписка вашей компании на чужом оборудовании: когда у провайдера горит дата-центр или пропадает питание, вы ничего не можете сделать, только ждать. В октябре 2026 года «Яндекс» сообщал о повреждении сразу нескольких своих дата-центров, у пользователей были трудности с почтой. Свой почтовый сервер — mailcow, Carbonio CE, iRedMail или ящики на нашей инфраструктуре — возвращает компании контроль: письма, бэкапы и время восстановления зависят от вас. Переезд для 10–50 ящиков занимает 3–5 рабочих дней после аудита, сотрудники работают в старой почте до переключения, письма не теряются.

Облако — это чужой сервер, и это главный риск

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

Облако объединяет в одной точке всё: почту, календари, документы, видеозвонки, иногда и DNS домена. Авария одной площадки провайдера бьёт по всем этим сервисам одновременно, и компания остаётся без связи с клиентами, банками и контрагентами разом.

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

Именно поэтому мы рекомендуем компаниям уходить с облачной почты на собственный сервер — свой или на инфраструктуре подрядчика — и в любом случае держать копию переписки вне облака. Ниже — как это сделать без потери писем.

Почему компании задумались о переносе почты именно сейчас

8 октября 2026 года, по сообщениям СМИ, в дата-центре «Яндекса» в Сасово Рязанской области после атаки беспилотников произошёл пожар, работа площадки была остановлена. Компания сообщала, что ситуация на площадке под контролем, основные сервисы работают штатно, но часть из них может быть недоступна для пользователей (Интерфакс). В тот же день у пользователей были трудности с Яндекс Почтой; в «Яндекс 360» сообщили, что проблемы оперативно устранены и почта работает в обычном режиме (Ведомости).

11 октября «Яндекс» сообщил о новом инциденте: инфраструктура дата-центра во Владимире повреждена в результате атаки беспилотников, работа дата-центра полностью остановлена, часть сервисов недоступна для пользователей, пострадавших нет (Интерфакс). Мы не пишем здесь о том, какие сервисы и как долго были недоступны: актуальное состояние проверяйте по официальным сообщениям компании.

Речь не о том, что облачная почта ненадёжна. Речь о другом: многие компании в эти дни впервые увидели, что вся их переписка с клиентами, банками и контрагентами зависит от одного поставщика, а запасного пути нет. Именно этот вопрос — «что мы делаем, если почта недоступна» — и стоит решить спокойно, без спешки.

Вариантов два. Первый — перенести почту на другую площадку: в другое облако, на свой сервер или в гибридную схему. Второй — оставить почту в Яндекс 360, но построить резерв: регулярную копию всех ящиков и план быстрого переключения. Эта статья — общее руководство по обоим путям: что переносится и как, куда переносить, в каком порядке действовать, сколько это занимает и где чаще всего ошибаются.

Что на самом деле нужно перенести

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

Параметры IMAP приведены по справке Яндекс 360 для бизнеса: кроме адреса и порта, в настройках ящика нужно включить доступ «С сервера imap.yandex.ru по протоколу IMAP», а подключаться с паролем приложения или OAuth-токеном. Логин для бизнес-аккаунта — полный адрес ящика. Контакты по справке выгружаются кнопкой «Экспорт контактов» в файл vCard. Календари по справке о экспорте отдаются в форматах iCal и HTML (только владельцу календаря) и по CalDAV.

Яндекс 360 — это ещё Диск, документы и видеозвонки. Их перенос — отдельный проект; в этой статье речь о почте, а для Диска и календарей в серии есть отдельные материалы.

Куда переносить почту: пять вариантов

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

Про реестр: CommuniGate Pro внесён в единый реестр российских программ (запись № 7112 от 12.10.2020, по данным производителя), RuPost — запись № 14647 от 23.08.2022 (Интерфакс), Mailion — запись № 12707 (реестр Минцифры). Для госзаказчиков и компаний с требованиями к импортозамещению это существенно; для небольшой фирмы обычно важнее цена владения и наличие специалиста.

Из открытых решений чаще всего выбирают mailcow (набор контейнеров Docker с веб-интерфейсом, антиспамом и веб-почтой SOGo), iRedMail (установщик связки Postfix, Dovecot и веб-интерфейса на обычный Linux-сервер) и Carbonio CE (наследник Zimbra с веб-клиентом, календарями и адресной книгой). Stalwart — более новый сервер, написанный на Rust, который в одном процессе поддерживает IMAP, JMAP, SMTP, CalDAV и CardDAV; распространяется по AGPL-3.0 и коммерческой лицензии (GitHub проекта). Подробное сравнение mailcow, iRedMail и Carbonio — в нашей статье «iRedMail, mailcow, Carbonio CE: что выбрать офису».

Если уходить из облака полностью пока рано, есть шестой путь — резервный контур: почта остаётся в Яндекс 360, а копия всех ящиков регулярно синхронизируется на ваш сервер. При сбое сотрудники открывают копию и продолжают работать с перепиской. Как это устроить, разобрано ниже, в разделе о резерве.

Облако на российской площадке: что проверить до переезда

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

Что выяснить у провайдера до подписания договора: где физически размещаются данные и есть ли резервная площадка; какое время восстановления указано в соглашении об уровне сервиса и что вы получаете при его нарушении; доступен ли IMAP для выгрузки всех ящиков и нет ли ограничений на число подключений; можно ли выгрузить контакты и календари в стандартных форматах (vCard, iCal); есть ли у администратора доступ к журналам входов.

Цены облачных тарифов меняются, поэтому сравнивайте их на дату решения по официальным страницам тарифов и обязательно смотрите, что входит в тариф: объём ящика, число адресов, архив, поддержка. В отдельной статье серии мы разбираем перенос в VK WorkSpace — одно из популярных направлений.

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

Свой почтовый сервер: из чего он состоит и кто его обслуживает

Собственный сервер — это несколько компонентов, которые должны работать вместе: сервер приёма и отправки почты (MTA, чаще всего Postfix), сервер хранения и доступа к ящикам (IMAP, чаще всего Dovecot), антиспам и антивирус, веб-почта, календари и адресные книги, если они нужны, система резервного копирования и мониторинг. Готовые сборки — mailcow, iRedMail, Carbonio CE — устанавливают и связывают эти компоненты за вас, но обслуживать их всё равно придётся.

Что входит в обслуживание: установка обновлений безопасности (почтовые серверы — постоянная цель атак), контроль очереди писем и отказов доставки, проверка, что бэкапы не только делаются, но и восстанавливаются, продление сертификатов, наблюдение за репутацией IP-адреса и чёрными списками, реакция на подозрительные входы. Как выглядит такой регламент на практике, мы описывали на примере эксплуатации mailcow.

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

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

Российские коммерческие почтовые системы: когда они оправданы

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

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

При выборе уточните у производителя или интегратора: поддерживает ли система IMAP для загрузки почты через imapsync или есть собственный инструмент миграции; как переносятся календари и контакты; какие клиенты поддерживаются (Outlook, мобильные приложения, веб); какие требования к серверам.

Гибридная схема: часть ящиков в облаке, часть у себя

Гибрид нужен, когда разным группам сотрудников подходят разные решения. Например, руководство и бухгалтерия — на собственном сервере с полным контролем над данными, а сотрудники, которым нужна только простая почта, — в облаке. Или наоборот: основная почта у себя, а облачный сервис используется как резервный.

Технически домен один, а ящики живут на разных серверах. Почта для домена приходит на один сервер (тот, на который указывает MX), и он пересылает письма для «чужих» ящиков на второй сервер. В Postfix это делается таблицей транспорта — для каждого адреса указывается, куда его доставлять. SPF при этом должен разрешать отправку обоим серверам.

Гибрид сложнее в обслуживании: две системы, две точки отказа, две политики безопасности. Используйте его, когда для этого есть конкретная причина, а не «на всякий случай».

Как выбрать: вопросы, на которые стоит ответить заранее

Чтобы не выбирать по рекламе, ответьте на несколько вопросов. Ответы сразу отсекают половину вариантов.

Есть ли у вас человек, который будет обслуживать почтовый сервер? Свой сервер — это не «поставил и забыл»: нужны обновления безопасности, контроль очереди, бэкапы с проверкой восстановления и реакция на взломы. Если специалиста нет, рассматривайте облако или обслуживание у подрядчика.

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

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

Что ещё завязано на почту? Сканеры, отправляющие документы на e-mail, 1С и CRM с рассылками, сайт с формой обратной связи, банковские уведомления — всё это нужно перенастроить на новые SMTP-параметры. Составьте список заранее.

Нужны ли календари и общий доступ, как в Яндекс 360? Если сотрудники активно планируют встречи, выбирайте вариант с календарём и веб-клиентом (Carbonio CE, mailcow с SOGo, коммерческие системы), а не «голый» Postfix + Dovecot.

Персональные данные в почте: что учесть при выборе площадки

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

Базовое требование закона о персональных данных о локализации — часть 5 статьи 18 Федерального закона № 152-ФЗ: при сборе персональных данных граждан России оператор обязан обеспечить их запись, систематизацию, накопление, хранение, уточнение и извлечение с использованием баз данных, находящихся на территории Российской Федерации. Статья 19 того же закона требует принимать правовые, организационные и технические меры для защиты персональных данных.

Практически это означает несколько вопросов к любой площадке. Где физически находятся серверы и резервные копии? Кто из сотрудников провайдера или подрядчика имеет доступ к ящикам? Ведутся ли журналы доступа и можно ли их получить? Как удаляются данные после расторжения договора? Для собственного сервера ответы на эти вопросы у вас, для облака — в договоре и документах провайдера.

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

Сколько времени занимает перенос

Сроки складываются из подготовки, переноса данных и сопровождения. Для ориентира — этапы, которые мы указываем на странице услуги: аудит текущей почты и домена — 1–2 рабочих дня, план миграции и смета — 1 рабочий день, настройка сервера, DNS и перенос ящиков — 3–5 рабочих дней, затем 5 рабочих дней сопровождения сотрудников и проверки доставляемости.

Сам перенос писем занимает меньше времени, чем кажется. На нашем тестовом стенде imapsync перенёс ящик на 755 писем за 11 секунд, а после искусственного обрыва докачал 298 писем объёмом 261 МиБ за 19 секунд. С облачным сервисом через интернет скорость ниже, поэтому реальную оценку даёт пробный перенос одного большого ящика.

Что действительно растягивает проект: согласования внутри компании, сбор паролей приложений от сотрудников, перенастройка телефонов и ноутбуков, а также интеграции — 1С, сканеры, CRM. Закладывайте время именно на них.

Чем отличается переезд для 5, 30 и 200 ящиков

Порядок работ одинаковый, но акценты разные.

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

15–50 ящиков. Появляются общие ящики, рассылки и интеграции, которые легко забыть, поэтому инвентаризация становится обязательной. Перенос писем запускают в несколько потоков по списку. Нужен письменный план переключения и инструкция для сотрудников, а в первый рабочий день — дежурство администратора.

50–200 ящиков и больше. Перенос писем растягивается на дни, поэтому его начинают заранее и повторяют проходы до переключения. Добавляются вход через LDAP или Active Directory, требования к хранению переписки и, нередко, к импортозамещению. Здесь уже имеет смысл пилот: перенести одну группу сотрудников, посмотреть на проблемы и только потом переводить остальных. О переносе больших ящиков и сотен ящиков без простоя — отдельная статья серии.

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

Порядок работ: от аудита до отключения старой почты

Ниже — последовательность, при которой сотрудники продолжают работать в старой почте до последнего момента, а письма не теряются при переключении.

Шаг 1. Инвентаризация. Список ящиков, алиасов, рассылок и общих ящиков; объём каждого ящика; кто пользуется календарями; какие устройства и программы отправляют почту через Яндекс; где размещена DNS-зона домена.

Шаг 2. Выбор площадки и подготовка нового сервера. Сервер или облачный тариф, домен добавлен, ящики созданы, лимиты на размер письма и квоты не меньше, чем были. DNS-записи для нового сервера подготовлены, но MX пока не меняются.

Шаг 3. Подготовка ящиков в Яндекс 360. Включить IMAP, создать пароли приложений. Подробно — в статье серии о подготовке Яндекс 360 к выгрузке.

Шаг 4. Первый перенос писем. imapsync с опцией --automap, ящик за ящиком или в несколько потоков. Повторные проходы докачивают новое — подробная инструкция с командами в статье «Перенос почты через imapsync».

Шаг 5. Контакты и календари. Экспорт vCard и iCal либо синхронизация по CardDAV и CalDAV, затем импорт на новом сервере.

Шаг 6. Снижение TTL DNS-записей за сутки-двое до переключения, чтобы изменения разошлись быстро.

Шаг 7. Переключение: смена MX, обновление SPF, публикация DKIM нового сервера, DMARC в режиме мониторинга. Делается в согласованное окно, обычно вечером или в выходные.

Шаг 8. Финальный проход imapsync с ограничением по возрасту писем, чтобы забрать всё, что успело прийти в старые ящики.

Шаг 9. Перенастройка клиентов: почтовые программы, телефоны, сканеры, 1С, сайт.

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

Шаг 11. Отключение старой почты — не раньше, чем через несколько недель, после контрольного полного прохода imapsync и сверки.

Подготовка Яндекс 360 к выгрузке: коротко

Чтобы забрать письма по IMAP, доступ по этому протоколу должен быть разрешён и на уровне организации, и в каждом ящике. По справке для администраторов протоколы для почтовых программ включаются в разделе «Почта» → «Настройки», блок «Использовать протоколы». В настройках самого ящика включается опция «С сервера imap.yandex.ru по протоколу IMAP».

Для подключения нужен пароль приложения (или OAuth-токен) — обычный пароль от аккаунта для IMAP не подходит. По справке Яндекс ID пароль приложения показывается только один раз и начинает действовать через 2–3 часа после создания — поэтому пароли создают заранее и сразу записывают в файлы для imapsync. Сбор паролей приложений от сотрудников — самая медленная часть подготовки: начните её в первый же день проекта.

Перед массовым переносом проверьте подключение на одном ящике командой imapsync с опцией --justfoldersizes: она подключится, покажет папки и объём и ничего не изменит. Если вход не проходит — почти всегда виноват выключенный IMAP или обычный пароль вместо пароля приложения.

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

Переключение удобно планировать на вечер пятницы или выходные. Ниже — типовая последовательность; конкретное время зависит от TTL ваших записей и числа устройств.

За 1–2 суток: TTL записей MX и SPF снижен, последний полный проход imapsync выполнен, сотрудникам разослано уведомление с инструкциями.

Время «Ч»: меняются MX-записи, в SPF добавляется новый сервер, публикуется DKIM нового сервера (если не был опубликован заранее), DMARC остаётся в режиме наблюдения. Сразу после этого администратор отправляет тестовые письма на несколько внешних адресов и с них — на ящики компании.

«Ч» плюс время TTL: проверяется, что новые письма приходят на новый сервер. Запускается финальный проход imapsync с --maxage, который забирает письма, успевшие прийти на старые ящики.

Утро первого рабочего дня: перенастройка телефонов и программ по инструкции, помощь сотрудникам, перенастройка 1С, МФУ и сайта по списку интеграций.

Первая неделя: контроль доставляемости, отчёты DMARC, повторные проходы imapsync по старым ящикам, пока на них ещё что-то приходит.

Интеграции: что ещё отправляет почту от имени компании

Самые неприятные сюрпризы после переезда связаны не с ящиками сотрудников, а с устройствами и программами, которые отправляют почту сами. Их забывают, потому что они годами работают незаметно.

1С и другие учётные системы: рассылка счетов, актов, расчётных листков. В настройках учётной записи электронной почты нужно сменить SMTP-сервер, порт и пароль. Проверьте и отправку, и получение, если 1С забирает входящие письма.

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

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

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

• 1С: учётные записи электронной почты в каждой базе
• МФУ и сканеры: SMTP-сервер, порт, учётная запись
• сайт: SMTP-настройки CMS и плагинов форм
• CRM и сервисы рассылок: домены отправителя и DKIM
• оборудование с почтовыми оповещениями: ИБП, видеонаблюдение, мониторинг

Сотрудники: как провести переезд без потери рабочего дня

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

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

В день после переключения выделите время на помощь: самые частые обращения — «не могу войти на телефоне», «нет писем в программе» (программа ещё смотрит на старый сервер) и «где мои папки» (папки есть, но в программе нужно обновить список подписок).

Отдельно предупредите тех, кто отвечает за рассылки и интеграции: бухгалтерию (1С), отдел продаж (CRM), ответственного за сайт.

Клиенты и контрагенты: нужно ли им что-то сообщать

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

Исключения — случаи, когда меняется что-то видимое для внешней стороны. Если компания переезжала с адресов вида имя@yandex.ru на собственный домен, клиентов нужно предупредить и настроить пересылку со старых адресов на новые на переходный период. Если с вами обмениваются документами через ЭДО или порталы, где указан почтовый адрес для уведомлений, проверьте, что адрес там тот же.

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

DNS при переезде: MX, SPF, DKIM, DMARC и TTL

Переключение почты — это изменение DNS-записей домена. От того, насколько аккуратно оно сделано, зависит, потеряются ли письма в первые часы и не попадут ли ваши письма в спам у получателей.

MX-записи указывают, на какой сервер доставлять почту для домена. После их смены отправители начинают слать письма на новый сервер, но не мгновенно: DNS-серверы по всему интернету хранят старое значение до истечения TTL. Поэтому TTL снижают заранее, а финальный проход imapsync делают после переключения.

SPF (RFC 7208) — список серверов, которым разрешено отправлять почту от имени домена. При переезде в него добавляют новый сервер, а записи старого провайдера убирают, только когда через него точно никто больше не отправляет — включая сканеры и 1С.

DKIM (RFC 6376) — подпись писем ключом домена. Новый сервер подписывает своим ключом с собственным селектором; его публичную часть публикуют в DNS до переключения, тогда первые же письма уйдут подписанными.

DMARC (RFC 7489) говорит получателям, что делать с письмами, не прошедшими SPF и DKIM, и куда слать отчёты. На время переезда разумно держать политику в режиме наблюдения (p=none) и читать отчёты, а ужесточать после того, как убедились, что все легитимные отправители проходят проверку.

Подробно — с примерами записей и порядком действий по часам — в статье серии о смене MX, SPF, DKIM и DMARC. Если DNS-зона домена тоже обслуживается Яндексом, её сначала переносят к другому DNS-провайдеру, а уже потом переключают почту.

Письма во время переключения не теряются — почему

Частый страх — «пока DNS обновляется, письма уйдут в никуда». На практике почтовая система устойчива к кратким перерывам. Если сервер получателя временно недоступен, сервер отправителя не выбрасывает письмо, а ставит его в очередь и повторяет попытки: по RFC 5321 время, через которое отправитель отказывается от доставки, как правило, должно составлять не менее 4–5 дней.

При переезде письмо в переходный период попадёт либо на старый сервер (если отправитель ещё видит старый MX), либо на новый. Письма, пришедшие на старый, забирает финальный проход imapsync. Чтобы ничего не осталось незамеченным, старые ящики оставляют активными, пока не пройдёт срок кэширования DNS и пока не сделан контрольный проход.

Для компаний, которым важен каждый час, есть схема двойной доставки: на время переезда письма доставляются одновременно на старый и новый сервер. Она сложнее в настройке и подробно разобрана в отдельной статье серии.

Если переезжать рано: резервный контур для почты в Яндекс 360

Не всем нужно уходить из облака. Иногда достаточно, чтобы при недоступности сервиса у компании оставался доступ к переписке и способ быстро переключить приём почты.

Минимальный резерв — регулярная копия всех ящиков на ваш сервер. Тот же imapsync, запущенный по расписанию, синхронизирует новые письма; после первого прохода каждый следующий занимает минуты. При сбое у сотрудников остаётся доступ к архиву через веб-почту резервного сервера.

Следующий уровень — готовый к работе резервный сервер с теми же ящиками. Если основной сервис недоступен долго, меняете MX на резервный сервер, и почта начинает приниматься там; после восстановления основного сервиса письма переносятся обратно тем же imapsync. Решение о таком переключении принимается заранее: кто, при какой длительности недоступности и по какой инструкции его делает.

Отдельно о бэкапе писем в облачных сервисах — в нашей статье «Бэкап Яндекс 360 и Google Workspace: кто отвечает».

Архив, удалённые письма и ящики уволенных сотрудников

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

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

Возможности архивирования и восстановления удалённых писем в Яндекс 360 зависят от тарифа и настроек организации — уточните их в справке и в настройках вашей организации до начала проекта.

Из чего складывается стоимость переезда

Стоимость состоит из разовой работы и ежемесячных расходов. Разовые: аудит, проектирование, подготовка сервера или облака, перенос ящиков, календарей и контактов, переключение DNS, перенастройка устройств и программ, сопровождение. Ежемесячные: тариф облака или сервер (собственный или арендованный), лицензии, если выбрана коммерческая система, и обслуживание.

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

Наши подтверждённые цены приведены в блоке ниже и на странице услуги; точную смету мы фиксируем после аудита.

Что зафиксировать в договоре с подрядчиком

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

Отдельно — передача дел: учётные записи администратора, документация по серверу, расположение бэкапов и порядок восстановления. Даже если подрядчик будет обслуживать почту дальше, эти сведения должны быть у компании.

И не соглашайтесь на обещание «100 % без простоя», если оно не подкреплено договором. Честная формулировка — перенос с минимальным простоем в согласованное окно и гарантированный перенос всех писем, которые были в ящиках на момент финального прохода.

Ошибки, которые делают при самостоятельном переезде

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

Забывают про SPF и DKIM. Новый сервер отправляет письма, но получатели складывают их в спам или отклоняют, потому что в SPF указан только старый провайдер, а DKIM не опубликован.

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

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

Переносят только почту. Через неделю выясняется, что пропали календари, общие ящики и правила, а у сканеров и 1С перестала уходить почта.

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

Риски переезда и как их закрыть

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

Безопасность нового сервера в первый день

Если вы переезжаете на собственный сервер, он должен быть защищён до того, как на него переключится почта, а не после. Минимальный набор: актуальные обновления всех компонентов; доступ к административной панели — только из сети компании или через VPN; защита от подбора паролей (например, fail2ban или встроенные механизмы сборки); сложные пароли и двухфакторная аутентификация для администраторов; сертификаты TLS на все почтовые протоколы; закрытые наружу служебные порты.

Отдельно проверьте, что сервер не является открытым релеем — не пересылает письма от посторонних на посторонние адреса. Иначе через несколько часов его используют для рассылки спама, и IP-адрес попадёт в чёрные списки. Как это проверяется в Postfix, мы разбирали в статье «Postfix: приём почты без пароля или открытый relay?».

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

Как проверить, что переезд прошёл успешно

Проверка состоит из трёх частей: всё ли перенесено, ходит ли почта и не попадают ли ваши письма в спам.

Полнота переноса: для каждого ящика сравните число писем и объём на старом и новом сервере (imapsync с --justfoldersizes), убедитесь, что в логах переноса нет ошибок, и выборочно откройте старые письма с вложениями. Контакты и календари проверьте у нескольких сотрудников, которые ими активно пользуются.

Почтовый поток: отправьте письма с новых ящиков на внешние адреса у разных почтовых сервисов и обратно. В заголовках полученного письма в поле Authentication-Results должны быть результаты spf=pass, dkim=pass и dmarc=pass.

Репутация: проверьте IP-адрес нового сервера по основным чёрным спискам и наличие PTR-записи. Подключите получение отчётов DMARC и в первые недели просматривайте их: в них видно, какие серверы отправляют почту от имени вашего домена и проходят ли они проверки. О мониторинге чёрных списков — в нашей статье «Мониторинг чёрных списков почты».

После переезда: первые 30 дней

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

Через две-три недели, если отчёты DMARC показывают, что все легитимные отправители проходят проверки, политику можно постепенно ужесточать: сначала p=quarantine, затем p=reject. Это защищает ваш домен от подделки писем от его имени.

В конце месяца — контрольный полный проход imapsync, финальная сверка и решение об отключении старой почты. Зафиксируйте в документах: где теперь почта, кто администратор, где бэкапы и как их восстановить, кто отвечает за продление домена и сертификатов. Эта документация понадобится при первом же инциденте.

Перенос в цифрах на примере стенда

Чтобы не опираться на чужие цифры, мы собрали стенд: два сервера Dovecot 2.4.5 и imapsync 2.326 в Docker, тестовые ящики с кириллическими папками, вложениями и отметками. Результаты:

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

Чек-лист переезда почты с Яндекс 360

Распечатайте или скопируйте в задачу — по этому списку удобно вести проект.

• составлен список ящиков, алиасов, рассылок, общих ящиков и их владельцев
• известен объём каждого ящика и где размещена DNS-зона домена
• выбрана площадка; на новом сервере созданы ящики, квоты и лимиты не меньше прежних
• подготовлены SPF, DKIM и PTR для нового сервера, DMARC в режиме p=none
• в Яндекс 360 включён IMAP, созданы пароли приложений
• выполнен первый перенос писем, в логах нет ошибок
• выгружены и загружены контакты и календари
• за 1–2 суток снижен TTL записей
• в согласованное окно переключены MX и обновлён SPF
• выполнен финальный проход imapsync
• перенастроены почтовые программы, телефоны, сканеры, 1С, сайт
• проверены входящие и исходящие письма, отсутствие в чёрных списках
• через несколько недель — контрольный проход, сверка и только потом отключение старых ящиков

Частые вопросы