Кейс: переводим бухгалтерскую фирму на 30 сотрудников с публичной почты на свой mailcow — цифры, сроки, подводные камни

Меня зовут Евгений Семёнов, я технический директор «АйТи Фреш»; это пятая статья нашей серии о mailcow — после обзора, установки, миграции и эксплуатации — и сегодня вместо инструкции будет история одного проекта. Кейс собирательный: я сложил его из нескольких реальных внедрений последних двух лет, чтобы не раскрывать клиентов, но каждая цифра и каждая грабля в нём — из практики, а не из головы. Наш собственный прод — mailcow в дата-центре МТС, 21 домен и больше двухсот ящиков, — так что советовать чужое мы не привыкли.

Исходная ситуация: почта бухфирмы как источник рисков

Портрет клиента. Бухгалтерская фирма в Москве: 30 сотрудников, свыше 400 обслуживаемых юрлиц и ИП на аутсорсинге учёта. Почта — главный рабочий канал: по ней ходят акты, счета, кадровые документы, сканы паспортов директоров, запросы банков и переписка с налоговыми юристами. Повод для обращения был приземлённый: клиенты всё чаще жаловались, что «акты не доходят», а директор прочитал новость об очередной утечке и впервые задал себе вопрос, где физически лежит переписка его фирмы.

Мы начали с аудита, и его результаты я показываю почти без купюр — потому что такую картину мы видим у семи из десяти небольших фирм:

• Половина ящиков — на публичных сервисах. 14 сотрудников работали с адресов вида familiya.buh@mail.ru и ivanova.uchet@gmail.com. Домены фирмы в адресах не было вовсе: сайт жил на одном хостинге, почта — где придётся.
• Общий ящик с одним паролем на шестерых. Через docs-firma@mail.ru шёл приём первички от клиентов; пароль знали шесть человек, был записан на стикере и не менялся четыре года.
• Уволенные с живыми доступами. Три бывших сотрудника теоретически могли читать клиентскую переписку со своих телефонов — их личные ящики, засветившиеся в рабочих цепочках, никто «отключить» не мог в принципе.
• Ноль резервных копий. Вся история переписки с 400 клиентами существовала в одном экземпляре — на серверах публичных сервисов, к которым у фирмы не было ни договора, ни SLA, ни кнопки «выгрузить всё».

Почему для бухгалтерии это критично

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

Постановка задачи и выбор решения

Требования директор сформулировал по-хозяйски, без технических терминов, и мне они до сих пор кажутся образцовыми:

1. Все адреса — только на домене фирмы. Никаких публичных сервисов в подписи и на визитках.
2. Почта должна работать на смартфонах и в привычном Outlook «как раньше» — переучивать 30 бухгалтеров в разгар отчётного периода никто не даст.
3. Переписка уволенного сотрудника остаётся у фирмы: архив, передача дел, переадресация клиентов.
4. Ежемесячный платёж — меньше, чем аренда корпоративной почты у облачного провайдера.

Сравнение, которое мы показали клиенту

Мы честно посчитали три сценария на горизонте трёх лет — именно на таком горизонте разовые затраты внедрения перестают искажать картину. Аренда: Яндекс 360 на 30 ящиков в нужной комплектации выходил в 110–160 тысяч рублей в год в зависимости от тарифа и скидок. Exchange on-premise: классика для тех, кто хочет «как у больших», — но лицензии сервера и клиентские доступы плюс железо дают шестизначную разовую сумму, а функционально для 30 человек это стрельба из пушки по воробьям. И mailcow на арендованном VPS: около 36 тысяч рублей в год за инфраструктуру плюс работа подрядчика.

Почему из «своих» вариантов именно mailcow, а не Exchange и не голый Postfix? Три аргумента, которые убедили клиента. Первый — встроенный ActiveSync: Outlook и смартфоны подключаются со всеми календарями и контактами без единой лицензии Exchange, то есть требование «как раньше» закрывается бесплатно. Второй — API: 30 ящиков заводятся скриптом за минуты, и этим же API потом пользуется регламент увольнения. Третий — лицензия GPL-3.0: никакой платы за ящик, домен или «расширенный» функционал, расходы не растут вместе с штатом. Подробный разбор сборки — в обзорной статье серии, здесь важен итог: решение выбрано, бюджет утверждён, поехали.

Проект внедрения по неделям

Весь проект занял три календарные недели — от подписания до момента, когда последний сотрудник отправил первое письмо с нового адреса. Разбивка по неделям — не маркетинг, а реальный ритм: почту нельзя переключать рывком, ей нужен параллельный период.

