Свой почтовый сервер на VPS: Postfix и Dovecot с нуля

Почему self-hosting почты сложнее, чем кажется

Поднять почтовый сервер технически несложно — установка Postfix и Dovecot на чистый VPS занимает от силы пару часов даже для человека, который делает это впервые. Настоящая сложность self-hosting почты не в установке, а в том, что происходит после: получении и удержании хорошей репутации отправителя в глазах крупных почтовых провайдеров, которые принимают решение о доставке каждого письма на основе множества факторов, зачастую невидимых со стороны отправителя.

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

Распространённое наблюдение при первом знакомстве с self-hosted почтой

Крупные почтовые провайдеры (Gmail, Mail.ru, Yandex, Outlook) применяют десятки сигналов при решении, доверять ли письму от незнакомого сервера: репутацию IP-адреса, наличие и корректность записей SPF, DKIM и DMARC, соответствие обратной DNS-зоны, историю предыдущих рассылок с этого же IP, скорость отправки и множество менее очевидных технических деталей заголовков письма. Пропуск любого из базовых требований почти гарантированно приводит к тому, что письма либо попадают в спам, либо отклоняются вовсе без уведомления отправителя о реальной причине.

Эта статья пошагово разбирает установку Postfix в роли MTA и Dovecot в роли сервера IMAP/POP3 на VPS, необходимые предварительные настройки DNS и записи аутентификации почты, TLS для защищённого подключения, а в конце — честно отвечает на вопрос, когда self-hosting почты действительно оправдан, а когда пragматичнее воспользоваться готовым сервисом.

Обратная DNS-зона (rDNS/PTR): фундамент доверия к серверу

Прежде чем настраивать сам почтовый сервер, нужно решить один вопрос на уровне DNS, без которого дальнейшая настройка не имеет практического смысла, — обратную DNS-зону, также называемую PTR-записью. Обычная A-запись сопоставляет доменное имя с IP-адресом; PTR-запись работает в обратную сторону: по IP-адресу она возвращает доменное имя, которое, по идее, этому IP принадлежит.

Большинство почтовых серверов при получении письма проверяют, что PTR-запись IP-адреса отправителя действительно резолвится в доменное имя, а это имя, в свою очередь, соответствует тому, что сервер представил в команде HELO/EHLO при установке SMTP-соединения. Несовпадение или полное отсутствие PTR-записи — один из самых сильных сигналов для спам-фильтров, поскольку легитимные почтовые серверы почти всегда имеют корректно настроенную обратную зону, а массовые спам-рассылки часто идут с временных или скомпрометированных серверов без такой настройки.

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

Дополнительно стоит убедиться, что имя в PTR-записи совпадает с тем, что настроено в самом Postfix как myhostname, — рассинхронизация между этими двумя значениями снова создаёт то же самое несовпадение, которое проверяют почтовые фильтры, даже если формально обратная зона настроена и указывает хоть на какое-то доменное имя.

SPF, DKIM и DMARC — не опция, а обязательное требование

Если rDNS подтверждает легитимность самого сервера-отправителя на уровне IP-адреса, то SPF, DKIM и DMARC подтверждают легитимность конкретного письма на уровне домена, от имени которого оно отправлено. Все три механизма работают вместе и дополняют друг друга, а не заменяют один другой.

SPF (Sender Policy Framework) — TXT-запись в DNS-зоне домена, которая перечисляет, каким серверам разрешено отправлять письма от имени этого домена. DKIM (DomainKeys Identified Mail) добавляет к каждому исходящему письму криптографическую подпись, которую принимающий сервер проверяет через открытый ключ, опубликованный в DNS, — это подтверждает, что содержимое письма не было изменено по пути и действительно отправлено владельцем приватного ключа. DMARC связывает SPF и DKIM в единую политику и явно указывает принимающим серверам, что делать с письмами, не прошедшими эти проверки.

Начиная с 2024 года крупнейшие почтовые провайдеры официально требуют настроенные SPF и DKIM даже от отправителей с небольшим объёмом писем — это уже не рекомендация для энтузиастов, а формальное техническое требование индустрии.

Изменение политики крупных почтовых провайдеров в отношении массовых и не только рассылок

Настройка Postfix для подписи писем через DKIM обычно выполняется через отдельный демон OpenDKIM, интегрированный с Postfix через milter-интерфейс — это отдельный процесс конфигурации, требующий генерации пары ключей, публикации открытого ключа в DNS-записи и настройки Postfix на передачу исходящей почты через этот демон перед фактической отправкой. Подробный разбор настройки всех трёх механизмов — в отдельной статье базы знаний, посвящённой именно SPF, DKIM и DMARC.

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

