Перенос почты на mailcow с Яндекс 360: свой сервер, письма, календари и DNS без потерь

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

Почему именно свой сервер, а не другое облако

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

Свой сервер на mailcow работает иначе. Копии ящиков делаются по вашему расписанию, журналы доставки доступны вашему администратору, а при сбое вы сами решаете, поднимать ли резервную машину. Это не магия и не бесплатная надёжность — это контроль. Его цена — регламент обслуживания, о котором ниже.

Своя почта — это не сложно, это решительно

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

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

Что такое mailcow и из чего он состоит

mailcow-dockerized — набор контейнеров Docker, в котором собраны всё, что нужно для корпоративной почты. Postfix принимает и отправляет письма, Dovecot хранит ящики и отдаёт их по IMAP и POP3, Rspamd фильтрует спам и подписывает письма DKIM, ClamAV проверяет вложения, SOGo даёт веб-почту, календари и адресные книги по CalDAV и CardDAV. Управление — через веб-интерфейс администратора: домены, ящики, псевдонимы, квоты, ключи DKIM.

Сборка обновляется скриптом update.sh, а резервные копии делает штатный helper-скрипт. Подробный разбор установки — в статье «Установка mailcow пошагово»; здесь мы сосредоточимся на переезде с Яндекс 360.

Требования к серверу

Для mailcow нужен отдельный сервер или виртуальная машина с Linux, где не работают другие веб-сервисы на портах 80 и 443. Документация mailcow называет минимум 6 ГБ оперативной памяти и 1 ГБ подкачки — большую часть памяти занимает ClamAV — и не меньше 20 ГБ на диске под систему. Ящики считаются отдельно: возьмите текущий объём почты в Яндекс 360 и добавьте запас на два-три года роста.

Сервер должен иметь постоянный внешний IP-адрес с обратной записью PTR на имя почтового сервера, например mail.company.ru. Без PTR многие получатели будут отклонять или помечать ваши письма как спам. Порт 25 на исходящие соединения должен быть открыт провайдером: у части облачных площадок он закрыт по умолчанию и открывается по заявке.

• Linux x86_64, Docker и плагин docker compose
• от 6 ГБ памяти и 1 ГБ подкачки
• диск: система 20 ГБ + объём ящиков с запасом
• постоянный IP с PTR на имя сервера
• открытые порты 25, 465, 587, 143, 993, 110, 995, 4190, 80, 443
• отдельная площадка или хотя бы отдельный диск для резервных копий

Где разместить сервер

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

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

Установка mailcow

На подготовленном сервере установите Docker и плагин compose, затем скачайте mailcow и сгенерируйте конфигурацию. Скрипт generate_config.sh спросит имя сервера — указывайте полное имя, например mail.company.ru, и часовой пояс. Затем образы скачиваются и контейнеры запускаются.

cd /opt
git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
./generate_config.sh
docker compose pull
docker compose up -d

После запуска откройте https://mail.company.ru/admin, войдите учётной записью admin с паролем из документации и сразу смените пароль. Включите двухфакторную аутентификацию для администратора: учётная запись администратора почты — первая цель любого взлома.

Домен и ящики: повторите структуру Яндекс 360

В разделе «Почтовые настройки» добавьте домен компании и задайте квоту домена. Затем создайте ящики с теми же адресами, что в Яндекс 360. Удобно выгрузить список сотрудников из панели администратора Яндекс 360 и создать ящики пакетно через API mailcow — для десятков адресов это быстрее, чем вручную.

Не забудьте псевдонимы и рассылки. В Яндекс 360 у сотрудника могут быть дополнительные адреса, а у отдела — общая рассылка. В mailcow псевдонимы создаются отдельно и могут указывать на один или несколько ящиков. Общие ящики вроде info@ и buh@ делаются обычными ящиками с делегированием доступа: сотрудники открывают их из своей веб-почты или почтовой программы.

• список ящиков с квотами
• дополнительные адреса каждого сотрудника
• рассылки отделов и их участники
• общие ящики и кому нужен доступ
• правила пересылки, которые нужно повторить

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

Чтобы забрать письма по IMAP, в Яндекс 360 должны быть разрешены почтовые программы, а у каждого ящика включён доступ по IMAP. Для подключения нужен пароль приложения: он показывается один раз и начинает действовать не сразу, поэтому создавайте пароли накануне переноса. Подробный порядок — в статье «Подготовка Яндекс 360 к выгрузке почты».

Параметры подключения из справки Яндекса: сервер imap.yandex.ru, порт 993, SSL, логин — полный адрес ящика. Пароли приложений храните в файлах с правами только для владельца и удаляйте после переезда.

Способ 1: перенос писем через imapsync

imapsync копирует письма между двумя IMAP-серверами с сохранением папок, дат и флагов «прочитано», «отмечено», «отвечено». Мы запускаем его в контейнере Docker на любом Linux-сервере — хоть на самом сервере mailcow. Пароли передаются через файлы, поэтому не видны в списке процессов.

docker run --rm -v "$PWD":/var/tmp gilleslamiral/imapsync imapsync \
  --host1 imap.yandex.ru --ssl1 --user1 anna@company.ru --passfile1 /var/tmp/pass_yandex \
  --host2 mail.company.ru --ssl2 --user2 anna@company.ru --passfile2 /var/tmp/pass_new \
  --automap

