Почтовый веб-сервер: выбор и настройка для корпоративной почты

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

Сколько ящиков - и что из этого следует

Первый вопрос - сколько у вас ящиков и кто будет за них отвечать. Выбор софта идёт вторым: от масштаба пляшет всё остальное.

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

Из чего состоит почтовый сервер

Почтовый веб-сервер - это не одна программа, а связка из трёх компонентов, каждый из которых отвечает за свой участок работы. Если нужен разбор с азов, что это за зверь и зачем он бизнесу, есть отдельный текст: что такое почтовый сервер.

MTA (Mail Transfer Agent) - это агент, который отправляет и получает письма по протоколу SMTP. Самый популярный вариант в Linux-мире - Postfix. Он принимает письмо от вашего сотрудника, смотрит, куда его нужно доставить, и передаёт на сервер получателя. Обратный процесс тоже на нём: когда вам пишут, Postfix принимает письмо и сохраняет.

MDA/IMAP-сервер - это Dovecot в большинстве случаев. Он хранит полученные письма и раздаёт их клиентам по протоколам IMAP или POP3. Когда сотрудник открывает Outlook или Thunderbird, он подключается именно к Dovecot и скачивает свою почту.

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

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

Свой сервер или облако: что выбрать

Классическая развилка для IT-директора: поднимать свою инфраструктуру или платить за облачный сервис? Оба варианта работают, но под разные задачи.

Цены на облачные тарифы - по прайсам Яндекс 360 и VK WorkSpace на июль 2026: минимальные тарифы от 207-319 ₽ за пользователя, рабочие - 459-549 ₽.

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

Импортозамещение добавило в этот расклад российские опции. TEGU, RuPost и МойОфис Почта - системы из реестра отечественного ПО, которые рассчитаны на работу в кластере и интеграцию с российскими средствами защиты.

TEGU интересен тем, что отказался от традиционного хранения писем в maildir-файлах, где каждое письмо лежит отдельным файлом на диске. Всё складывается в базу данных, а пароли хранятся отдельно, в LDAP. Взломали почтовый сервер - не получили автоматически доступ к паролям.

RuPost пошёл другим путём: готовые конфигурационные шаблоны для кластеров и интеграция с российскими DLP-системами без допиливания. Установил, настроил пару параметров - и работает. Для тех, кто не хочет месяц разбираться с документацией.

Где разместить: своё железо, аренда, VPS или облако

Почтовый сервер для организации можно разместить четырьмя способами, и отличаются они и по деньгам, и по зоне ответственности.

Про VPS есть нюанс, который всплывает уже после запуска. Почтовый сервер живёт репутацией своего IP-адреса, а на дешёвом хостинге адрес достаётся из подсети, где до вас кто-то мог рассылать спам. Письма начнут уходить в папку «Спам» у половины получателей, и виноват будет не ваш конфиг. Перед покупкой стоит проверить адрес по публичным чёрным спискам и уточнить у провайдера, даёт ли он PTR-запись под ваш домен.

Собирать руками, брать готовый образ или коробочный продукт

Три пути, и выбор между ними - это выбор между контролем и скоростью.

Собирать руками означает ставить Postfix, Dovecot, Roundcube, базу под учётные записи и антиспам поверх. Дольше всего. Зато вы понимаете каждую строчку конфига и чините сервер сами, без оглядки на автора сборки. Разумно, если админ уже работал с почтой.

Готовая сборка снимает половину этой работы. Mailcow упаковывает весь стек в набор Docker-контейнеров с веб-панелью; ориентир по памяти - от 8 ГБ, меньше брать смысла нет. iRedMail живёт с 2007 года и ставится прямо на систему, без контейнеров. Stalwart написан на Rust и заметно скромнее по ресурсам. Старт занимает часы вместо дней, но обновляться придётся по правилам сборки, а не по своим.

Коробочный продукт - это TEGU, RuPost или МойОфис Почта. Их берут, когда нужны запись в реестре отечественного ПО, поддержка по договору и интеграция с российскими средствами защиты без самодеятельности. Платят за это лицензией и меньшей свободой в конфигурации.

