Переезд корпоративной почты на свой сервер: как не потерять письма и не улететь в спam
Три раза в этом году ко мне приходили клиенты с одной и той же фразой: «Гугл заблокировал оплату, срочно нужна почта». Один раз это была бухгалтерская фирма на 18 человек, другой — юристы, третий — небольшое производство под Домодедово. Каждый раз я видел одну и ту же ошибку: люди думают, что переезд почты — это поменять MX-запись и всё заработает. Расскажу, как это делать так, чтобы письма не терялись, а домен не попал в чёрные списки на второй день.
Почему вообще переезжают, если и так работает
Обычно повод не «хочу», а «пришлось». Google Workspace отключил оплату картой из России ещё в 2022-м, платить приходится через прокладки и курс с накруткой 8-12%. Яндекс 360 для бизнеса дешевле, но там своя головная боль — служба поддержки отвечает по трое суток, а миграция крупных ящиков (больше 15 ГБ) иногда просто зависает без объяснений.
У одного моего клиента, юридической конторы на 22 сотрудника, ящик директора весил 41 ГБ — переписка за 9 лет, договоры, сканы. Яндекс перенос завис на 60% и там и остался. Пришлось руками через IMAP выгружать.
Есть и вторая причина, помимо денег и капризов провайдера — контроль. Если почта на 1С-Битрикс24 или в облаке иностранного вендора, вы не знаете точно, где физически лежат ваши договоры и переписка с налоговой. Для юрфирм и бухгалтерии это не паранойя, а требование клиентов — некоторые прямо в договоре просят подтверждение, что данные хранятся на территории РФ.
Аудит перед стартом — не пропускайте этот шаг
Первое, что я делаю перед любой миграцией почты — выгружаю полный список того, что реально нужно перенести. Не «всю почту», а конкретно: сколько ящиков, средний объём каждого, есть ли общие папки, календари, контакты, алиасы, рассылки типа info@ и bухгалтерия@.
Отдельно смотрю текущие DNS-записи домена: SPF, DKIM, DMARC, TTL у MX. Если TTL стоит 86400 секунд (сутки), его нужно снизить до 300 заранее, минимум за два-три дня до переключения — иначе при смене MX часть почтовых серверов будет ещё сутки слать письма по старому адресу, и вы их просто не увидите.
Ещё один момент, который все забывают — SPF-запись старого провайдера. Если в ней прописан Google (include:_spf.google.com) и вы просто замените MX, но не почистите SPF, письма от вашего домена, отправленные через новый сервер, начнут попадать в спам у получателей с строгой DMARC-политикой. Проверял это на собственном опыте с mail24x7.net — забыл почистить старый include, и половина писем клиентам ушла в карантин Mail.ru.
Что выбрать: mailcow, Zimbra или готовое решение
Для компаний до 50 рабочих мест я почти всегда советую mailcow-dockerized — это Postfix плюс Dovecot плюс Rspamd, всё в Docker-контейнерах, с удобной админкой и встроенным SOGo для веб-почты и календарей. Поднимается на сервере с 4 ядрами и 8 ГБ оперативки без проблем, обновляется одной командой.
Zimbra в 2026 году я уже не рекомендую новым клиентам — компания практически заморозила бесплатную версию, а лицензии на коммерческую кусаются. У меня был сервер на Zimbra, который в итоге пришлось полностью переносить на mailcow — сама миграция заняла три недели именно из-за архитектурных различий в хранении писем.
Если бюджет позволяет и в компании уже есть 1С и Windows-инфраструктура, вариант с Exchange тоже рабочий, но дороже по лицензиям и требовательнее к железу. Для бухгалтерии и юрфирм с типовыми задачами — почта, календарь, общие папки — mailcow закрывает 95% потребностей бесплатно.
Прогрев домена и репутация — здесь ошибаются чаще всего
Самая частая причина, по которой свежемигрированная почта улетает в спам — новый IP-адрес сервера не имеет истории. Почтовые фильтры Mail.ru, Gmail, Yandex смотрят не только на контент письма, но и на репутацию отправляющего IP. У нового сервера её попросту нет, и первые письма легко попадают в карантин.
Поэтому за неделю до переключения я настраиваю обратную DNS-запись (PTR) на новом сервере — она должна совпадать с именем сервера, который представляется в HELO. Затем настраиваю SPF с точным списком разрешённых серверов, DKIM-подпись с ключом минимум 2048 бит, и DMARC для начала в режиме p=none, чтобы просто собирать отчёты и видеть, кто и как подделывает или не проходит проверку по вашему домену.
Дальше — прогрев. Первые три-четыре дня после переключения не отправляю через новый сервер массовые рассылки и письма незнакомым адресатам, только обычную рабочую переписку с постоянными контрагентами. Объём писем в день наращиваю постепенно: 50, потом 150, потом 400, и так далее. У клиента-производителя мы за 12 дней вышли на обычный объём в 900 писем в сутки без единой жалобы на спам.
Перенос самих ящиков без потери писем
Технически перенос писем делается через imapsync — утилита, которая копирует содержимое ящиков по протоколу IMAP с одного сервера на другой, папка за папкой, с сохранением дат и флагов прочитанности. Важно: она именно копирует, а не переносит, старые ящики остаются нетронутыми, пока вы сами их не отключите.
Первый прогон imapsync запускаю за несколько дней до переключения MX — переносится основной объём, это может занять от пары часов до суток на большой объём. Затем, буквально перед сменой MX, делаю второй короткий прогон — он докачивает только то, что накопилось с момента первой синхронизации.
Для компании из 22 юристов с теми самыми 41 ГБ у директора весь перенос всех ящиков занял двое суток фоновой работы сервера, при этом почта у людей продолжала работать в старом сервисе без перерыва. Никто из сотрудников даже не заметил, что где-то что-то копируется.
Само переключение MX — окно тишины и двойной приём
День икс. MX-запись меняется на новый сервер, TTL уже снижен заранее, так что распространение по миру занимает от 15 минут до пары часов, а не сутки. Но письма, отправленные людьми, у которых DNS ещё не обновился, продолжают идти на старый сервер ещё какое-то время — иногда до 24-48 часов, это нормально.
Чтобы не потерять эти письма, старый почтовый ящик я не отключаю сразу. Он продолжает принимать входящую почту ещё три-пять дней, а новый сервер параллельно её забирает через fetchmail или повторный imapsync раз в несколько часов. Это и называется двойной приём — избыточно, зато ни одно письмо не теряется в переходный период.
На практике я обычно назначаю переключение на вечер пятницы или на выходные — меньше активной переписки, есть время спокойно проверить логи и убедиться, что почта реально доходит, прежде чем в понедельник утром 20 человек начнут работать.
Первая неделя после переезда — не расслабляться
Сразу после переключения проверяю домен в основных чёрных списках — Spamhaus, Barracuda, SORBS. Делается это за пару минут через любой mxtoolbox-подобный сервис. Если IP сервера раньше кому-то принадлежал и использовался для спама, он вполне может оказаться в списке ещё с прошлой жизни — тогда нужно сразу подавать заявку на исключение, это может занять от часа до нескольких дней.
Первые дни смотрю логи Rspamd и Postfix буквально каждое утро — сколько писем ушло, сколько отклонено, нет ли жалоб от получателей на «письмо не доставлено». У одного клиента на третий день обнаружили, что письма в адрес одного крупного банка-контрагента заворачивались из-за слишком строгой DMARC-политики банка — пришлось донастраивать выравнивание SPF и DKIM именно под их фильтр.
И да, обязательно предупредите бухгалтера и всех, кто переписывается с ФНС и банками, о дате переезда. Пусть в эти дни на всякий случай дублируют важные письма и проверяют, что ответы реально доходят — паранойя тут дешевле, чем пропущенное требование налоговой.
Частые вопросы
Сколько времени занимает вся миграция почты на свой сервер?
Для компании на 20-30 ящиков закладываю обычно две-три недели: неделя на аудит и подготовку DNS, несколько дней на перенос писем, ещё неделя на прогрев домена и наблюдение после переключения. Можно быстрее, но я не советую торопиться именно с прогревом репутации.
Будет ли простой в работе почты во время переезда?
При правильной подготовке — нет. Пока идёт перенос писем, сотрудники продолжают пользоваться старыми ящиками как обычно. Само переключение MX проходит незаметно для пользователей, если заранее снижен TTL и настроен двойной приём почты на переходный период.
Что будет со старыми письмами в Gmail или Яндекс 360 после переезда?
Они никуда не исчезают — старый ящик просто перестаёт быть основным, но остаётся доступен ещё несколько недель или месяцев, пока вы не решите его закрыть. Я обычно советую держать старый аккаунт активным минимум месяц, на всякий случай.
Как понять, что новый почтовый сервер не попадёт в спам?
Проверяйте домен в чёрных списках сразу после переключения, следите за отчётами DMARC и постепенно наращивайте объём отправки в первые дни. Если через неделю-две письма стабильно доходят до Gmail, Mail.ru и Яндекса без карантина — репутация домена в порядке.
Проведём аудит, настроим DKIM и DMARC, прогреем домен и перенесём все ящики — вы просто продолжите работать как ни в чём не бывало.
Бесплатная консультация →
Подпишитесь на рассылку ITfresh
Раз в неделю — практические гайды для руководителя и сисадмина: безопасность, 1С, миграции, резервные копии, лайфхаки из реальных проектов.
