Кейс: своя почта на iRedMail для бухгалтерской фирмы на 35 сотрудников — от Яндекс 360 к серверу за 4 990 ₽/мес

Портрет клиента и исходная боль

Меня зовут Евгений Семёнов, я технический директор ITfresh. Этой статьёй закрываю серию про iRedMail: был обзор, установка на Debian 13, миграция и регламент эксплуатации. Сегодня — то, ради чего всё затевалось: разбор реального внедрения от первого звонка до цифр через год. Кейс собирательный и обезличенный — я сложил его из нескольких похожих проектов и убрал всё, по чему можно узнать конкретную компанию, — но каждая цифра и каждая ошибка в нём настоящие.

Клиент — бухгалтерская фирма из Москвы: 35 сотрудников, порядка 120 обслуживаемых организаций на аутсорсинге. Почтовых ящиков при этом не 35, а 48: у каждого бухгалтера личный, плюс ролевые buh@, zarplata@, docs@, отдельные адреса под группы клиентов и технические ящики для сканера и 1С. Всё это жило в Яндекс 360 и ежемесячно превращалось в счёт, который рос при каждом пересмотре тарифов.

Триггеров для переезда оказалось три, и деньги — только третий по важности:

• Требование хранить переписку у себя. В почте бухгалтерской фирмы — банковские выписки клиентов, кадровые документы, договоры на обслуживание. Несколько крупных клиентов фирмы прямо прописали в договорах, что переписка по их учёту не должна храниться в публичных облаках. Спорить с формулировкой можно, выполнить её в облаке — нельзя.
• Негибкость облака. Руководителю нужен был неудаляемый архив всей доменной переписки на случай споров с клиентами («вы нам этот акт не присылали») и автораскладка входящих по папкам клиентов. В облачном тарифе — либо никак, либо через дорогие корпоративные надстройки.
• Ценник. 48 ящиков в Яндекс 360 на тарифе с нормальным объёмом диска — это уже за двадцать тысяч в месяц, и цифра индексировалась каждый год.

Требования бухгалтерии к почте — специфика сегмента

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

• Ни одно письмо от ИФНС, СФР и банков не должно потеряться. Госорганы и банки — чемпионы по кривым отправителям: самописные SMTP-релеи, отсутствующие PTR, ломаные SPF. Закрутить антиспам «на максимум» здесь нельзя — цена ложного срабатывания слишком высока.
• Вложения до 50 МБ. Акты сверки на сотню страниц, сканы первички пачками, архивы с базами — стандартный лимит в 15–25 МБ вызывал у бухгалтеров ежедневную боль с файлообменниками.
• Архив переписки минимум 5 лет. Срок исковой давности плюс запас: при споре с клиентом или проверке нужно поднять переписку трёх-, пятилетней давности, даже если сотрудник давно уволился и его ящик удалён.
• Ролевые ящики с доступом нескольких человек — buh@, zarplata@, docs@ — и понятное управление, кто из сотрудников какой ролевой ящик видит.
• Автоответы в отчётный период. В марте и апреле фирма физически не успевает отвечать в день обращения — нужны управляемые автоответы на группах ящиков.

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

Почему выбрали iRedMail, а не mailcow, Carbonio или облако

Мы обслуживаем и mailcow-серверы, и классические стеки, поэтому выбор был не религиозным, а практическим. Логика аутсорсера такая: сервер будет жить годами, обслуживать его будем мы, значит, стек должен быть прозрачным, экономным по железу и без лицензионных платежей вообще.

• iRedMail — классический стек Postfix + Dovecot + Rspamd без контейнеров. Все конфиги на своих местах, любой наш инженер чинит его штатными средствами. Требования к VPS скромные. Выбрали его.
• Mailcow — отличный продукт, но это Docker-стек c бо́льшим аппетитом к памяти. Для клиентов, где почта — часть большой инфраструктуры с контейнерами, берём его; здесь это было избыточно.
• Carbonio CE / наследники Zimbra — сильны общими календарями и документами, но просят от 8–12 ГБ RAM и заметно сложнее в сопровождении. Фирме нужна была почта, а не групповое ПО.
• Российские облака (VK WorkSpace и аналоги) — не решали требование «переписка у себя» и стоили сопоставимо с Яндексом.

Экономику считали на горизонте трёх лет — короче для инфраструктурных проектов считать нечестно. Округлённые цифры в ценах середины 2026 года:

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

Архитектура решения

Ничего экзотического — ровно та схема, которую я описывал в статьях про установку и эксплуатацию, с поправками под объём:

