Переезд с Яндекс 360 на Mailu: как мы перенесли 28 ящиков клиента и сократили расходы на почту в несколько раз

Экономика вопроса: считаем на калькуляторе клиента

Меня зовут Евгений Семёнов, я технический директор ITfresh. Расскажу реальный кейс: как мы переносили торговую компанию на 28 сотрудников с Яндекс 360 на собственный почтовый сервер Mailu. Начну с того, с чего начинается любой такой проект, — с денег, потому что именно экономика чаще всего и запускает разговор о переезде.

Яндекс 360 для бизнеса — хороший продукт, но это подписка за каждого сотрудника, и платить её нужно каждый месяц, пока существует компания. Актуальные тарифы на 2026 год: минимальный — от 319 ₽ в месяц за пользователя, основной — 549 ₽, продвинутый — 720 ₽. С 1 июля 2026 года корпоративные подключения переведены на обновлённые условия — порядка 485 ₽ в месяц за сотрудника. Возьмём наши 28 человек по средней ставке: это примерно 13–15 тысяч рублей в месяц, около 160–180 тысяч в год, и эта сумма никуда не денется — она повторяется каждый год и имеет свойство расти.

Что в другой чаше весов. Свой Mailu — это VPS примерно за 700 ₽ в месяц (около 8,4 тысячи в год), разовое внедрение и час-другой нашего обслуживания в месяц. Даже с учётом работ по переезду и сопровождению годовые расходы на порядок ниже подписки, а главное — они не масштабируются с числом сотрудников: примете вы ещё десять человек или двадцать, сервер тот же, доплаты за ящики нет.

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

Главный принцип, которого мы держимся: никаких «переехали за ночь». Резкое переключение — это гарантированные потерянные письма и паника у сотрудников. Вместо этого мы делаем параллельный период.

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

Точка невозврата в этой схеме ровно одна — смена MX. До неё откат тривиален: если что-то пошло не так, мы просто продолжаем жить на Яндексе, ничего не сломав. После смены MX новая почта идёт уже на Mailu, а Яндекс мы держим ещё какое-то время для «хвоста» — писем, которые долетят на старый адрес по инерции. План отката прописан на каждом этапе: пока MX на Яндексе — откат мгновенный, после смены MX — возврат MX обратно в течение TTL.

imapsync: рабочая лошадка переноса

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

Запуск в отдельном контейнере

Чтобы не засорять сервер зависимостями Perl, мы гоняем imapsync в отдельном docker-контейнере — запустил, отработал, удалил. Чисто и повторяемо.

Синтаксис для Яндекса — и главный подводный камень

Исходный сервер — imap.yandex.ru порт 993 по SSL. И вот ключевой момент, на котором спотыкаются все: Яндекс не пускает imapsync по основному паролю пользователя. Нужен пароль приложения. Для каждого ящика в настройках Яндекс ID генерируется отдельный пароль приложения, а в настройках почты предварительно должны быть включены поддержка IMAP и опция доступа по паролям приложений. Без этого вы будете получать ошибку авторизации и гадать, что не так. Базовая команда выглядит так:

imapsync \
  --host1 imap.yandex.ru --port1 993 --ssl1 \
  --user1 "ivanov@company.ru" --password1 "ПАРОЛЬ_ПРИЛОЖЕНИЯ_ЯНДЕКС" \
  --host2 mail.company.ru --port2 993 --ssl2 \
  --user2 "ivanov@company.ru" --password2 "ПАРОЛЬ_В_MAILU"

Батч-скрипт на весь список ящиков

Двадцать восемь раз руками вводить команду — не наш метод. Мы держим список ящиков и паролей в CSV и прогоняем по нему простой скрипт, который вызывает imapsync для каждой строки. Один запуск — весь парк ящиков переносится по очереди.

Повторные прогоны без дублей

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

Заводим ящики в Mailu пачкой

Прежде чем что-то переносить, ящики надо создать в Mailu. Кликать 28 раз в админке — снова не наш метод. Mailu даёт два способа автоматизации: CLI и REST API админ-панели.

Через CLI ящик создаётся одной командой в контейнере admin:

docker compose exec admin flask mailu user ivanov company.ru 'СтойкийПароль'

Мы оборачиваем это в цикл по тому же CSV, из которого потом кормим imapsync, — один источник данных на весь проект. Для более сложных сценариев (заведение с квотами, алиасами) удобнее REST API админки, но для типового переезда хватает CLI.