Postfix: приём и отправка почты по SMTP

Postfix — это MTA (Mail Transfer Agent), программа, отвечающая за приём входящих писем по протоколу SMTP от других почтовых серверов и за отправку исходящих писем на серверы получателей. Это именно тот компонент, который делает возможной саму передачу писем между разными доменами и серверами в интернете.

apt update
apt install postfix -y

В процессе установки инсталлятор предложит выбрать общий тип конфигурации — для полноценного почтового сервера, принимающего почту из интернета, стоит выбрать вариант Internet Site и указать основное доменное имя сервера, от которого он будет представляться другим серверам.

myhostname = mail.example.ru
mydomain = example.ru
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
inet_interfaces = all
home_mailbox = Maildir/

Параметр myhostname задаёт полное доменное имя сервера, которое должно совпадать с тем, что настроено в rDNS. mydestination перечисляет домены, для которых этот сервер считается конечным получателем почты (то есть входящие письма для этих доменов доставляются локально, а не пересылаются дальше). home_mailbox = Maildir/ указывает формат хранения писем каждого пользователя — Maildir хранит каждое письмо отдельным файлом в структуре директорий, что надёжнее и удобнее для параллельного доступа, чем более старый формат mbox, хранящий все письма ящика в одном большом файле.

Dovecot: доступ пользователей к почте по IMAP и POP3

Dovecot решает другую задачу — предоставляет пользователям доступ к уже полученным письмам через протоколы IMAP или POP3 из обычного почтового клиента (Thunderbird, Outlook, приложение на телефоне). Postfix кладёт полученные письма в почтовый ящик на диске, а Dovecot читает их оттуда по запросу конкретного пользователя, аутентифицированного своим логином и паролем.

apt install dovecot-imapd dovecot-pop3d -y

mail_location = maildir:~/Maildir
ssl = required
ssl_cert = </etc/letsencrypt/live/mail.example.ru/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.example.ru/privkey.pem

Параметр mail_location должен соответствовать формату хранения писем, заданному в конфигурации Postfix (в данном случае Maildir), иначе Dovecot не найдёт письма, доставленные Postfix, или найдёт их в неверном формате. Связка ssl = required заставляет Dovecot принимать только зашифрованные подключения, что обязательно для защиты паролей пользователей и содержимого писем при передаче между почтовым клиентом и сервером через открытые сети вроде публичного Wi-Fi.

Postfix и Dovecot взаимодействуют друг с другом через два дополнительных механизма: SASL-аутентификацию, которую Postfix использует для проверки логина и пароля отправителя перед приёмом исходящей почты от авторизованного пользователя (а не только от других почтовых серверов), и, в более сложных конфигурациях, протокол LMTP для передачи входящей почты от Postfix напрямую в Dovecot вместо прямой записи в файловую систему.

TLS для почты: шифрование на всех протоколах

Почтовые протоколы используют несколько разных портов в зависимости от задачи и способа шифрования: порт 25 — приём почты от других серверов (SMTP), порт 587 — отправка почты от авторизованных пользователей через почтовый клиент (submission, с шифрованием STARTTLS), порт 465 — отправка с немедленным TLS-шифрованием при установке соединения (SMTPS), порты 993 и 995 — защищённые IMAP и POP3 соответственно.

certbot certonly --standalone -d mail.example.ru
crontab -l | grep certbot

Сертификат Let's Encrypt подходит для почтового сервера точно так же, как и для обычного сайта, — важно только, чтобы доменное имя в сертификате совпадало с именем, которое сервер использует при представлении в TLS-соединении (обычно то же значение, что в myhostname Postfix). Подробный разбор получения и настройки сертификата разобран в отдельной статье базы знаний.

smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.ru/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.ru/privkey.pem
smtpd_tls_security_level = may
smtpd_use_tls = yes
submission inet n - y - - smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt

Значение smtpd_tls_security_level = may для основного порта 25 означает, что шифрование предлагается, но не требуется в обязательном порядке — это сделано намеренно, поскольку многие другие почтовые серверы в интернете по историческим причинам всё ещё не поддерживают TLS на этом порту, и требование обязательного шифрования здесь заблокировало бы приём легитимной почты от части отправителей. Для порта submission (587), где подключаются только доверенные авторизованные пользователи, разумно требовать шифрование в обязательном порядке.

Проблема заблокированного 25 порта у хостинг-провайдеров

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

Разблокировка исходящего 25 порта обычно требует отдельного обращения в техподдержку с указанием конкретной цели использования — планов запустить собственный почтовый сервер под конкретный домен. Это разумная практика с точки зрения провайдера: явный запрос с указанием цели позволяет отследить владельца сервера в случае последующих проблем со спамом и одновременно отсеивает значительную часть автоматизированных ботов, которые просто пытаются использовать случайно полученный доступ к VPS для массовой рассылки.

