Настройка почтового сервера на собственной инфраструктуре предприятия строится вокруг двух базовых компонентов: агента пересылки почты (MTA) и сервера доступа по IMAP/POP3. Отдельным модулем добавляется защита от спама, а корректная доставка писем зависит еще и от настроек DNS-записей домена. Для IT-специалиста, который получил задачу развернуть почту вместо облачного сервиса, важна не только установка пакетов, но и последовательность действий: домен и DNS настраиваются раньше, чем запускается прием писем.
До установки нужно определить программный стек и конфигурацию сервера под ожидаемое число пользователей. Затем вы готовите доменную зону, правила доступа и резервное копирование, чтобы сервис был готов к приему реальной почты.
Зачем компании собственный почтовый сервер вместо облачной почты
Компании переходят на собственный почтовый сервер по двум основным причинам: из-за требований безопасности и ради контроля над данными. Хранение почты на собственной инфраструктуре снимает вопрос о том, где физически лежат письма с персональными данными сотрудников и клиентов — это существенно при обработке персональных данных по 152-ФЗ. Корпоративная почта в собственном контуре также позволяет компании самой определять сроки хранения и правила доступа.
Вторая причина — экономика. При большом числе почтовых ящиков, от 100–200 штук, лицензионные платежи за облачный сервис за 2–3 года часто превышают стоимость владения собственным сервером, особенно если оборудование уже используется под другие задачи. Дополнительный плюс — полный контроль над политиками хранения и резервного копирования без ограничений тарифного плана внешнего провайдера.
Выбор программного стека: MTA, IMAP/POP3 и антиспам
Базовый стек почтового сервера на Linux начинается с MTA — программы, которая принимает и пересылает письма между серверами. Для этой роли обычно выбирают Postfix или Exim.
За доступ пользователей к почтовым ящикам по IMAP или POP3 отвечает отдельный сервер, как правило, Dovecot. Он же обычно применяется для аутентификации пользователей при отправке писем через SMTP. Антиспам-фильтр — SpamAssassin или Rspamd, работает отдельным модулем: письмо сначала проходит через MTA, затем анализируется на признаки спама и фишинга и только после этого попадает в почтовый ящик.
Подготовка домена: MX, SPF, DKIM и DMARC
Для корректной доставки почты домен должен иметь запись MX, которая указывает, какой сервер принимает письма для этого домена. Без нее входящая почта не найдет сервер назначения.
Запись SPF перечисляет серверы, которым разрешено отправлять письма от имени домена — это защищает от подделки отправителя. DKIM добавляет к каждому исходящему письму цифровую подпись, которая подтверждает, что письмо не менялось в пути.
DMARC определяет, что делать с письмами, которые не прошли проверку SPF или DKIM: отклонять их или пропускать с пометкой о подозрительности. MX обеспечивает маршрутизацию входящих писем к серверу. SPF, DKIM и DMARC подтверждают отправителя и задают политику обработки сообщений, которые не прошли проверку. Ошибка в MX нарушает доставку, а отсутствие механизмов аутентификации повышает риск попадания исходящих писем в спам.
Настройка приема и отправки писем через SMTP
SMTP — протокол, который отвечает за прием почты между серверами и за отправку писем клиентами. Для приема писем от других почтовых серверов используется порт 25: именно на нем MTA принимает входящую корреспонденцию из интернета.
Для отправки писем почтовыми клиентами сотрудников используются порты 587 и 465 с TLS-шифрованием или STARTTLS. Разница между ними в способе установки шифрованного соединения: порт 465 включает TLS сразу при подключении, порт 587 переходит на шифрование через команду STARTTLS уже после установки соединения.
Также нужно настроить обратную DNS-запись (PTR) для IP-адреса сервера — она связывает IP-адрес с доменным именем сервера в обратном направлении. Без корректной PTR-записи крупные почтовые провайдеры массово отклоняют письма еще до проверки содержимого: сервер выглядит как источник спама.
Открытый релей — сервер, который пересылает почту для любого отправителя без проверки авторизации — частая причина, по которой сервер компании попадает в черный список IP или сразу в несколько репутационных баз. Аутентификация через Dovecot для отправки писем по портам 587 и 465 закрывает эту уязвимость: письмо на пересылку принимается только от авторизованного пользователя домена.
Защита почтового сервера от спама и фишинга
Базовый уровень защиты — набор DNS-записей домена, разобранный выше: он блокирует основную часть писем с подделанным отправителем еще до того, как антиспам-фильтр начнет анализировать содержимое. Второй уровень — сам фильтр, SpamAssassin или Rspamd, который оценивает письмо по десяткам признаков: репутации IP отправителя и характерным фразам в теле письма.
Дополнительно стоит подключить проверку по спам-листам (RBL) — открытым базам IP-адресов, замеченных в рассылке спама, и включить шифрование TLS 1.2/1.3 для SMTP и IMAP. Шифрование соединений снижает риск перехвата учетных данных при работе почтовых клиентов вне офисной сети — например, когда сотрудник подключается к почте с личного ноутбука через публичный Wi-Fi. Перед запуском такого сервера в эксплуатацию имеет смысл провести аудит безопасности инфраструктуры, чтобы проверить не только сам почтовый сервер, но и его окружение — сетевые правила и доступ извне.
Какая конфигурация сервера нужна под число ящиков
Расчет конфигурации сервера под почту отличается от расчета под файловый или веб-сервер: основная нагрузка приходится не на процессор, а на дисковые операции ввода-вывода и объем хранения писем с вложениями. Почтовый сервер для организации на 50–100 ящиков с умеренной нагрузкой обычно получает 4–8 ядер CPU и 16–32 ГБ оперативной памяти.
Под хранение вложений и почтовых баз предусмотрите SSD-массив от 500 ГБ. Точная емкость зависит от среднего размера вложений, срока хранения и параметра «квота ящика» для разных групп сотрудников. Ориентир для расчета — конфигурация сервера для почты на 200 ящиков: она показывает, сколько ядер и памяти закладывают под нагрузку такого масштаба, а также какой объем дискового пространства для этого требуется. Для организаций с числом ящиков за 200 расчет усложняется — растет нагрузка на дисковую подсистему и требования к резервному копированию.
При росте штата число ящиков и объем переписки увеличиваются не линейно: активные пользователи с большими вложениями создают нагрузку на диск заметно выше средней по компании. Конфигурацию стоит закладывать с запасом по дисковому пространству на 6–12 месяцев роста. Такой запас снижает риск срочного расширения массива сразу после запуска.
Резервное копирование и отказоустойчивость почтового сервера
Резервное копирование почты рекомендуется планировать независимо от резервного копирования файлового сервера — у почты другая частота изменений и другой суточный прирост данных. Ежедневный объем новых писем и вложений в почтовом ящике растет быстрее, чем в среднем файловом каталоге, поэтому расписание бэкапов и глубину хранения версий для почты настраивают отдельно.
Для сценариев, где простой почты недопустим даже на несколько часов, конфигурацию дополняют отказоустойчивым сервером с резервированием компонентов — это снижает риск простоя из-за отказа отдельного узла. Резервные копии почтовых баз стоит хранить на отдельном хранилище, физически отделенном от продуктивного сервера, чтобы авария или шифровальщик не затронули одновременно рабочую копию и бэкап.
Типичные ошибки при развертывании почтового сервера
Частая ошибка — запустить прием почты без настроенной PTR-записи: письма с такого сервера отклоняются или помечаются как спам без предупреждения, а разобраться в причине сложно постфактум. Вторая типичная ошибка — включить только SPF, но пропустить DKIM и DMARC: без полного набора записей защита от подделки отправителя работает лишь частично.
Третья ошибка — путать роли протоколов: настраивать прием и отправку почты через IMAP вместо SMTP, что технически не работает, поскольку за передачу писем между серверами отвечает именно SMTP. Миграция почты без тестового периода параллельной работы со старой системой увеличивает риск потери писем при переключении и усложняет откат. До изменения MX-записи проверьте прием и отправку на тестовом домене, а также подготовьте план возврата на прежний сервер.
Пошаговый порядок помогает не пропустить зависимые настройки. Сначала подготовьте сервер и доменную зону, затем установите MTA и сервис доступа к ящикам. После этого настройте SMTP, SPF, DKIM и DMARC, а перед переключением MX проверьте доставку и восстановление резервной копии. Такой чек-лист выявляет ошибки до переноса пользователей.
Если ресурсов на самостоятельную настройку и последующее сопровождение нет, имеет смысл привлечь интегратора для аудита безопасности перед запуском и подбора конфигурации сервера под ожидаемое число ящиков. Это снижает риск ошибок на старте, которые потом дорого исправлять на уже работающей системе.