Переход с Gmail на свой почтовый сервер: честный разбор

MAATRIX

Идея уйти с Google Workspace на свой почтовый сервер обычно приходит из двух мест: раздражения от растущего счёта за ящики и страха, что аккаунт компании однажды заблокируют без внятного объяснения. Обе причины реальны. Но статьи в интернете на эту тему почти всегда пишут с одной стороны — либо «Google — зло, переходите немедленно», либо «сами вы никогда не справитесь». Здесь — попытка взвесить обе чаши весов без продажи в одну сторону: что вы получаете и что теряете на самом деле, без сглаживания углов.

Что вы реально получаете, уходя с Gmail

Первое и главное — полный контроль над данными. На своём сервере никто, кроме вас, не может заблокировать почтовый ящик компании за нарушение непрозрачных правил, не может ограничить доступ по решению, которое вы не можете оспорить, и не может изменить условия использования так, что вчерашняя функциональность вдруг станет платной опцией. Это не гипотетический риск: у корпоративных аккаунтов Google (и любого другого стороннего провайдера) блокировка по срабатыванию автоматических систем безопасности — задокументированный сценарий, и апелляция может занимать дни, а для бизнеса, где вся коммуникация идёт через почту, день простоя — это реальные потери.

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

Третье — отсутствие искусственных ограничений Google на объём и функциональность. Лимиты на размер вложений, квоты на отправку писем в сутки, ограничения API для интеграций — на своём сервере вы настраиваете эти параметры сами под реальные нужды бизнеса, а не под тарифный план.

Дальше — то, что почти никогда не пишут честно, но что определяет, будет ли переход успехом или головной болью.

Репутация IP-адреса — самая дорогая цена перехода

Это первое и самое недооцениваемое, что вы теряете. У Google — многолетняя репутация отправителя, построенная на миллиардах писем, которую крупнейшие почтовые системы мира (сами же Gmail, Mail.ru, Yandex, корпоративные фильтры на Exchange) знают и которой доверяют по умолчанию. Письмо, отправленное с серверов Google, стартует с огромным кредитом доверия.

Ваш новый VPS с IP-адресом, который вчера принадлежал неизвестно кому (а часто — предыдущему арендатору с совершенно другой историей использования), не имеет этой репутации вообще. Ноль. Для почтовых систем получателей это неизвестный отправитель, и по умолчанию неизвестное — это подозрительное. Первые недели после переключения даже идеально настроенный сервер будет попадать в спам чаще, чем должен бы по существу отправляемых писем — просто потому что адрес новый.

Это не решается настройкой, это решается временем — так называемым разогревом IP (IP warm-up):

Неделя 1: минимальный объём, не более 30-50 писем в сутки на новый IP
Неделя 2: постепенное увеличение, ориентируясь на отсутствие жалоб и попаданий в спам
Неделя 3-4: наращивание до целевого объёма, если метрики стабильны

Это ориентировочная схема, а не гарантированный график — у вас может уйти меньше или больше времени в зависимости от объёма писем, репутации самого IP-блока провайдера и того, насколько агрессивно вы масштабируете отправку. Резкий скачок объёма писем с нового адреса — сам по себе триггер для спам-фильтров, независимо от содержания писем.

Проверять репутацию IP в процессе разогрева нужно постоянно — через открытые чёрные списки (DNSBL-проверки) и через Google Postmaster Tools, если значимая доля переписки идёт с получателями на Gmail. Честно: даже спустя месяц-два репутация нового IP не сравняется с репутацией серверов Google — она станет приемлемой для нормальной доставляемости, но не станет идентичной.

Спам-фильтрация: ваш SpamAssassin против машинного обучения Google

Второй пункт, который нужно проговорить без прикрас: спам-фильтр Gmail — это система, обученная на данных миллиардов писем за годы работы, с постоянно обновляемыми моделями машинного обучения, которые распознают новые виды спама и фишинга почти в реальном времени. Она встроена, бесплатна и не требует от вас ни единой настройки.

Самостоятельно настроенный аналог — обычно SpamAssassin, часто в связке с Rspamd в готовых сборках вроде Mailcow — объективно слабее из коробки. Не потому что это плохой софт (это хороший, зрелый и рабочий софт), а потому что у него нет и не может быть той же обучающей выборки и той же вычислительной мощности, что у Google. Базовая конфигурация ловит очевидный спам, но:

• требует ручной настройки правил под специфику вашей входящей почты;
• нуждается в периодическом дообучении на реальных ложных срабатываниях (байесовский фильтр учится на письмах, которые вы вручную пометили как спам или не спам);
• первое время будет пропускать часть спама, который Gmail отсеивал бы автоматически, и одновременно может ошибочно помечать легитимные письма — обе ошибки требуют вашего внимания, а не решаются один раз и навсегда.

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

Интеграции и удобство, которые вы теряете

Здесь честность требует признать: экосистема Google вокруг Gmail — это не только почта. Календарь с автоматическим приглашением участников и проверкой занятости, совместное редактирование документов без пересылки файлов туда-обратно, мобильные приложения, которые синхронизируются между устройствами без дополнительной настройки, поиск по письмам, который просто работает быстро на любом объёме архива.

Голый почтовый сервер (Postfix + Dovecot, или готовая сборка вроде iRedMail или Mailcow) даёт вам почту — приём, отправку, IMAP/POP3-доступ, вебмейл через Roundcube. Он не даёт вам аналог Google Calendar с той же глубиной интеграции, не даёт совместного редактирования документов, не даёт единого мобильного приложения, которое «просто работает» на iOS и Android с той же отладкой, что прошли приложения Google за полтора десятилетия.

Существуют self-hosted альтернативы — Nextcloud с его модулями календаря и совместных документов, отдельные CalDAV/CardDAV-серверы, самостоятельно поднятые инструменты для совместной работы. Это рабочие решения, но это отдельная большая тема настройки, поддержки и обучения сотрудников — и она не входит в «просто поднять почтовый сервер». Если ваша команда активно использует Google Docs для совместной работы над документами и Google Calendar для планирования встреч между отделами, переход одной только почты оставит эти инструменты без замены, и вам придётся либо продолжать платить за Google Workspace ради них (потеряв часть экономии, ради которой затевался переход), либо отдельно решать эту задачу.

Поддержка и безопасность — теперь это ваша работа

У Google — огромная команда безопасности, которая круглосуточно отслеживает угрозы, закрывает уязвимости, реагирует на новые виды атак и делает это для миллионов пользователей одновременно, включая вас, пока вы на их инфраструктуре. Вы этого почти не замечаете именно потому, что это работает без вашего участия.

На своём сервере эта ответственность полностью переходит к вам или к вашему администратору:

• регулярные обновления безопасности операционной системы и почтового ПО (Postfix, Dovecot, компоненты Mailcow или iRedMail) — пропущенное обновление с известной уязвимостью может превратить ваш сервер в открытую дверь для рассылки спама через ваш же домен;
• мониторинг очереди писем — застрявшие в очереди письма, попытки перебора паролей на SMTP/IMAP, аномальный рост исходящего трафика (частый признак взлома одного из ящиков);
• реакция на инциденты — если ваш IP попал в чёрный список, если один из сотрудников стал жертвой фишинга и его ящик используется для рассылки спама, разбираться и чинить это придётся вам, а не команде поддержки Google;
• резервное копирование почты — на своём сервере это ваша ответственность целиком, без автоматического резервирования уровня датацентров Google.

Это не аргумент «не переходите» — это аргумент «посчитайте, кто именно будет этим заниматься». Если у вас нет администратора, который готов выделять на это несколько часов в месяц в спокойном режиме и куда больше в моменты инцидентов, эта работа либо не будет делаться (и тогда сервер постепенно станет более уязвимым и менее надёжным), либо придётся регулярно платить подрядчику — и тогда экономия от отказа от Google Workspace частично или полностью компенсируется этими расходами.

Экономика и риски: как считать честно

Свести всё вышеперечисленное к одному решению помогает простой вопрос: что из перечисленных потерь для вас критично, а что — терпимо?

Экономика перехода реально считается не сравнением «подписка против аренды VPS», а полным расчётом с учётом единоразовых затрат на миграцию (перенос ящиков, настройка DNS, окно риска при переключении MX) и текущих трудозатрат на поддержку. Подробная методика такого расчёта, включая формулу срока окупаемости, — в статье про окупаемость перехода на свой почтовый сервер. Здесь же — если решаете технически, с чего начинать настройку самого сервера, обязательный шаг — корректная настройка SPF, DKIM и DMARC записей, без которых ни о какой доставляемости речи не идёт вообще: как это сделать правильно, разобрано в статье про настройку SPF, DKIM и DMARC.

Честный практический вывод

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

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

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