• VPS: 4 vCPU, 8 ГБ RAM, 250 ГБ NVMe в российском дата-центре. Восемь гигабайт вместо минимальных четырёх — из-за 48 ящиков и ClamAV; 250 ГБ — под 212 ГБ мигрируемой почты с запасом на полтора-два года роста.
• Debian 13 + iRedMail 1.8.4, бэкенд учёток — MariaDB, веб-сервер Nginx.
• Roundcube — основной веб-клиент для сотрудников; SOGo включили для четырёх руководителей ради календарей и нормальной синхронизации с телефонами через ActiveSync.
• Outlook по IMAP на рабочих местах — половина офиса так и осталась в привычном клиенте.
• Бэкап в независимое хранилище в другом ЦОД: ночной дамп MariaDB плюс инкрементальная синхронизация maildir. Хранилище у другого провайдера — сознательно: сгоревший ЦОД не должен уносить и почту, и её копии.

К серверу также подключены МФУ (сканы «в почту») и 1С, которая рассылает клиентам акты и счета через отдельный технический ящик — с его же SMTP-авторизацией, чтобы рассылки фирмы не портили репутацию основного домена анонимными релеями.

Внедрение по этапам: реальный таймлайн

Неделя 1 — сервер, DNS, тесты

Заказали VPS, тикетами у хостера открыли исходящий 25-й порт и прописали PTR, развернули iRedMail по нашему регламенту, настроили DKIM/DMARC, завели тестовые ящики. Всю неделю новый сервер просто «прогревался»: с него понемногу ходила тестовая переписка на Gmail, Яндекс и Mail.ru, чтобы к моменту переезда IP не был для больших провайдеров чистым листом.

Неделя 2 — imapsync: 48 ящиков, 212 ГБ

Почту с Яндекса тянули imapsync по app-паролям (обычные пароли Яндекс для IMAP-доступа сторонних клиентов не принимает — для каждого ящика выпускается пароль приложения). Две грабли, к которым стоит быть готовым:

• Лимиты скорости IMAP у источника. Облако начинает притормаживать выгрузку при агрессивной параллельности. Больше четырёх-пяти параллельных потоков запускать бессмысленно — суммарная скорость не растёт, а вероятность обрывов растёт.
• Ящик главбуха на 31 ГБ. Пятнадцать лет переписки, вложения по 40 МБ, десятки тысяч писем в одной папке. Такой ящик синхронизировался почти сутки и дважды падал по таймауту — лечится повторным запуском imapsync, он докачивает только разницу.

Первый полный проход по всем ящикам занял четыре ночи. Дальше — ежесуточные дельта-проходы, каждый по 20–40 минут: к моменту переключения расхождение между облаком и сервером измерялось часами, а не неделями.

День X — смена MX в пятницу вечером

MX переключили в пятницу в 19:00 с TTL 300, заранее сниженным за сутки. Выходные — буфер: почтовый трафик минимален, а старый сервер Яндекса ещё принимал письма от отстающих DNS-кешей, и субботний дельта-прогон imapsync забирал их на новый сервер. К понедельнику вся доставка шла на iRedMail.

Неделя 3 — рабочие места и люди

Самая недооцениваемая часть проекта — не серверная. Перенастройка Outlook на 35 рабочих местах, замена паролей на сгенерированные, настройка подписей, телефоны руководителей через ActiveSync. Плюс час обучения по группам: где веб-клиент, как выглядит карантин Rspamd, куда писать, если письмо «не дошло». Типовые вопросы первых дней: «почему папка Отправленные пустая» (клиент писал копии в локальную папку — поправили маппинг), «где мои контакты» (адресную книгу Яндекса выгружали отдельно в vCard) и «почему письмо от банка в карантине» — об этом ниже.

Тонкие настройки под бухгалтерию

Теперь то, ради чего фирма и уходила из облака, — серверные правила под специфику бизнеса.

Госорганы и банки — никогда не в спам

Верхнеуровневая идея: письма доменов ИФНС, СФР и банков клиентов не должны попадать в карантин даже при плохом скоринге. В Rspamd для этого мы завели отдельную группу с отрицательным весом для доверенных доменов — но с важной оговоркой: белый список работает только по envelope-from, прошедшему SPF-проверку. Просто внести nalog.ru в whitelist нельзя — первый же фишер, подставивший отправителя, войдёт в дверь с ковровой дорожкой. Связка «домен + валидный SPF» закрывает эту дыру.

Большие вложения