Универсального ответа нет. Компании с одним админом чаще выигрывают от готовой сборки: она не требует помнить, где в Postfix лежит какой параметр.

Какое железо нужно для сервера

Если решили поднимать своё, железо подбирается исходя из количества пользователей и объёма почты.

Для компании на 100-150 человек стартовый минимум: 8 ядер CPU, 32 ГБ оперативки, 500 ГБ SSD для почтовой базы. Это если считать, что средний ящик весит 2-3 ГБ, а письма не хранятся годами. HDD можно использовать для архивных писем, но активная работа должна идти с SSD - иначе IMAP будет тормозить на больших ящиках.

Почему именно диск, а не частота процессора. IMAP - это поток мелких случайных обращений: клиент открывает папку, сервер лезет в индекс, отдаёт заголовки, потом тело письма. Когда таких клиентов сотня и у каждого ящик на несколько гигабайт, дисковая подсистема захлёбывается раньше, чем загрузится процессор. На механическом диске это выглядит как «почта тупит», хотя по мониторингу сервер простаивает.

Объём считают так: число ящиков умножить на средний размер ящика, добавить запас на рост года на три, прибавить место под индексы и вторую копию для резервного копирования. Сотня ящиков по 3 ГБ - это 300 ГБ данных, и 500 ГБ SSD из абзаца выше окажутся впритык уже через пару лет.

С оперативкой похожая история. Её разбирают между собой база учётных записей, кеш индексов Dovecot и антиспам с антивирусом: одни только базы сигнатур ClamAV держат порядка гигабайта, и от версии к версии этот аппетит растёт. Процессор нагружают те же самые проверки - каждое входящее письмо стоит тактов. Поэтому 32 ГБ из абзаца выше расходуются быстрее, чем кажется на старте.

Для 500-1000 пользователей уже нужна отказоустойчивость: два сервера в кластере, общий массив хранения (NAS или SDS), балансировка нагрузки. И да, обязательно ИБП - почтовый сервер не любит внезапных отключений, это прямой путь к повреждённым базам.

Базовая настройка: быстрый старт

Стандартная связка для Linux - Postfix + Dovecot + Roundcube на Debian или Ubuntu. Процесс занимает несколько часов, если знаешь, что делаешь.

Устанавливаешь пакеты через apt: postfix для SMTP, dovecot-imapd и dovecot-pop3d для доступа к письмам, postfixadmin для веб-управления ящиками, roundcube для веб-клиента. Всё это крутится поверх MySQL или PostgreSQL - база нужна для хранения учётных записей, паролей и настроек.

Postfix настраивается через файл main.cf: прописываешь домен, указываешь путь к хранилищу писем, включаешь TLS для шифрования. Dovecot подключаешь к той же базе, чтобы он знал, какие ящики существуют. Roundcube ставишь в веб-сервер (Apache или Nginx), связываешь с IMAP-сервером - и базовая конфигурация готова.

Но это только половина дела. Пошаговый разбор с командами и конфигами мы вынесли в отдельный материал - создание почтового сервера с нуля; здесь дальше речь про то, обо что этот запуск чаще всего спотыкается.

Порты и грабли, о которые спотыкаются на запуске

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

Дальше начинаются грабли. Почти все они лежат за пределами конфига Postfix, и именно поэтому их ищут последними.

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

Следом идёт PTR. Обратная запись должна совпадать с тем именем, которым сервер представляется при соединении; не совпадает - и крупные почтовые системы относятся к письму настороженно ещё до проверки подписи. Выдаёт её владелец IP-адреса: провайдер или дата-центр. В своей зоне DNS вы её не пропишете.

Отдельная история - серые списки (greylisting). Получатель задерживает первое письмо с незнакомого адреса на 5-15 минут. Это не поломка. Через несколько дней переписки адрес запоминают и задержка исчезает. Но в первый день после переезда бухгалтерия успевает трижды позвонить в панике.

Если порты и протоколы - не ваша ежедневная тема, пригодится базовый разбор: что такое порт в сети.