Неделя 1 — фундамент. Арендовали VPS 4 vCPU / 8 ГБ RAM / 80 ГБ SSD, проверили репутацию выданного IP по чёрным спискам, заказали у хостера PTR-запись, тикетом открыли исходящий 25-й порт. Опубликовали DNS-фундамент: A, MX, SPF, DMARC, autodiscover — всё по нашему регламенту, который я по шагам разобрал в статье об установке. Развернули mailcow (на тот момент — актуальный релиз 2026-05c «Mooay 2026»), завели тестовый домен и неделю гоняли на нём отправку: mail-tester, заголовки в Gmail и Mail.ru, доставка на капризные корпоративные серверы клиентов фирмы.

Неделя 2 — ящики и политики. Кадровик выгрузил список сотрудников в CSV, и 30 ящиков создались скриптом через POST /api/v1/add/mailbox — API-ключ выпущен в админ-панели с ограничением по IP нашего сервера управления. Единый шаблон адресов familiya@, стойкие сгенерированные пароли, персональные квоты. Дальше политики: принудительная 2FA для администраторов и главбуха (mailcow с весны 2026 умеет требовать TOTP на уровне политики, а не уговоров), запрет слабых паролей, и точечная настройка: ящикам, через которые ходят клиентские базы и кадровые документы, ограничили протоколы EAS/DAV — синхронизировать их на личные планшеты стало нельзя.

Неделя 3 — миграция и переключение. Переписку с публичных сервисов переносили imapsync по двухпроходной схеме: первый прогон — вся история заранее, второй — дельта в ночь переключения. Для Gmail и Mail.ru выпускали пароли приложений, потому что обычные пароли IMAP-доступ там уже не открывают. Всю неделю фирма жила в параллельном режиме: старые ящики принимали, новые — уже отправляли. MX переключили в ночь с пятницы на субботу, когда поток входящих минимален, и до понедельника держали двойной контроль входящих на обоих концах.Техническая сторона этой процедуры со всеми флагами imapsync — в отдельной статье о миграции.

Что пошло не по плану

Идеальных проектов не бывает, и врать, что всё прошло по нотам, я не стану. Три сюрприза этого внедрения:

• Два сотрудника не знали паролей от собственных Gmail. Ящики были заведены много лет назад, входили в них по сохранённой сессии телефона, привязанные номера — устаревшие. Восстановление доступа через процедуры Google заняло четыре дня; их переписку мы переносили последней, уже после переключения MX.
• PST-архив на 40 ГБ у главбуха. Пятнадцать лет переписки лежали не на сервере, а в локальном файле Outlook. imapsync такое не видит: архив загружали в новый ящик прямо из Outlook, порциями, с поднятой на время квотой, — плюс два вечера к плану.
• МФУ 2015 года не умело TLS 1.2. Сканер, отправлявший документы «сканируй в почту», не смог подключиться к новому серверу: его прошивка знала только устаревшие протоколы шифрования. Обновление прошивки не помогло, и мы завели для МФУ отдельный приёмный ящик с ограничением по внутреннему IP — компромисс, зафиксированный в паспорте системы до замены аппарата.

Организационная часть, без которой техника не работает

Самая частая ошибка таких проектов — считать, что после переключения MX работа закончена. Сервер — половина дела; вторая половина — заставить организацию им пользоваться. Если через месяц половина сотрудников продолжит переписываться с клиентами со старых личных ящиков, весь проект превращается в дорогую декорацию.

Поэтому одновременно с переключением директор подписал приказ о переходе на корпоративную почту: с даты Х вся рабочая переписка ведётся только с адресов на домене фирмы, использование личных ящиков для рабочих задач запрещено, старые публичные адреса переводятся в режим автоответа «мы переехали». К приказу — памятка на одну страницу: как зайти в веб-почту, как настроить телефон, куда звонить, если что-то не работает. И одно 30-минутное обучение на всех: показали SOGo, показали настройку смартфона через автоконфигурацию, ответили на вопросы. Больше получаса не потребовалось — в этом, собственно, и смысл требования «как раньше»: интерфейсы не изменились, изменился только адрес.

Регламент увольнения: 30 секунд вместо «никогда»

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

Ящики-роли вместо личных адресов

Вторая организационная находка проекта — ролевые ящики. Клиенты фирмы раньше писали конкретному бухгалтеру на личный адрес, и когда тот уходил в отпуск или увольнялся, переписка рвалась. Мы завели роли: docs@ — приём первички, salary@ — зарплатный блок, otchet@ — отчётность. Каждая роль доставляется в ящики нужной группы сотрудников, а право отправлять «от имени» роли выдано через sender_acl конкретным людям. Клиент пишет на функцию, а не на человека — и смена исполнителя внутри фирмы для клиента вообще незаметна. Бонус, которого не ждали: у общего ящика «с паролем на стикере» не стало наследника — роли не требуют общего пароля в принципе.