Опция --automap сопоставляет системные папки: русские «Отправленные» и «Черновики» попадают в Sent и Drafts на mailcow, и почтовые программы видят их как свои. На нашем стенде первый перенос ящика из 755 писем в 11 папках занял 11 секунд без ошибок, а повторный запуск не создал ни одного дубля — imapsync пропускает уже перенесённые письма.

Подробно все опции, обработка ошибок и перенос десятков ящиков разобраны в статье «Перенос почты через imapsync».

Способ 2: задания синхронизации в интерфейсе mailcow

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

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

Контакты и календари

imapsync переносит только письма. Контакты и календари в mailcow живут в SOGo и доступны по CardDAV и CalDAV. Из Яндекс 360 их выгружают файлами: адресную книгу — в формате vCard или CSV, календари — в формате iCalendar. Затем файлы импортируются в SOGo через веб-интерфейс каждого пользователя или администратором.

После импорта подключите календари на телефонах и в почтовых программах. На iPhone и macOS удобно использовать профиль автонастройки, на Android — приложение с поддержкой CalDAV и CardDAV. Старые аккаунты Яндекса на устройствах удалите, иначе события и контакты задвоятся.

DNS: MX, SPF, DKIM, DMARC и автонастройка

За сутки-двое до переключения снизьте TTL записей MX и SPF до 300–600 секунд. Сгенерируйте ключ DKIM в mailcow — раздел «Конфигурация», ключи ARC/DKIM, длина 2048 бит — и опубликуйте его в DNS заранее: лишняя запись DKIM ничему не мешает. В день переключения смените MX на свой сервер и SPF на разрешение вашего IP.

company.ru.               MX     10 mail.company.ru.
mail.company.ru.         A      203.0.113.10
autodiscover.company.ru. CNAME  mail.company.ru.
autoconfig.company.ru.   CNAME  mail.company.ru.
company.ru.              TXT    "v=spf1 mx -all"
dkim._domainkey.company.ru. TXT "v=DKIM1; k=rsa; p=…"
_dmarc.company.ru.       TXT    "v=DMARC1; p=none; rua=mailto:dmarc@company.ru"

Записи autodiscover и autoconfig позволяют Outlook, Thunderbird и почте на iPhone настраиваться по адресу и паролю. DMARC начинайте с p=none и отчётов на отдельный адрес, через несколько недель без ошибок переводите на quarantine. Подробно — в статье о записях MX, SPF, DKIM и DMARC при смене провайдера.

День переключения

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

docker run --rm -v "$PWD":/var/tmp gilleslamiral/imapsync imapsync \
  --host1 imap.yandex.ru --ssl1 --user1 anna@company.ru --passfile1 /var/tmp/pass_yandex \
  --host2 mail.company.ru --ssl2 --user2 anna@company.ru --passfile2 /var/tmp/pass_new \
  --automap --maxage 2

Опция --maxage 2 переносит только письма за последние двое суток, поэтому проход занимает секунды. На стенде дозаливка пяти новых писем перед переключением прошла за 4 секунды без ошибок.

Устройства, программы и всё, что отправляет почту

Переезд не заканчивается на сервере. Каждый телефон, каждая почтовая программа, 1С, МФУ со сканированием в почту, форма обратной связи на сайте, CRM, системы мониторинга — всё это отправляло письма через серверы Яндекса. Составьте список заранее и перенастройте по нему: SMTP-сервер mail.company.ru, порт 587 с STARTTLS или 465 с SSL, логин — полный адрес.

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

Проверка после переезда

Сверьте число писем и объём по каждой папке на обеих сторонах. imapsync с опцией --justfoldersizes показывает размеры без переноса — на стенде числа писем и байт совпали по всем папкам. Отправьте письма на внешние ящики и проверьте заголовки: должны быть spf=pass, dkim=pass, dmarc=pass. Проверьте IP сервера по основным чёрным спискам.

• число писем и объём по папкам совпадают
• флаги «прочитано» и «отмечено» на месте
• входящие приходят на mailcow, MX указывает на новый сервер
• исходящие проходят SPF, DKIM и DMARC
• календари и контакты видны на телефонах
• 1С, МФУ и сайт отправляют через новый сервер
• резервная копия ящиков уже сделана на другой площадке

Регламент: что делать после переезда

Свой сервер требует ухода. Раз в неделю — проверка обновлений mailcow и их установка через update.sh после резервной копии. Каждый день — резервная копия ящиков и конфигурации на другую площадку. Раз в месяц — проверка восстановления: копия, которую ни разу не восстанавливали, не считается копией. Постоянно — мониторинг очереди Postfix, места на диске, срока сертификата и чёрных списков.

Если в компании нет администратора, этот регламент берём на себя мы. Пример реальной работы — кейс бухгалтерской фирмы на mailcow.

Старые ящики Яндекс 360: не удаляйте сразу

Оставьте ящики в Яндекс 360 на две-четыре недели. В это время на них могут приходить письма от серверов с устаревшим кэшем DNS, а сотрудники могут вспомнить про письмо, которое лежало в нестандартной папке. Задания синхронизации или ежедневный проход imapsync продолжают забирать всё новое.

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

Типичные ошибки переезда на mailcow

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

• нет PTR-записи — письма уходят в спам у крупных получателей
• порт 25 закрыт провайдером площадки — исходящие висят в очереди
• DKIM опубликован с ошибкой в имени селектора — dkim=fail
• не перенесены псевдонимы — письма на старые адреса возвращаются отправителям
• забыли МФУ и 1С — сканы и счета перестали отправляться
• копия лежит на том же сервере — авария забирает и почту, и копию
• старые ящики удалили в день переключения — часть писем потеряна

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