5 почтовых серверов: чеклист оценки параметров перед запуском

Причина обычно находится в сетевом контуре: VPS-провайдер блокирует исходящий порт 25, PTR не соответствует имени узла, а DNS-записи обслуживаются через не тот панельный интерфейс.

Выбор между Postfix, Exim, Zimbra, Mailcow и iRedMail имеет смысл только после проверки инфраструктуры. Все пять решений работают с почтой, но закрывают разные задачи и требуют разной эксплуатации. Сначала определите архитектуру, затем проверьте сеть, DNS, аутентификацию и ресурсы. Только после этого переключайте домен на новый сервер.

Сначала подтвердите доступность порта 25 и управление PTR. Установка MTA поверх неподготовленного VPS лишь переносит сетевой отказ в очередь повторной отправки.

1. Определите архитектуру пяти платформ

Под названием «почтовый сервер» здесь скрываются пять разных программных моделей. Postfix и Exim — узкоспециализированные MTA. Zimbra, Mailcow и iRedMail включают несколько компонентов почтовой системы.

Postfix и Exim

Postfix и Exim отвечают за маршрутизацию и передачу сообщений. Организация пользовательских ящиков, IMAP/POP3 и веб-доступа требует дополнительного ПО. Типовая связка включает Dovecot; веб-интерфейс можно реализовать отдельным приложением, например Roundcube.

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

Zimbra Collaboration Suite

Zimbra представляет собой тяжовесный Java-стек корпоративного уровня. В состав входят веб-клиент, календарь, контакты и инструменты совместной работы. Продукт распространяется в редакциях Open Source Edition и коммерческой Network Edition.

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

Mailcow

Mailcow разворачивается как набор Docker-контейнеров. В составе присутствуют Postfix, Dovecot, SOGo, Rspamd и другие компоненты. Модель подходит организациям, которым нужен готовый почтовый комплекс и предсказуемая структура контейнеров.

Проверяйте версию образов, постоянные тома, сетевые ограничения, обновление компонентов и процедуру восстановления. Заявленный системный минимум для стандартной конфигурации с ClamAV составляет 6 GiB RAM и 1 GiB swap. Это нижняя граница, а не запас под реальную нагрузку.

iRedMail

iRedMail устанавливает и настраивает традиционный стек Postfix, Dovecot, фильтрации спама и веб-панели непосредственно в ОС сервера. Решение поддерживает Rocky Linux, AlmaLinux, Debian, Ubuntu и системы BSD.

Такая модель даёт прямой контроль над хостом и сервисами. Одновременно администратор отвечает за обновления ОС, зависимости, firewall, резервные копии и совместимость пакетов. Проверяйте поддерживаемый релиз и наличие готовых пакетов в конкретном репозитории.

2. Проведите сетевой аудит до установки

Проверка начинается с провайдера и выделенного IP-адреса. Базовое инфраструктурное требование — один IPv4-адрес с возможностью назначения PTR. PTR изменяется владельцем обратной DNS-зоны. Обычная панель управления доменом не даёт полного контроля над ним.

Порты и их назначение

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

Локальная проверка показывает только состояние firewall внутри ОС:

ss -lntp

Для приёмки подключайтесь к серверу из другой сети:

nc -vz mail.example.net 25

nc -vz mail.example.net 587

nc -vz mail.example.net 465

nc -vz mail.example.net 993

nc -vz mail.example.net 995

Успешный TCP-connect означает доступность порта. Он не подтверждает корректную работу SMTP, TLS и аутентификации. Проверяйте их отдельно:

openssl s_client -starttls smtp -connect mail.example.net:587 -servername mail.example.net

openssl s_client -connect mail.example.net:465 -servername mail.example.net

openssl s_client -connect mail.example.net:993 -servername mail.example.net

Для 587 сервер должен объявить поддержку STARTTLS после EHLO. Для 465 и 993 TLS устанавливается сразу. Проверяйте цепочку сертификатов, имя узла и срок действия. Submission должен требовать авторизацию; порт 465 использует тот же контроль доступа на защищённом транспорте.

Проверка IP и прямой отправки

Проверьте исходящий маршрут до реального MX получателя:

dig +short MX recipient.example.org

nc -vz mx.recipient.example.org 25

Если соединение с внешним MX запрещено провайдером, MTA будет принимать письма и помещать их в очередь, но не сможет завершить доставку. Использование релея допустимо, если его использование разрешено архитектурой и политикой домена. Проверяйте релей отдельно: репутация адреса, доступность порта 25, TLS и обработка ошибок.

