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

Когда собственный почтовый сервер выгоднее облака

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

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

Пример расчёта для организации с 300 сотрудниками

Допустим, у компании 300 сотрудников, у каждого ящик на 50 ГБ. Суммарный объём хранения около 15 ТБ. При аренде выделенного сервера с нужными ресурсами ежемесячные расходы фиксированы и не зависят от количества пользователей. Добавить нового сотрудника стоит ровно ноль рублей дополнительно.

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

• в компании от 50 сотрудников и больше;
• каждому нужен большой почтовый ящик (20-50 ГБ);
• требуется долгосрочное хранение переписки;
• важен полный контроль над данными и доступами.

Кроме экономии, собственный сервер даёт независимость от тарифных изменений провайдеров, гибкие политики безопасности и соответствие внутренним регламентам по информационной безопасности.

Как рассчитать ресурсы под почтовый сервер

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

Процессор и оперативная память

Почтовый сервер с антиспамом и веб-интерфейсом комфортно работает от 4 ядер CPU. Для антиспам-фильтрации (особенно с нейросетевыми движками) нагрузка чувствительна к частоте ядер. Минимум оперативной памяти для связки Postfix + Dovecot + Rspamd + SOGo или Roundcube: 8 ГБ RAM. Для 300 пользователей с активной перепиской рекомендуется 16-32 ГБ.

Дисковое пространство

К объёму самой почты прибавляйте запас на индексы поиска (15-20% от объёма писем), временные файлы, резервные копии (минимум двойной объём) и рост переписки на 2-3 года вперёд. При 15 ТБ чистой почты реалистичный расчёт дискового пространства составит 40-50 ТБ с учётом резервных копий.

Сеть

Для корпоративной почты достаточно канала 100 Мбит/с. Важнее скорости сама репутация IP-адреса: на свежем или «грязном» адресе письма уходят в спам. Выделенный сервер с чистым IP-адресом решает эту проблему.

Где размещать почтовый сервер: три варианта

Выбор площадки определяет уровень контроля, стоимость и требования к IT-компетенциям команды.

Собственное оборудование

Максимальный контроль и независимость. Подходит компаниям, у которых уже есть серверный контур и IT-специалисты. Требует вложений в оборудование, UPS, каналы связи и берёт ответственность за бесперебойную работу на внутреннюю команду.

Аренда выделенного сервера

Компромиссный и самый популярный вариант для корпоративной почты. Хорошая производительность, чистый IP-адрес, предсказуемые расходы. Физическое оборудование обслуживает провайдер, а администрирование остаётся за вашей командой.

VPS (виртуальный сервер)

Дешевле и проще в масштабировании. Подходит для небольших и средних организаций или при старте. Требует внимательного выбора провайдера и тщательной настройки репутации IP. На плотно заселённом хосте соседи могут «засорить» общий IP, что негативно влияет на доставляемость писем.

Современная архитектура почтового сервера

Ещё несколько лет назад развернуть почтовый сервер означало вручную настроить десятки компонентов: SMTP, IMAP, веб-почту, антиспам, антивирус, TLS-сертификаты и логирование. Любая ошибка в конфигурации открывала уязвимость или ломала доставку.

Сегодня стандартом стала контейнерная архитектура. Все компоненты собраны в единый согласованный стек через Docker Compose. Установка занимает часы, а не недели. Обновление всей системы выполняется одной командой.

Компоненты стека

• Postfix: SMTP-сервер, приём и отправка почты;
• Dovecot: IMAP/POP3-сервер, хранение ящиков;
• Rspamd: антиспам с поддержкой DKIM-подписи;
• ClamAV: антивирусная проверка вложений;
• SOGo или Roundcube: веб-интерфейс и CardDAV/CalDAV;
• Nginx: обратный прокси с TLS-терминацией;
• MariaDB: хранение конфигурации и метаданных;
• Redis: кэш и очереди.

Решение Mailcowсобирает весь этот стек в готовый дистрибутив с удобной веб-панелью управления. Именно его чаще всего используют для корпоративного развертывания на Linux.

Установка Mailcow: основные шаги

Процесс установки состоит из четырёх этапов.

Подготовка сервера

Потребуется сервер с Ubuntu 22.04 или Debian 12, Docker и Docker Compose. Перед установкой нужно настроить PTR-запись (обратный DNS) у провайдера. Имя сервера в PTR должно совпадать с FQDN почтового сервера.

Клонирование и конфигурация

Репозиторий клонируется в /opt/mailcow-dockerized. Скрипт generate_config.shзадаёт hostname и спрашивает параметры Let's Encrypt. После генерации конфига правятся основные переменные: имя хоста, часовой пояс, при необходимости отключается автоматический выпуск сертификата, если TLS терминируется на балансировщике.

Запуск

Один вызов docker compose up -dподтягивает все образы и поднимает стек. Веб-панель доступна по HTTPS на 443 порту. Первичная настройка занимает несколько минут: создание домена, почтовых ящиков и паролей.

Проверка работоспособности

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

DNS, SPF, DKIM и DMARC: без них письма не дойдут