DNS-записи: без них никуда

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

MX-запись указывает, куда доставлять почту для вашего домена. Без неё письма вообще не придут.

SPF (Sender Policy Framework) - это список IP-адресов, с которых можно отправлять почту от имени вашего домена. Если письмо пришло с другого адреса, получатель имеет право его отклонить.

DKIM (DomainKeys Identified Mail) - цифровая подпись письма. Ваш сервер подписывает каждое исходящее письмо закрытым ключом, а получатель проверяет подпись открытым ключом из DNS. Если подпись не совпала - письмо подделано или изменено по пути.

DMARC (Domain-based Message Authentication) - политика, которая говорит получателю, что делать с письмами, не прошедшими проверку SPF или DKIM. Можно настроить карантин (отправка в спам) или полный отказ, когда письмо даже не доставляется.

MTA-STS (Mail Transfer Agent Strict Transport Security) - принудительное TLS-шифрование между почтовыми серверами. Без него письма могут передаваться открытым текстом, даже если оба сервера поддерживают шифрование.

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

Безопасность: чего боятся почтовые серверы

Корпоративная почта - лакомый кусок для атакующих. Тут и данные, и доступ к внутренним системам, и возможность рассылать фишинг от имени компании.

Первый уровень защиты - фильтры спама и антивирус. Rspamd анализирует входящие письма и отсеивает мусор. ClamAV проверяет вложения на вирусы. Это базовый минимум, который должен стоять на любом почтовом сервере.

Второй уровень - двухфакторная аутентификация. Пароли компрометируются регулярно, а второй фактор добавляет ещё один барьер. Настраивается через Dovecot с поддержкой TOTP: подойдут любые приложения-аутентификаторы.

Третий уровень - интеграция с корпоративными системами безопасности. Компании, которым важен контроль утечек и коммерческая тайна, подключают к почте DLP (Data Loss Prevention) и SIEM (Security Information and Event Management). DLP ловит письма с конфиденциальной информацией вроде номеров карт и внутренних документов, SIEM собирает логи для разбора инцидентов. По данным опроса InfoWatch за 2023 год, DLP-системы внедрены примерно у половины организаций, но подавляющее большинство из них - крупный бизнес; в малых компаниях это редкость.

Для интеграции с Active Directory или LDAP нужен модуль аутентификации в Dovecot и Postfix. Тогда работает единая база пользователей: завели учётку в Active Directory - сотрудник автоматически получил доступ к почте. Уволили - отключили учётку, и почта закрылась в тот же момент.

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

Резервное копирование почты

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

Копируют обычно письма и на этом успокаиваются. В минимальный комплект входит больше:

• сами письма: каталог maildir или дамп базы, смотря как устроено хранилище;
• база учётных записей с паролями и алиасами;
• конфигурационные файлы Postfix и Dovecot;
• закрытые ключи DKIM и TLS-сертификаты.

Про ключи DKIM забывают почти всегда. Восстановили сервер, письма ходят, а подпись не проходит проверку, потому что закрытый ключ остался на мёртвом диске - и приходится генерировать новую пару и править DNS, пока вся исходящая почта валится в спам.

Ещё одна ловушка: копию, которую ни разу не разворачивали, правильнее называть надеждой. Раз в квартал разумно поднять почту из бэкапа на тестовой машине и открыть в ней несколько ящиков. Полчаса работы, зато вы знаете, что копия живая.

И последнее: окно резервного копирования растёт вместе с ящиками. То, что на старте копировалось за двадцать минут, через три года копируется четыре часа - и упирается в рабочий день. Обычно на этом этапе почту переводят на инкрементальные копии, а под сами копии заводят отдельную машину - backup станция нужна как раз затем, чтобы копии не жили на том же массиве, что и оригинал.

Масштабирование: когда одного сервера мало

При росте компании почтовый сервер упирается в производительность. Тысяча активных ящиков, большие вложения, рассылки на тысячи адресов - один сервер начинает задыхаться.