До переноса проверьте адрес в DNSBL/RBL. Общие адреса VPS иногда уже имеют негативную историю. Установка PTR и смена MX такую репутацию не отменяют. При обнаружении блокировки зафиксируйте состояние адреса и выполните процедуру устранения у оператора блок-листа.

3. Настройте MX, PTR и прямую DNS-зону

Записи DNS должны образовывать согласованную цепочку. MX ссылается на имя почтового узла. Имя разрешается в A или AAAA. PTR отображает адрес в то же FQDN. Сервер использует это FQDN в HELO/EHLO.

Базовый набор выглядит так:

• example.net MX 10 mail.example.net — маршрут входящей почты;
• mail.example.net A <IP> — адрес почтового узла;
• PTR для <IP> — mail.example.net.

MX нельзя задавать числовым IP-адресом. Целевое имя должно разрешаться через A или AAAA. При нескольких MX задайте приоритеты: меньшее числовое значение обозначает основной узел. Второй MX должен быть реально готов принимать почту и иметь собственные PTR, TLS и работающую политику аутентификации.

Проверяйте записи через публичный DNS:

dig +short MX example.net

dig +short A mail.example.net

dig +short -x <IP>

dig +short TXT example.net

Проверка из внутреннего resolver может дать другой ответ из-за split-horizon. Для приёмки используйте внешний публичный resolver и DNS-серверы, которыми пользуются получатели.

PTR и прямое разрешение

Для основного почтового IP проверьте обратное и прямое соответствие:

• PTR <IP> возвращает mail.example.net;
• mail.example.net возвращает тот же <IP>;
• hostname в HELO/EHLO совпадает с PTR;
• TLS-сертификат содержит это имя в SAN.

Не используйте для почтового IP без необходимости несколько несвязанных hostname. Обратная зона должна однозначно связывать адрес с узлом. Делегируйте PTR через провайдера, если тот владеет reverse zone. Передача зоны другому оператору не отменяет необходимость запроса на изменение PTR.

MX определяет только маршрутизацию входящего сообщения. Он не гарантирует помещение письма в папку «Входящие». Дальнейшую судьбу письма определяют репутация IP, аутентификация, содержимое,recipient policy и действия принимающего домена.

Перед переключением домена снизьте TTL в обслуживаемой зоне. После стабилизации и проверки очереди верните прежний TTL. Такой порядок сокращает время распространения изменений MX во время аварийного отката.

4. Соберите SPF, DKIM и DMARC

Серверные компоненты отвечают за приём, маршрутизацию и доставку. SPF, DKIM и DMARC связывают домен с авторизованными отправиками и формируют проверяемую политику доверия.

SPF: разрешите реальные источники отправки

Создайте одну TXT-запись SPF для домена. Она начинается с v=spf1. Укажите серверы и внешние службы, которые действительно отправляют почту от имени домена.

Учитывайте все легитимные источники:

• основной почтовый сервер;
• транзакционную почтовую платформу;
• CRM и сервис рассылок;
• мобильные приложения;
• сайты и формы, отправляющие письма через сторонний API.

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

SPF анализирует envelope sender и HELO/EHLO. Поле From: он не защищает. Даже успешный результат SPF не завершает проверку DMARC.

DKIM: подпишите исходящие сообщения

Для каждого отправителя создайте DKIM-ключ. Закрытый ключ разместите на системе, формирующей подпись. Открытый ключ опубликуйте в TXT-записи селектора:

selector._domainkey.example.net

Проверьте соответствие открытой части закрытому ключу и длину DNS-записи. Удаляйте устаревшие селекторы после перехода на новый ключ. Храните резервную копию закрытого ключа в системе управления секретами. Публикация закрытого ключа в DNS недопустима.

Подписывать нужно все легитимные источники. Передача почты через релей не отменяет DKIM: сервис проверяет подпись на момент пересылки и учитывает результат в DMARC.

DMARC: свяжите политику с видимым доменом

DMARC публикуется в TXT-записи _dmarc.example.net. Политика задаёт реакцию получателя при сбое проверок. Порядок внедрения обычно следующий:

1. p=none — собирать отчёты без блокировки.

2. quarantine — помещать сбойные сообщения в карантин на стороне получателя.

3. reject — отклонять сообщения, не прошедшие DMARC.

Повышайте строгость после проверки всех источников. Включите rua для получения агрегированных отчётов. Адрес отчётности должен принимать почту и не зависеть от того же сбоя, который выявляет DMARC.

