Перенос корпоративной почты на российский сервер: как переехать без потерь

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

Почему бизнес уходит с зарубежных платформ

2022 год ударил по многим одинаково. Привычный Google Workspace или Microsoft 365 вдруг превратился в источник головной боли. Карты не принимают. Биллинг завис. Аккаунт заблокирован без предупреждения и без объяснений. У одного нашего клиента — транспортная компания, 35 рабочих мест в Подмосковье — однажды утром просто не открылась корпоративная почта. Восемь часов они работали на личных телефонах. Восемь часов потерянных переговоров. Это не абстрактный риск — это конкретные деньги и нервы.

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

Есть и чисто финансовая сторона вопроса. Google Workspace Business Starter через посредников обходился в 800–900 рублей на пользователя в месяц. На 30 пользователей — 25 000 рублей ежемесячно, 300 000 в год. Российские альтернативы — Яндекс 360 для бизнеса или собственный сервер на Mailcow — выходят принципиально дешевле. Особенно если VPS у вас уже есть под другие задачи.

Что собрать и проверить до начала работ

Прежде чем что-то переносить, нужно чётко понять — что именно. Звучит банально, но именно здесь возникает половина проблем при миграции. Я всегда начинаю с инвентаризации: список всех почтовых ящиков с объёмом данных в каждом. Объём — критичный параметр. Ящик на 50 ГБ будет переноситься через imapsync несколько часов, и это нужно закладывать в планирование окна технических работ заранее.

Следующий шаг — текущие DNS-записи домена. Их нужно зафиксировать до начала любых работ. Я делаю так: запускаю dig @8.8.8.8 yourdomain.ru MX и dig @8.8.8.8 yourdomain.ru TXT, сохраняю вывод в текстовый файл. Там будут MX-записи — куда сейчас идёт почта, SPF-запись — с каких IP разрешена отправка, иногда DKIM и DMARC. Всё это придётся воссоздать на новом сервере. Этот файл не теряйте.

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

Настройка нового сервера: всё до переключения DNS

Новый сервер должен быть полностью готов до того, как вы тронете DNS. Это принципиально. На нашей практике мы работаем преимущественно с Mailcow — Docker-based решение на базе Postfix и Dovecot с удобной веб-панелью. Разворачивается на VPS или выделенном сервере. Под 30 ящиков достаточно VPS с 4 ядрами, 8 ГБ RAM и 100 ГБ диска — у российских хостеров типа Selectel или Timeweb это обойдётся в 2500–4000 рублей в месяц. При наличии опыта настройка занимает час-два.

SSL-сертификат — обязателен. Mailcow умеет получать его через Let's Encrypt автоматически, но только если DNS поддомена mail.yourdomain.ru уже указывает на новый сервер. Не путайте: это DNS для поддомена, а не MX-запись основного домена — они меняются независимо друг от друга. Ещё один момент, который часто упускают, — PTR-запись, обратный DNS. Попросите хостера прописать её вручную. Без PTR многие почтовые серверы будут тихо отклонять ваши письма или класть в спам.

SPF, DKIM и DMARC — три записи, без которых нормальной доставки не будет. SPF сообщает другим серверам: вот список IP, которым разрешено слать письма от имени нашего домена. DKIM подписывает каждое письмо криптографической подписью. DMARC определяет, что делать, если SPF или DKIM не прошли проверку. Без этих трёх записей письма будут попадать в спам у половины получателей. Мы столкнулись с этим на практике: небольшое производство в Химках полгода жаловалось, что коммерческие предложения не доходят до адресатов. Настроили DKIM — проблема исчезла в тот же день.

DNS: самое критичное место всей миграции

TTL — Time to Live — это время в секундах, на которое DNS-серверы по всему миру кэшируют вашу запись. По умолчанию у большинства регистраторов стоит 3600 или 86400 — час или целые сутки. Что это значит на практике? После смены MX-записи весь мир ещё долго будет слать почту на старый сервер. За 24–48 часов до переезда снизьте TTL до 300 секунд. Тогда в момент переключения изменения разойдутся по миру за 5–10 минут, а не за сутки.

MX-запись — это указатель на сервер, который принимает почту для вашего домена. Выглядит примерно так: yourdomain.ru MX 10 mail.yourdomain.ru. Цифра 10 — приоритет. При переключении почты меняете эту запись на новый сервер. Совет: старую MX не удаляйте сразу — оставьте с высоким числом приоритета, например 20. Если что-то пойдёт не так в первый час, часть писем всё равно дойдёт на старый сервер. Подстраховка ценой одной строчки в DNS.

Пока меняется DNS — а при TTL 300 это занимает 5–30 минут — письма могут приходить как на старый, так и на новый сервер одновременно. Это нормально, но это нужно учитывать. Именно поэтому после переключения нужен ещё один прогон imapsync: забрать со старого сервера всё, что пришло туда за переходный период. И ещё одно правило, которое мы не нарушаем: не отключайте старый сервер немедленно. Подождите сутки, убедитесь что весь трафик идёт на новый, — и только потом отключайте.

Перенос данных: imapsync и практика трёх прогонов

imapsync — наш основной инструмент переноса почтовых ящиков. Утилита командной строки, которая одновременно подключается к двум IMAP-серверам и синхронизирует содержимое. Переносит всё: папки, письма, флаги прочитанного и непрочитанного, даты получения. Команда выглядит примерно так: imapsync --host1 mail.old.ru --user1 user@domain.ru --password1 PASS --host2 mail.new.ru --user2 user@domain.ru --password2 PASS. Для каждого ящика — отдельный запуск, но несколько можно запускать параллельно.