Настройка самого сервера это лишь половина работы. Вторая половина работы - корректные DNS-записи. Без них письма попадают в спам или не принимаются получателем вовсе.

MX-запись

Указывает, на какой сервер принимать почту для домена. Создаётся в DNS-зоне домена и должна указывать на FQDN почтового сервера, у которого есть совпадающая A-запись.

SPF

TXT-запись, которая перечисляет IP-адреса и серверы, имеющие право отправлять почту от имени домена. Принимающий сервер проверяет, откуда пришло письмо, и сверяет с SPF. Если IP не в списке, письмо помечается как подозрительное или отклоняется.

Пример записи SPF: v=spf1 ip4:203.0.113.5 -all

DKIM

Цифровая подпись исходящих писем. Mailcow через Rspamd автоматически генерирует пару ключей. Публичный ключ публикуется в DNS в TXT-записи вида mail._domainkey.example.com. Принимающий сервер верифицирует подпись и убеждается, что письмо не было изменено в пути.

DMARC

Политика, которая объединяет SPF и DKIM и указывает получателю, что делать с письмами, не прошедшими проверку. Настраивается постепенно: сначала p=noneдля мониторинга, затем p=quarantineили p=rejectдля реального применения.

Пример записи DMARC: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

Проверить корректность всех записей можно через публичные сервисы mail-tester.com или MXToolbox. Целевой результат теста в mail-tester: 10/10.

Антиспам и безопасность

Rspamd в составе Mailcow предоставляет многоуровневую фильтрацию: проверку репутации IP-адреса, анализ заголовков, байесовскую фильтрацию, проверку DNSBL-списков и поддержку автообучения на основе пользовательских действий (перенос в спам, обратно во входящие).

ClamAV сканирует вложения на вирусы. Интеграция с Rspamd позволяет блокировать заражённые письма до попадания в ящик.

Дополнительные меры

• Ограничение SMTP-аутентификации только по TLS;
• Принудительное требование STARTTLS для всех соединений;
• Fail2ban или аналогичные инструменты для блокировки перебора паролей;
• Двухфакторная аутентификация для веб-панели Mailcow;
• Ограничение административного доступа по IP.

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

Почта организации это критическим активом. Потеря переписки за несколько лет несёт репутационные и юридические риски. Резервное копирование решается на двух уровнях.

Встроенные инструменты Mailcow

Mailcow включает скрипт backup_and_restore.sh, который сохраняет конфигурацию, базу этих MariaDB и почтовые эти Dovecot. Резервная копия создаётся при остановленных контейнерах для консистентности данных. Восстановление выполняется той же утилитой.

Внешнее резервирование

Копии должны храниться на отдельном физическом сервере или в объектном хранилище. Рекомендуемое расписание: ежедневные инкрементальные копии, еженедельные полные с проверкой восстановления.

Доступ пользователей и почтовые клиенты

Mailcow поддерживает три способа доступа к почте:

1. Веб-интерфейс SOGo: полноценный группвер с общими календарями, контактами и задачами. Работает через браузер без установки клиентов.
2. IMAP/SMTP: подключение любого почтового клиента: Thunderbird, Outlook, Apple Mail. Настройка стандартная: IMAP на 993, SMTP на 465 или 587.
3. ActiveSync: синхронизация с мобильными устройствами на iOS и Android через протокол Exchange ActiveSync.

Миграция почты с облачных сервисов

Перенос переписки с Яндекс 360 или VK WorkSpace на собственный сервер выполняется через IMAP-миграцию. Инструмент imapsyncподключается к исходному и целевому серверам и копирует письма папку за папкой, сохраняя структуру, флаги и даты.

Рекомендуемый порядок миграции:

1. Перенести историческую переписку при активном облаке.
2. Переключить MX-запись на новый сервер.
3. Запустить финальную синхронизацию новых писем.
4. Перевести пользователей на новый сервер.
5. Отключить облачный сервис через 2-4 недели.

Масштабирование и пределы одного сервера

Один сервер с Mailcow комфортно обслуживает от нескольких десятков до 1000-1500 активных пользователей в зависимости от конфигурации оборудования и интенсивности переписки. При более высоких нагрузках архитектура разделяется: SMTP-шлюзы, IMAP-кластер на Dovecot Director и отдельное хранилище.

Для большинства организаций до 500 сотрудников одного правильно настроенного сервера достаточно на несколько лет вперёд. Важнее мощности заранее предусмотреть запас дискового пространства и возможность горячего расширения RAID-массива.

Итоги

Собственный почтовый сервер перестал быть уделом крупных корпораций с большими IT-отделами. Контейнерные решения вроде Mailcow снизили порог входа до уровня, доступного команде из одного-двух системных администраторов. При количестве сотрудников от 50 и выше такое решение чаще всего окупается в течение первого года за счёт разницы в стоимости облачных подписок.

главные шаги для успешного запуска: расчёт ресурсов с запасом, выбор площадки под задачи, корректная настройка DNS-записей (MX, SPF, DKIM, DMARC), включение антиспама и антивируса, организация резервного копирования с регулярной проверкой восстановления.