Лимит письма поднят до 50 МБ в Postfix (message_size_limit = 52428800) и продублирован в лимитах Nginx/PHP для веб-клиента, иначе Roundcube обрежет вложение раньше, чем Postfix его увидит. Сотрудников честно предупредили: 50 МБ — предел на нашей стороне, принимающая сторона может резать и на 25.

Архив переписки

Неудаляемый архив сделан через always_bcc в Postfix: скрытая копия каждого входящего и исходящего письма домена падает в отдельный ящик archive@, доступ к которому есть только у управляющего партнёра. Ящик исключён из пользовательских квот, письма из него не удаляются, объём мониторится. Важная юридическая оговорка, которую мы проговариваем с каждым клиентом: тотальное архивирование корпоративной переписки должно быть закреплено в локальных актах, и сотрудники должны быть под подпись с этим ознакомлены — иначе у архива будут проблемы посерьёзнее дискового места.

Автораскладка и квоты

На ящике docs@ работает набор sieve-правил: входящие от известных доменов клиентов раскладываются по папкам «Клиенты/ИмяКлиента» — бухгалтер, ведущий конкретную организацию, видит свою папку и не роется в общем потоке. Квоты назначены по ролям прямо в SQL (поле quota в таблице mailbox базы vmail): рядовым — 5 ГБ, ведущим бухгалтерам — 10, главбуху — 30. При 85% заполнения iRedAdmin шлёт предупреждение — за год до лимита дошли трое.

Что пошло не так — честный раздел

Проектов без факапов не бывает; вопрос в том, попадают ли они потом в регламент. Три штуки из этого внедрения попали.

• Mail.ru неделю грейлистил свежий IP. Несмотря на прогрев, первые дни письма некоторым адресатам на Mail.ru доходили с задержкой 15–40 минут: типичный greylisting для IP без истории. Помогла регистрация домена в постмастере Mail.ru и ровный поток легитимной почты — через неделю задержки исчезли. Вывод в регламент: прогрев начинать не за неделю, а за две, постмастеры заводить до смены MX.
• Сканер Kyocera не умел современный TLS. Старое МФУ отказалось дружить с TLS 1.2 на 587-м порту. Чинить прошивку десятилетнего аппарата — утопия; подняли для него локальный relay-порт, доступный только с IP сканера внутри офисной сети, без TLS. Некрасиво, зато честно изолировано.
• «У меня пропали письма». Через две недели после переезда сотрудница сообщила о пропаже входящих от одного клиента. Оказалось — sieve-фильтры: на Яндексе у неё были свои правила раскладки, при переезде она вручную пересоздала их в Roundcube и ошиблась условием — письма улетали в архивную папку. Вывод в регламент: при миграции собирать у сотрудников список их личных фильтров и переносить централизованно.

Цифры через год эксплуатации

Сервер работает 13-й месяц. Сводка из мониторинга и отчётов, которые мы ежемесячно отдаём клиенту:

Экономия за первый год с учётом внедрения — около 130 тысяч рублей, со второго года — около 190 тысяч в год. Но клиент, что показательно, в отзыве первым пунктом называет не деньги, а архив: за год он дважды выигрывал споры с клиентами, поднимая из archive@ переписку с точными датами и вложениями.

Чему кейс учит другие сегменты

Схема переносится почти без изменений на другие бизнесы «до 50 рабочих мест», меняются только акценты:

Общий знаменатель один: везде, где в переписке живут чужие деньги, документы или персональные данные, аргумент «письма лежат у нас, и мы знаем, где именно» перевешивает удобство облачной галочки «всё само».

Итог — и когда так делать не надо

Честные противопоказания, при которых я сам отговорю вас от этого проекта:

• Нет договора на сопровождение и нет своего админа. Почта — сервис, который должен работать всегда. Сервер «поставили и забыли» без обновлений и мониторинга через год превратится в проблему — от переполненного диска до участия в чужих рассылках.
• У вас 5–7 ящиков. Экономика не сойдётся: облако за пару тысяч в месяц дешевле любого сопровождаемого сервера. Возвращайтесь к расчёту от 15–20 ящиков.
• Нужен полный паритет с Exchange — общие календари уровня секретариата, делегирование ящиков, единый групповой софт. Это не про классический iRedMail; смотрите Carbonio CE — про него следующая серия статей.

Если же у вас 20–50 сотрудников, в переписке — клиентские документы, а счёт за облачную почту вырос до неприличия, этот кейс воспроизводим практически один в один. Приходите на бесплатный аудит почтовой инфраструктуры: посчитаем вашу экономику на трёх годах, честно скажем, сойдётся ли она, и покажем план миграции без потери единого письма. Telegram @ITfresh_Boss или +7 903 729-62-41.