Результаты через 3 месяца в цифрах

Проект сдан — но кейс без измеримого результата ничего не стоит. Через три месяца после переключения мы сняли контрольные показатели:

• Доставляемость. mail-tester стабильно 10/10; жалобы клиентов «не дошёл акт», которых до проекта набиралось около пяти в неделю, за третий месяц — ноль. Исчез и обратный поток: письма фирмы перестали падать в спам корпоративных серверов её крупных клиентов, потому что домен обзавёлся SPF, DKIM и DMARC.
• Экономика. Прямые расходы — 3000 рублей в месяц за VPS плюс примерно 4 часа сопровождения в рамках действующей абонентки. Альтернатива в виде аренды на 30 ящиков стоила бы порядка 13 тысяч в месяц. Разница около 10 тысяч ежемесячно окупила 70 тысяч за внедрение за 7 месяцев — дальше экономия чистая.
• Управляемость. Заведение нового сотрудника — 5 минут вместе с инструктажем; блокировка уволенного — 30 секунд; полный бэкап сервера (220 ГБ вместе с историей переписки) уезжает на отдельную площадку каждую ночь, восстановление отдельного ящика отрепетировано на учениях — как это устроено, я разбирал в статье об эксплуатации.
• Безопасность. 2FA включена у всех, кто имеет доступ к панели и к ящикам с клиентскими данными. Контейнер netfilter за первый квартал заблокировал около 12 тысяч попыток перебора паролей — цифра, которая лучше любых слов объясняет директору, зачем всё это было.

Специфика других сегментов нашей ЦА

Бухгалтерия — самый частый, но не единственный профиль таких проектов. Ядро везде одинаковое — тот же стек, тот же регламент внедрения; различается обвязка политик поверх него.

Юридическая фирма: конфиденциальность выше удобства

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

Медицинская клиника: врачебная тайна и изоляция регистратуры

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

Торговая компания: поток счетов из 1С

У торговцев боль другая: сотни исходящих счетов и актов в день, которые шлёт учётная система. Если пустить этот поток через ящик менеджера, антиспам-системы получателей быстро запишут домен в рассыльщики. Решение — отдельный релей-ящик для 1С с собственным rate-limit: поток документов идёт равномерно, не смешивается с живой перепиской и не тянет вниз репутацию основного домена.

Мораль сегмента проста: не бывает «почты вообще» — бывает почта под профиль рисков конкретного бизнеса. Именно поэтому шаблонные тарифы аренды жмут то тут, то там, а свой сервер настраивается под профиль точно.

Когда мы отговариваем клиента от своего сервера

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

Первая: микрокоманда без бюджета на сопровождение. Пять человек, почта нужна «чтобы была», платить за поддержку нечем и некому. Честный ответ: возьмите аренду у крупного провайдера. Экономика своего сервера складывается от десятка ящиков и выше, а без сопровождения он превратится в тыкву при первом же инциденте.

Вторая: нулевая терпимость к простою без денег на резервный контур. Если минута лежащей почты — сорванная сделка, одного сервера мало: нужен резервный MX, мониторинг с дежурством, отработанный план аварийного восстановления. Это всё реализуемо, но стоит денег; если их в бюджете нет — аренда с её SLA будет честнее.

Третья: некому даже перезагрузить VPS. Ни своего админа, ни подрядчика, ни желания их заводить. Свой сервер — это ответственность владения; без рук, которые раз в месяц смотрят на метрики и обновляют стек, она не работает.

Вывод, к которому мы пришли за годы: mailcow — оптимум для юрлица на 10–50 рабочих мест, у которого есть подрядчик или толковый штатный админ. Ниже — аренда, выше — уже разговор про кластеры и выделенную команду. Проверьте себя по короткому чек-листу:

1. В компании 10 и более почтовых ящиков?
2. По почте ходят персональные данные или коммерческая тайна клиентов?
3. Есть подрядчик или админ, готовый уделять серверу 3–5 часов в месяц?
4. Ежемесячный счёт за аренду почты уже заметен в бюджете или станет заметен при росте?
5. Вам важно блокировать доступ уволенных и хранить их переписку?
6. Простой почты на 2–3 часа в год переживаем без катастрофы?
7. Готовы один раз вложиться во внедрение ради низких постоянных расходов?

Пять и больше «да» — вы кандидат на свой сервер, и этот кейс примерно про вас. Три-четыре — считайте TCO на своих цифрах, развилка близко. Меньше трёх — оставайтесь на аренде и вернитесь к вопросу через год: бизнес растёт быстрее, чем кажется. А если хотите пройти нашу самодиагностику не в одиночку — напишите, посчитаем вместе на ваших данных.