Стоит учитывать этот шаг заранее при планировании запуска почтового сервера — если запрос на разблокировку обрабатывается не мгновенно, вся остальная настройка Postfix и Dovecot может быть полностью готова, но реальная отправка почты во внешний мир не заработает до завершения этого административного шага.

Проверка результата и типичные проблемы с доставляемостью

После завершения базовой настройки стоит проверить результат специализированными онлайн-инструментами вроде mail-tester.com, которые отправляют письмо через настроенный сервер на специальный тестовый адрес и возвращают подробный отчёт: проходит ли письмо проверки SPF, DKIM и DMARC, корректна ли обратная DNS-зона, не находится ли IP-адрес сервера в известных чёрных списках (RBL).

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

Скорость и объём первой рассылки с нового сервера также имеет значение — резкий скачок объёма исходящей почты со свежего, ещё не имеющего репутации IP-адреса воспринимается почтовыми фильтрами с большей подозрительностью, чем постепенное наращивание объёма (практика, называемая IP warm-up), даже если всё содержимое писем полностью легитимно.

Когда self-hosting почты действительно оправдан

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

Для типичного бизнеса, которому просто нужна корпоративная почта вида имя@company.ru для сотрудников, self-hosting почти всегда проигрывает по совокупности затрат готовому managed-сервису — Яндекс 360, Google Workspace или аналогичным решениям. Managed-сервис уже решил вопросы репутации IP, антиспам-фильтрации, защиты от компрометации ящиков и резервного копирования писем на своей стороне, тогда как self-hosting перекладывает всю эту постоянную, не разовую работу на владельца сервера.

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

Практический вывод из опыта эксплуатации self-hosted почтовых серверов

Честная оценка трудозатрат — хороший ориентир для решения: если специалист, способный поддерживать почтовый сервер на постоянной основе, уже есть в команде и email действительно важен как часть продукта, self-hosting оправдан; если задача — просто дать сотрудникам почтовый адрес на корпоративном домене без специфичных технических требований, время и риски self-hosting почти никогда не окупаются экономией на подписке managed-сервиса.

Чек-лист запуска собственного почтового сервера

Шаг 1. Настройте корректную PTR-запись (обратную DNS-зону) для IP-адреса сервера через панель хостинг-провайдера, убедившись, что она совпадает с myhostname в конфигурации Postfix.

Шаг 2. Настройте SPF, DKIM и DMARC записи в DNS-зоне домена до начала реальной отправки писем, а не после первых проблем с доставляемостью.

Шаг 3. Запросите разблокировку исходящего 25 порта у хостинг-провайдера заранее, с указанием конкретной цели использования.

Шаг 4. Установите и настройте Postfix с форматом хранения Maildir и Dovecot для доступа пользователей по IMAP/POP3, синхронизировав параметры формата почтового ящика между обоими компонентами.

Шаг 5. Получите TLS-сертификат для доменного имени почтового сервера и настройте шифрование для всех используемых портов — обязательное для submission и IMAP/POP3, опциональное для основного 25 порта.

Шаг 6. Проверьте результат через mail-tester.com и убедитесь, что IP-адрес сервера отсутствует в основных чёрных списках, прежде чем переходить к реальной эксплуатации.

Итог: осознанный выбор между контролем и удобством

Собственный почтовый сервер на Postfix и Dovecot даёт полный контроль над почтовой инфраструктурой, но требует заметно больше постоянного внимания, чем однократная настройка, — репутация IP-адреса, чёрные списки, актуальность SPF/DKIM/DMARC под меняющиеся требования почтовых провайдеров нуждаются в регулярном присмотре на протяжении всего срока эксплуатации сервера, а не только на этапе первичной настройки.

Для проекта, где email — часть основного продукта, эти трудозатраты оправданы полным контролем над инфраструктурой; для типичного бизнеса, которому нужна просто рабочая корпоративная почта, managed-сервис почти всегда оказывается более рациональным выбором по совокупности затрат времени и рисков. Если нужна помощь с настройкой почтового сервера на своём VPS или подбором конфигурации под ожидаемый объём почты — опишите задачу в заявке внизу страницы.

Независимо от выбранного пути, три вещи остаются обязательными в любом сценарии: корректная обратная DNS-зона, настроенные SPF/DKIM/DMARC записи и TLS-шифрование для передачи писем — без них доставляемость почты будет страдать вне зависимости от того, насколько аккуратно настроены сами Postfix и Dovecot на техническом уровне.