DMARC требует согласованности результата с доменом в видимом From:. SPF может пройти проверку, но не пройти alignment. Аналогично DKIM может быть корректным, но подписан другим доменом. DMARC принимает сообщение при успешном aligned SPF либо aligned DKIM.

Аутентификация клиента на Submission остаётся отдельным обязательным слоем. SPF, DKIM и DMARC не подтверждают пароль отправителя на SMTP-порту.

Проверяйте результат из внешней точки. Локальный тест может использовать другой resolver, другой IP или другой путь отправки, чем реальный получатель.

5. Проверьте ресурсы, изоляцию и порядок приёмки

Системные требования

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

Для Mailcow заявленный минимум стандартной конфигурации с ClamAV — 6 GiB RAM и 1 GiB swap. Проверяйте конфигурацию под ожидаемый объём писем, одновременный доступ пользователей и объём антивирусного сканирования. Запас памяти должен оставаться после запуска всех контейнеров.

Zimbra использует тяжовесный Java-стек и хранит данные Groupware. Проводите нагрузочный тест на конфигурации, близкой к рабочей. iRedMail разворачивается непосредственно в ОС. Проверяйте свободное место, обновления пакетов, состояние firewall и совместимость версий компонентов.

Универсального норматива дискового пространства на пользователя нет. Расчёт учитывает почтовые ящики, вложения, журналы, карантин, резервные копии и временные файлы антивирусной проверки.

Контейнеры и постоянные данные

Для Mailcow проверяйте, что каталоги почты, конфигурация, базы данных, DKIM-ключи и сертификаты находятся в постоянных томах. Фиксация версий образа упрощает обновление и откат. Обновляйте компоненты по проверяемой процедуре, а не обновлением всех контейнеров одновременно.

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

• почтовые ящики и пользовательские данные;
• конфигурацию MTA, IMAP, антиспама и Groupware;
• базы данных;
• закрытые DKIM-ключи и TLS-сертификаты;
• постоянные тома Docker;
• правила firewall и DNS-конфигурацию.

Проверяйте восстановление в отдельный контур. Наличие backup-файла не подтверждает работоспособность архива.

Консольный порядок приёмки

1. Зафиксируйте требования. Определите роли пользователей, объём почты, необходимость Web UI, календарей, контактов, совместной работы, антивируса и антиспама. Назначьте каждой системе владельца и процедуру обновления.

2. Проверьте сеть извне. Убедитесь в доступности входящего TCP/25, исходящего маршрута к внешним MX, а также портов 465, 587, 993 и 995. Проверьте TLS и отказ при неверных credentials на Submission.

3. Опубликуйте DNS. Настройте A или AAAA для почтового узла, MX для домена и PTR для IP. Проверяйте ответы через публичный DNS. Убедитесь, что hostname сервера совпадает с PTR и сертификатом.

4. Разверните SPF, DKIM и DMARC. Сначала включите SPF и DKIM для каждого источника. Проверьте alignment и агрегированные отчёты DMARC. Переходите к quarantine и reject после исключения легитимных, но неподписанных отправителей.

5. Проведите полный тест. Отправьте письмо в другой домен, запросите входящее письмо, проверьте чтение через IMAPS, отправку через 465 и 587, вложения, автоматические ответы и уведомления о задержке.

6. Проверьте очередь и отказы. Имитируйте недоступный MX, переполнение диска и ошибку TLS. Убедитесь, что сообщения повторяются с корректными интервалами, ошибки читаемы, а очередь не растёт бесконтрольно.

7. Проверьте восстановление. Восстановите резервную копию в отдельное окружение. Проверьте доступ к ящикам, целостность DKIM-ключей и запуск Postfix, Dovecot, Rspamd, SOGo или компонентов Zimbra.

8. Переключайте MX поэтапно. Сначала переведите тестовый домен или небольшой поток. Следите за очередью, журналами, bounce rate, отчётами DMARC и задержками доставки. Переносите основной домен только после устойчивой работы.

Итог: Postfix и Exim дают контролируемую MTA-архитектуру, Mailcow — контейнерный комплекс, iRedMail — классический стек прямо в ОС, Zimbra — Groupware на Java. Решение о запуске принимайте по инфраструктурным признакам: доступный порт 25, корректный PTR, согласованные MX, рабочие SPF, DKIM и DMARC, защищённые клиентские порты и проверенное восстановление. Название программы не устранит сетевой, DNS- или репутационный сбой.