DevOps · 25 октября 2026 г. · 7 мин чтения
Перенос корпоративной почты с Google Workspace на собственный сервер: практическое руководство
Недавно мы перенесли почту трёх доменов компаний с Google Workspace и старого сервера на один собственный почтовый сервер. Вот порядок действий, при котором все почтовые ящики продолжали работать во время переезда.
Почему компании уходят с Google Workspace
Стоимость за пользователя накапливается, данные хранятся у третьей стороны, а каждый новый домен или ящик — это ещё одна подписка. Собственный сервер может обслуживать множество доменов и сколько угодно ящиков на одной машине.
Обратная сторона — ответственность: доставляемость, безопасность, резервные копии и обновления теперь на вас. Это нормально, если кто-то за этим следит, и рискованно, если никто.
Какой стек мы использовали
Мы использовали docker-mailserver, который объединяет в одном контейнере всё необходимое для боевого почтового сервера, и Roundcube в качестве веб-почты.
- Postfix и Dovecot для отправки и почтовых ящиков
- Rspamd для фильтрации спама и DKIM-подписи
- ClamAV и Fail2ban для защиты от вирусов и брутфорс-атак
- Веб-почта Roundcube с привычным интерфейсом в стиле Gmail
- SMTP-релей для исходящей почты, поскольку многие хостинг-провайдеры блокируют порт 25
Перенесите ящики до изменения DNS
Сначала импортируйте старую почту: экспорт данных Google или синхронизацию по IMAP для Workspace и копирование на уровне файлов для старого сервера. Сохраните флаги, например «прочитано» и «помечено звёздочкой», а также структуру папок, чтобы пользователи нашли всё там, где оставили.
Если вы переносите пользователей со старого Linux-сервера, хеши паролей часто тоже можно перенести, и в день переключения никому не придётся сбрасывать пароль.
Настройте доставляемость правильно
Письма с нового почтового сервера попадают в спам, если нет аутентификации. До переключения настройте и проверьте:
- SPF со всеми серверами и релеями, которые отправляют почту от имени домена
- DKIM-ключи для каждого домена, опубликованные в DNS
- DMARC с отправкой отчётов в отдельный ящик
- Обратную DNS-запись (PTR), совпадающую с именем хоста сервера
- Реальный тест: отправьте письмо на Gmail и убедитесь, что SPF, DKIM и DMARC проходят проверку
Переключение
За день снизьте TTL в DNS. Затем направьте MX-запись (или имя почтового хоста) на новый сервер, остановите доставку на старом, чтобы отправители повторили попытку по новому адресу, и выполните финальную дельта-синхронизацию для всего, что пришло в промежутке.
Почта здесь прощает многое: отправляющий сервер, который не может подключиться, повторяет попытки несколько дней, поэтому несколько минут переключения не приводят к потере писем.
После переключения
Проверьте зависимости, о которых часто забывают: приложения, отправляющие почту через старый аккаунт, входы через «Войти с Google», записи DNS для верификации и сервисы транзакционных рассылок. Затем удалите старые записи и отмените подписку.
FAQ
- Надёжна ли почта на собственном сервере?
- Да, если её обслуживать. Современный стек, например docker-mailserver с SPF, DKIM, DMARC, фильтрацией спама, мониторингом и ежедневными резервными копиями, надёжен. Риск — в заброшенном сервере, а не в программном обеспечении.
- Не будут ли мои письма попадать в спам после переезда?
- Нет, если аутентификация настроена полностью. Опубликуйте SPF, DKIM и DMARC, настройте соответствующую обратную DNS-запись, отправляйте через надёжный релей, если ваш хостинг блокирует порт 25, и проверьте доставку на Gmail до переключения.
- Могут ли несколько доменов работать на одном почтовом сервере?
- Да. Один сервер может обслуживать множество доменов, у каждого из которых свои ящики, свой DKIM-ключ и свой адрес веб-почты.
Нужна помощь с этим?
Мы делаем это для клиентов каждую неделю. Расскажите о своём проекте.
Начать проект