Корпоративная почта после ухода вендора: свой сервер или российское облако

MAATRIX

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

Контроль над данными

Это критерий, из-за которого многие вообще начинают этот разговор — предыдущий вендор одним решением показал, что контроль был иллюзией.

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

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

Практический вывод: если требование «данные физически не покидают периметр компании» — жёсткое (юр. фирма, медицина, гособоронзаказ, финансы с повышенными требованиями комплаенса), свой сервер закрывает вопрос полностью. Если требование — «данные в РФ и с внятным договором», российское облако тоже подходит.

Трудозатраты администрирования

Здесь честность особенно важна, потому что именно на этом пункте чаще всего обжигаются компании, которые выбирают свой сервер под влиянием момента, а не расчёта.

Собственный сервер — это не разовая настройка. Классический стек Postfix + Dovecot + Rspamd/ClamAV нуждается в постоянном сопровождении: обновления пакетов и закрытие CVE, мониторинг очередей отправки, разбор жалоб на спам-фильтрацию, ротация и проверка бэкапов (именно проверка — бэкап, который никогда не разворачивали, бэкапом не является), продление TLS-сертификатов, разбор инцидентов вида «письмо не дошло, а почему — не сказали». Готовые сборки вроде iRedMail или Mailcow сильно упрощают первичную установку, но не снимают задачу постоянной эксплуатации. Ориентировочно для стабильно работающей почты на 20–50 ящиков нужен сотрудник с квалификацией линукс-админа, тратящий на это не полный рабочий день, но и не «раз в квартал заглянуть» — реальная цифра сильно зависит от того, как часто у вас меняются сотрудники, домены и внешние интеграции.

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

Репутация IP и доставляемость писем

Здесь оба пути сталкиваются с одной и той же физикой интернета, только с разных сторон.

Свежий IP-адрес — что на арендованном VPS под свой сервер, что у нового облачного тарифа — не имеет истории, и крупные почтовые системы (тот же Gmail или Outlook на стороне получателя) относятся к письмам с него настороженно, пока не увидят стабильный «чистый» объём трафика. Отсюда правило прогрева: начинать с небольшого объёма писем, постепенно наращивать, не запускать рассылку на всю базу клиентов в первый день после переезда.

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

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

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

Практический ориентир: если основная переписка компании — с российскими и СНГ-контрагентами, банками, госорганами, риск доставляемости невысокий что там, что там. Если много переписки с зарубежными партнёрами, закладывайте время на прогрев и жёсткий контроль аутентификации домена независимо от выбранного пути.

Стоимость на длинной дистанции

Здесь сравнение зависит не от того, что дешевле «в моменте», а от того, как стоимость масштабируется с ростом штата.

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

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

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

Скорость миграции

Когда доступ к прежнему сервису уже закрыт, скорость — не абстрактный критерий, а вопрос «сколько дней компания работает без нормальной почты».

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

Российское облако обычно даёт рабочий ящик в тот же день после регистрации и оплаты — учётки заводятся через панель за минуты. Но полноценная миграция всё равно занимает 1–3 дня для небольшой команды: перевод MX-записей, ожидание обновления DNS-кэшей у получателей, настройка клиентов у каждого сотрудника, перенос сохранившихся писем. Для команды побольше добавьте время на перенос групп рассылки и общих ящиков.

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

Если критично «хоть что-то рабочее сегодня» — облако быстрее почти всегда. Если у вас уже есть заранее подготовленная инфраструктура (сервер стоит, просто почта на нём не поднята) — свой вариант может оказаться не медленнее.

Какой вариант подходит вашей команде

Универсального ответа нет, но есть рабочие ориентиры по размеру команды и наличию своей IT-экспертизы.

До 10–15 ящиков, нет выделенного администратора. Российское облако почти всегда выигрывает: минимум трудозатрат, предсказуемая цена на этом масштабе, быстрое восстановление работы. Разворачивать свой почтовый сервер ради десятка ящиков экономически не оправдано — время админа на его сопровождение обойдётся дороже, чем разница в тарифах.

15–50 ящиков, уже есть штатный сисадмин или подрядчик на аутсорсе. Оба варианта жизнеспособны. Решает не размер, а требования к контролю данных: если это финансы, медицина, юридическая практика или гособоронзаказ — свой сервер оправдан несмотря на трудозатраты. Если требований по комплаенсу нет, облако проще в сопровождении на этом масштабе тоже.

50+ ящиков, есть своя IT-инфраструктура (другие серверы, мониторинг, бэкапы уже настроены под что-то ещё). Свой сервер обычно выгоднее по деньгам на длинной дистанции и даёт полный контроль, а предельные трудозатраты на добавление почты к уже существующей инфраструктуре ниже, чем разворачивать её с нуля отдельно.

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

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