Свой почтовый сервер: Postfix, Dovecot, DKIM, SPF, DMARC и что важно настроить
Старая инструкция «Postfix + Dovecot + MySQL + PostfixAdmin + Roundcube + DKIM на CentOS 8» больше не должна восприниматься как готовый рецепт. CentOS 8 снят с поддержки, а почтовый сервер — один из тех сервисов, где слепое копирование конфигурации особенно быстро приводит к open relay, утечке паролей или письмам в спаме.
Из каких компонентов состоит почтовая система
- Postfix принимает и отправляет SMTP-почту;
- Dovecot даёт пользователям IMAP/POP3 и может участвовать в SMTP AUTH;
- база пользователей нужна только если вы действительно храните виртуальные домены и аккаунты в SQL/LDAP;
- webmail вроде Roundcube — отдельное веб-приложение, а не часть SMTP;
- DKIM-подпись, SPF и DMARC отвечают за доверие к исходящей почте;
- антиспам и антивирус — отдельный слой, который нужно проектировать по нагрузке.
Начните с DNS, а не с пакетов
До запуска production-почты определите hostname сервера, A/AAAA, MX и PTR. Имя, которым SMTP-сервер представляется наружу, должно разрешаться предсказуемо. Без корректного reverse DNS даже идеально настроенный Postfix может иметь проблемы с доставляемостью.
TLS и submission
Пользовательские клиенты должны отправлять почту через аутентифицированный submission с TLS. Не превращайте порт 25 в универсальную точку входа для пользователей. Сертификаты должны автоматически продлеваться, а конфигурация — переживать renewal без ручного вмешательства.
SPF, DKIM и DMARC работают вместе
SPF указывает, какие серверы имеют право отправлять почту от домена. DKIM добавляет криптографическую подпись сообщения. DMARC задаёт политику обработки писем, которые не проходят проверки выравнивания. Начинайте DMARC с режима наблюдения и анализируйте отчёты, прежде чем переходить к жёсткому reject.
Не делайте open relay
Проверяйте, что анонимный клиент из интернета не может отправить письмо на произвольный внешний домен через ваш сервер. Relay разрешается только доверенным сетям, аутентифицированным пользователям и явно заданным сценариям.
Где хранить пользователей
Для нескольких локальных аккаунтов SQL может быть лишним. Для большого числа виртуальных доменов база или каталог удобнее. Выбирайте схему от требований, а не потому что она была в старой статье. Пароли храните только в подходящем hash-формате и не дублируйте их в открытых конфигурационных файлах.
Антиспам и ограничения
Нужны ограничения на аутентифицированную отправку, защита от перебора паролей, разумные message size limits и контроль очереди. Отдельно следите за взломанными аккаунтами: один пользовательский пароль может превратить сервер в источник тысяч исходящих сообщений.
Мониторинг
- размер и возраст очереди Postfix;
- ошибки доставки и bounce rate;
- authentication failures;
- срок TLS-сертификата;
- место на диске и inode;
- доступность SMTP submission и IMAP;
- репутацию IP и попадание в DNSBL.
Backup должен включать не только письма
Сохраняйте mailbox data, базу пользователей, конфигурации Postfix/Dovecot, DKIM private keys, webmail settings и список DNS-записей. Копия без приватного DKIM-ключа и схемы базы может сильно усложнить аварийное восстановление.
Итог: собственный почтовый сервер имеет смысл строить как систему из независимых слоёв и вводить в эксплуатацию только после проверки relay, TLS, DNS-аутентификации, backup и мониторинга. Это намного надёжнее старого «установите восемь пакетов и вставьте main.cf».