На нашей практике типичная миграция проходит в три этапа. Первый прогон — за 2 дня до переезда: самый долгий, переносит всё накопленное за годы. Ящик на 20 ГБ гоняется 3–4 часа. Второй прогон — за час до переключения DNS: быстрый, переносит только новое. Третий прогон — через час после переключения: забирает письма, которые за переходный период успели прийти на старый сервер. Три прогона, минимум простоя, максимум сохранности данных.

Один момент, который почти всегда упускают — это общие и ресурсные ящики. info@, sales@, buh@, office@ — они есть в каждой второй компании, но ни в каком списке «сотрудников» вы их не найдёте. Составьте для них отдельный список. Убедитесь, что на новом сервере эти адреса созданы. Перенесите их через imapsync — точно так же, как и личные ящики. В таких адресах нередко лежит многолетняя история переписки. Терять её нельзя.

Что проверить сразу после переезда

Сразу после смены DNS я отправляю тестовые письма на внешние адреса — Яндекс, Mail.ru, Gmail, прямо с телефона. И жду. Письма должны прийти быстро и не в спам. Если всё же попали в спам — открываю заголовки письма. В большинстве клиентов есть пункт «Показать оригинал» или «Показать источник». Там сразу видно, что именно сломалось: SPF не прошёл, DKIM не совпал, или сервер отправки вообще не числится в белых списках.

MXToolbox должен быть открыт всё время, пока идут технические работы. Вбиваете домен или IP — и сразу видите MX-записи, SPF, DKIM, DMARC. И главное — blacklist-статус вашего IP-адреса. Это не мелочь. IP нового сервера вполне мог побывать в чужих руках и попасть в базы спамеров от предыдущего владельца. На нашей практике такое встречалось. Решается запросом на делистинг — обычно в течение суток. Лучше проверить это до переезда, пока есть время.

Обязательный пункт, про который легко забыть — настройки почтовых клиентов на машинах сотрудников. Если адрес сервера изменился, IMAP и SMTP нужно обновить везде. На 20 компьютерах ручная настройка займёт 2–3 часа. Если машины в домене Windows Server с групповыми политиками — раскатайте всё через GPO, это быстрее. Только сначала проверьте, что Outlook нормально работает на нескольких тестовых машинах. Не на всех сразу — иначе при проблеме придётся откатываться везде.

Ошибки, которые мы видели — и которые стоили денег

Самая дорогая ошибка из тех, что мы видели — не снизить TTL заранее. Один наш клиент из торговли решил переехать быстро, без подготовки. TTL стоял на 86400 — сутки. После смены MX-записи весь мир ещё 18 часов продолжал слать почту на старый сервер. Часть писем никто не забрал — старый сервер к тому моменту уже отключили. Несколько заявок потеряли. Ущерб по одной сорванной сделке посчитали в 70 000 рублей. Пять минут на снижение TTL за несколько дней до переезда — и ничего этого бы не случилось.

Вторая по частоте ошибка — забытый DKIM после переноса. Старый сервер подписывал письма своим ключом, новый использует свой. Но DNS-запись с публичным ключом для проверки никто не обновил. Результат: письма уходят, но у получателей стабильно падают в спам. Компания несколько дней не понимает, почему клиенты молчат. Потом выясняется, что в спаме лежат пять важных писем с вопросами. Один ключ в DNS. Один раз забыть — и репутация домена проседает на недели.

Третья ошибка — не проверить PTR-запись на точное совпадение. Она должна соответствовать имени, которое сервер указывает в SMTP-приветствии, то есть EHLO-имени. Есть расхождение — крупные почтовые провайдеры могут тихо отклонять соединение. Вы не заметите это сразу. Исходящие письма просто будут теряться, и выяснится это через неделю — когда кто-то из сотрудников начнёт жаловаться, что ответ так и не пришёл.

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

Сколько времени занимает миграция корпоративной почты?
Зависит от объёма данных и количества ящиков. Подготовка и настройка нового сервера — 1–2 рабочих дня. Сам перенос данных при 10–20 ящиках стандартного объёма занимает 4–8 часов. Момент переключения DNS — 15–30 минут реального простоя. При правильной подготовке сотрудники практически не замечают переезда.

Можно ли перенести почту без потери писем?
Да, если использовать трёхэтапный прогон через imapsync и заранее снизить TTL DNS-записей. Схема простая: первый прогон за 2 дня до переезда, второй — за час до переключения, третий — через час после. Так ни одно письмо не потеряется даже в переходный период, когда DNS ещё не распространился повсеместно.

Какой почтовый сервер выбрать для российского хостинга?
Мы рекомендуем Mailcow — open source, активно развивается, удобная панель, хорошая документация. Из коммерческих российских вариантов — Яндекс 360 для бизнеса, проще в обслуживании, не требует своего сервера. Если нужна полная независимость и контроль — VPS у Selectel, Timeweb или Hosting.ru с Mailcow на борту.

Обязательно ли настраивать DKIM и DMARC при переносе?
Обязательно. Без DKIM письма будут попадать в спам у части получателей — особенно у тех, кто использует строгие фильтры. DMARC без DKIM вообще не работает по смыслу. На настройку уходит 20–30 минут, но это одна из тех вещей, где экономить время нельзя. Потеря репутации домена восстанавливается неделями.