Кластеризация решает проблему: несколько серверов работают как единая система. Postfix можно запустить на нескольких машинах с балансировщиком вроде HAProxy, который распределяет нагрузку. Хранилище писем выносится на SAN или SDS - отказоустойчивый массив, доступный всем серверам.

Здесь всплывает та самая причина, по которой TEGU ушёл от maildir. Когда каждое письмо - отдельный файл, а хранилище общее и сетевое, узлы начинают спорить за блокировки, и почта ловит странные ошибки под нагрузкой. Поэтому под кластер берут либо блочный доступ вместо файловой шары, либо систему, которая изначально хранит письма в базе. На двух узлах это ещё терпимо, на пяти уже нет.

Миграция из Google Workspace или Microsoft Exchange - отдельная история. Письма переносятся через IMAP-синхронизацию инструментами вроде imapsync, но пароли не мигрируют: пользователи получают новые. Календари и контакты переносятся отдельно, через экспорт-импорт или специализированные утилиты. Заложите на переезд выходные и предупредите людей заранее.

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

Когда свой почтовый сервер не нужен

Честный список ситуаций, где своё решение принесёт больше хлопот, чем пользы:

• ящиков меньше 20-30 и своего админа нет - обслуживать почту некому, а стоимость простоя выше экономии на тарифе;
• нет статического белого IP с PTR-записью - доставляемость будет плохой независимо от качества настройки;
• некому реагировать ночью: почта лежит - бизнес стоит, и без дежурства риск разумнее отдать провайдеру;
• компания уже живёт в чужой экосистеме - когда календари, документы и звонки в Яндекс 360 или VK WorkSpace, вынимать оттуда одну почту значит ломать связки ради принципа;
• регулятор не обязывает хранить переписку на своей площадке, а данные не чувствительные - тогда главный аргумент за своё железо отпадает.

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

Что в итоге

Почтовый веб-сервер - инфраструктура, которая требует времени на запуск и внимания в эксплуатации. Взамен вы получаете контроль над доставляемостью писем, безопасностью данных и возможность настроить всё под свои задачи.

Кому-то достаточно облачного сервиса: быстро, просто, без головной боли. Для других свой сервер - вопрос не удобства, а необходимости: требования регуляторов, объёмы трафика, интеграция с внутренними системами. Выбор зависит от масштаба компании и от того, насколько критична почта для бизнеса. Но если решение принято в пользу своего сервера, оно окупается и долгосрочной экономией, и независимостью от внешних провайдеров.

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

Какой почтовый сервер выбрать для корпоративной почты?

Под Linux рабочий стандарт - Postfix для отправки и Dovecot для хранения, с веб-интерфейсом Roundcube. Если админ один и времени мало, берите готовую сборку (Mailcow, iRedMail). Если нужны реестр отечественного ПО и поддержка по договору - TEGU, RuPost или МойОфис Почта.

Нужен ли почтовому серверу веб-интерфейс?

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

Сколько стоит свой почтовый сервер на 100 человек?

Разовые вложения в сервер плюс работа администратора. Сравнивать надо с подпиской: 100 ящиков в российских облаках обойдутся примерно в 21-55 тыс. ₽ в месяц в зависимости от тарифа. Если админ уже в штате, своё железо на таком объёме обычно отбивается за пару лет.

Можно ли поднять почтовый сервер на VPS?

Можно, до полусотни ящиков это нормальный вариант. Два условия: провайдер должен открывать 25-й порт на исходящие и давать PTR-запись под ваш домен. Ещё стоит проверить IP-адрес по чёрным спискам до покупки.

Какие порты нужны для почтового сервера?

25 - для обмена между серверами, 587 и 465 - для отправки писем сотрудниками, 143 и 993 - для IMAP, 110 и 995 - для POP3. Вторые номера в парах - это варианты с TLS.

Почему письма уходят в спам, хотя сервер работает?

Почти всегда дело в трёх вещах: не настроены SPF, DKIM и DMARC; PTR-запись не совпадает с именем сервера; IP-адрес попал в чёрные списки из-за прошлых владельцев. Начинать проверку стоит именно с этого, а не с конфигурации Postfix.