День X: переключение MX и первые 48 часов

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

1. Заранее снижаем TTL записи MX. За сутки-двое до переключения ставим на MX короткий TTL (например, 300 секунд), чтобы смена разошлась по миру быстро, а не «висела» сутки на старом значении.
2. Меняем MX вечером пятницы. Классика: минимальный поток почты на выходных даёт запас времени на разбор возможных проблем без давления рабочего дня.
3. Финальный прогон imapsync. Сразу после смены MX добираем «хвост» — письма, упавшие на Яндекс перед самым переключением.
4. Мониторим очередь и логи. Смотрим mailqueue и логи Postfix: уходит ли исходящая, принимается ли входящая, нет ли отбоев.

Что происходит в первые двое суток: часть внешних серверов ещё какое-то время шлёт почту на старый MX, пока у них не обновится кеш DNS. Именно поэтому Яндекс мы не отключаем сразу — он ещё несколько дней ловит отставшие письма, а мы периодически догоняем их финальными прогонами imapsync. Через двое-трое суток поток на старый сервер иссякает, и можно спокойно расставаться с подпиской.

Перенастройка клиентских программ и устройств

Сервер переключён — теперь надо переключить всё, что этой почтой пользуется. И это не только Outlook сотрудников. Разберу по категориям — от рабочих станций до сканеров, 1С и СБИС.

Outlook и Thunderbird

Меняем адреса серверов IMAP и SMTP на единый mail.company.ru (порты 993 и 465/587). Приятно, что сервер один и тот же для приёма и отправки — сотруднику проще запомнить. Старую учётку Яндекса не удаляем сразу, а оставляем в режиме чтения на время параллельного периода.

Смартфоны сотрудников

Настраиваем почту по IMAP/SMTP. ActiveSync-профиля, как в Яндексе, здесь не будет — это осознанное ограничение Mailu, о котором мы предупреждаем заранее; на практике для почты на телефоне разницы почти нет.

Сканеры и МФУ

Часто забываемая категория. Офисные МФУ шлют отсканированные документы «на почту» по SMTP — и после переезда молча перестают это делать. Перенастраиваем на них SMTP-сервер и учётные данные. Обязательно тестируем реальным сканированием.

1С, СБИС и другие системы

1С рассылает документы и уведомления, СБИС шлёт оповещения — всё через SMTP. Для таких интеграций мы заводим отдельный служебный ящик (например robot@company.ru) с ограниченными правами и прописываем его в настройках отправки этих систем. Служебный ящик отделён от человеческого: если понадобится сменить пароль или упрутся лимиты, это не заденет живую переписку сотрудников.

Что теряем при отъезде из Яндекс 360

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

• Совместные документы и таблицы. Онлайн-редактирование в облаке Mailu не заменяет. Обычно мы ставим клиенту отдельный self-hosted сервис вроде Nextcloud с офисным модулем — и он же закрывает следующий пункт.
• Файловый диск. Большого облачного хранилища у почтового сервера нет и не должно быть. Отдельный Nextcloud или сетевое хранилище решают задачу и заодно оставляют файлы под контролем компании в РФ.
• Видеовстречи и мессенджер. Встроенных видеозвонков в Mailu нет. Здесь клиенты обычно уже пользуются сторонним решением, и почтовый переезд на это никак не влияет.

Почему клиента это не остановило? Потому что реально из всего пакета Яндекс 360 компания активно использовала только почту, а совместные документы и диск — эпизодически. Мы честно разложили это по полкам до старта: за что вы платите каждый месяц и чем на самом деле пользуетесь. После такого разбора решение о переезде стало очевидным.

Итоги через три месяца

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

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

Итог по деньгам простой: разовое внедрение окупилось за несколько месяцев экономии на подписке, а дальше компания платит только за скромный VPS и наше сопровождение. При этом вся переписка теперь лежит на подконтрольном сервере в РФ, и никакое изменение тарифов облачного провайдера компании больше не грозит.

Это третья статья серии про Mailu — после обзора системы и пошаговой установки. Если вы задумались об уходе из облачной почты, но не хотите разбираться в imapsync, MX и служебных ящиках сами — мы в ITfresh перевозим компании на свою почту под ключ, с параллельным периодом и без потери писем. Напишите мне в Telegram @ITfresh_Boss или позвоните +7 903 729-62-41 — посчитаем вашу экономику и составим план переезда.