Как настроить почту на своем домене и поставить Roundcube
Когда сервис доменной почты меняет правила доступа к IMAP, SMTP или POP3, внезапно выясняется, что почтовый клиент, сайт, CRM и пара служебных ботов завязаны на чужой тарифный переключатель.
Можно просто оплатить новый тариф. Иногда это нормальный вариант. Но если хочется контролировать почту на своем домене, можно перенести ее на собственный сервер и поднять веб-почту через Roundcube.
Только без сказок про "поставил за 15 минут и забыл". Своя почта — это не просто еще один сайт на VPS. Тут важны DNS, репутация IP, TLS, DKIM, бэкапы и аккуратная настройка отправки. Иначе письма будут либо не доходить, либо жить в спаме.
Из чего состоит почта на своем сервере
Минимальный понятный стек выглядит так:
- Postfix принимает и отправляет письма по SMTP.
- Dovecot хранит ящики и отдает почту по IMAP или POP3.
- OpenDKIM подписывает исходящие письма DKIM-подписью.
- DNS-записи объясняют миру, какой сервер имеет право отправлять почту от домена.
- TLS-сертификат защищает подключение клиентов и веб-почты.
- Roundcube дает нормальный веб-интерфейс в браузере.
Roundcube здесь важно понимать правильно. Это не почтовый сервер. Это веб-клиент, который подключается к вашему IMAP и SMTP. Если Postfix и Dovecot настроены криво, Roundcube не спасет. Он просто красиво покажет, что все криво.
Что проверить до установки
Я бы не начинал настройку, пока не проверены базовые вещи:
- у VDS есть статический IPv4
- провайдер не блокирует исходящий порт 25
- можно прописать reverse DNS / PTR на
mail.example.ru - домен управляется через нормальную DNS-панель
- сервер не стоит на домашнем интернете или случайном сером IP
- на сервере есть бэкапы
- понятно, кто будет обновлять систему и смотреть логи
Если IP уже в спам-листах или у провайдера плохая почтовая репутация, настройка может быть технически правильной, но письма все равно будут страдать. Почта довольно злопамятная штука. Интернет многое забывает, но плохие SMTP-соседи — не всегда.
Если не хочется руками собирать Postfix и Dovecot
Ручная настройка полезна тем, что вы понимаете каждый слой. Но не всем нужно становиться почтовым археологом ради пары доменных ящиков. Есть три нормальных направления.
Готовые self-hosted комплекты
Если хочется оставить контроль у себя, но не собирать все из отдельных деталей, можно смотреть в сторону готовых серверов:
- Mox — современный all-in-one сервер: SMTP, IMAP, SPF, DKIM, DMARC, MTA-STS, DANE, автоматический TLS, автоконфигурация клиентов и webmail. Хороший кандидат, если нужен более цельный стек без Postfix/Dovecot-комбайна.
- Stalwart — более широкая платформа: JMAP, IMAP, POP3, SMTP, CalDAV, CardDAV, WebDAV, админка, антиспам и автоматический TLS. Это уже не просто "ящик на домене", а почтово-коллаборативный сервер.
- mailcow — Docker-комплект на знакомых компонентах: Postfix, Dovecot, SOGo, Rspamd, MariaDB, Redis, Nginx и прочее. Удобен, если нужны ящики, алиасы, DKIM, веб-интерфейс и управление из UI, но нужно быть готовым поддерживать набор контейнеров.
- Postal — не замена обычному почтовому ящику, а self-hosted платформа для доставки писем от сайтов и приложений. Это ближе к своей версии SendGrid, Mailgun или Postmark для транзакционных писем.
Еще бывают скрипты "поставить почтовый сервер одной командой". Я бы относился к ним спокойно, но без религии: перед запуском от root надо читать, что именно скрипт меняет, какие порты открывает, где хранит ключи и как потом обновляется. Иначе вместо экономии времени можно получить черный ящик, который страшно трогать.
Сторонние сервисы без своего SMTP
Если задача не в контроле, а в том, чтобы почта просто работала, свой сервер может быть лишней операционкой.
Варианты:
- платная доменная почта у нормального провайдера, если нужны ящики, календарь, мобильные клиенты и поддержка
- обычный хостинг с почтой, если проект маленький и нагрузка простая
- Cloudflare Email Service для входящей маршрутизации и транзакционной отправки из Workers/API/SMTP, когда почта нужна как часть приложения
- Mailtrap или похожие сервисы для транзакционных писем через API/SMTP, аналитики и проверки доставляемости
Это не всегда дешевле на длинной дистанции, зато часто дешевле по нервам. Особенно если у проекта нет человека, который умеет ночью читать mail.log без желания сменить профессию.
Гибридный подход
Можно разделить задачи:
- обычные ящики держать у провайдера или в self-hosted решении
- письма от сайта, CRM и ботов отправлять через отдельный SMTP/API-сервис
- в коде иметь очередь, ретраи и переключение между провайдерами
Библиотеки и собственные адаптеры для нескольких провайдеров полезны именно для исходящих писем из приложения. Они не заменяют IMAP-ящик, MX-записи и нормальную доменную почту. Это не "почтовый сервер в npm-пакете", а слой отправки.
Главная мысль простая: выбирайте не самый модный вариант, а тот, который кто-то сможет поддерживать через год.
Базовый порядок настройки
Ниже не универсальный copy-paste для любого сервера, а нормальная последовательность работ. На практике детали зависят от Debian, Ubuntu, панели, Docker-стека и способа хранения пользователей.
1. Подготовить сервер и имя
Для почты лучше сразу использовать отдельное имя:
mail.example.ru
На сервере выставляется hostname:
hostnamectl set-hostname mail.example.ru
Дальше ставится базовый набор:
apt update
apt install postfix dovecot-core dovecot-imapd dovecot-lmtpd opendkim opendkim-tools certbot nginx mariadb-server php-fpm php-mysql php-xml php-mbstring php-intl php-zip php-curl
Для одного небольшого домена можно начать с системных пользователей и Maildir. Для нескольких доменов, десятков ящиков и нормального администрирования лучше сразу делать виртуальных пользователей в базе. Но я бы не начинал с самодельной "суперплатформы". Сначала один понятный рабочий домен, потом расширение.
2. Настроить Postfix
Postfix должен делать три вещи:
- принимать письма для вашего домена
- отправлять письма наружу
- не быть открытым релеем для всего интернета
В конфигурации обычно задаются:
myhostname = mail.example.ru
mydomain = example.ru
myorigin = $mydomain
inet_interfaces = all
home_mailbox = Maildir/
Самое важное — не разрешить отправку всем подряд. Для исходящей почты от пользователей нужен submission-порт 587 с авторизацией через Dovecot SASL. Порт 25 остается для обмена между почтовыми серверами.
Логика простая:
- серверы снаружи стучатся на
25 - ваши пользователи и боты отправляют через
587 - авторизация обязательна
- TLS обязателен
reject_unauth_destinationдолжен быть включен, чтобы сервер не превратился в спам-пушку
3. Настроить Dovecot
Dovecot отвечает за IMAP и хранение почты. Для простого старта обычно хватает Maildir:
mail_location = maildir:~/Maildir
ssl = required
Также Dovecot может отдавать Postfix сокет авторизации, чтобы один и тот же логин-пароль работал для IMAP и SMTP submission. Это удобнее, чем разводить две разные системы доступа.
Если POP3 не нужен, я бы не включал его просто "чтобы было". IMAP почти всегда удобнее: письма остаются на сервере, клиенты синхронизируются нормально, Roundcube работает поверх той же логики.
4. Выпустить TLS-сертификат
Для mail.example.ru нужен сертификат. Чаще всего достаточно Let's Encrypt:
certbot certonly --nginx -d mail.example.ru
Потом Postfix и Dovecot должны смотреть на эти файлы:
/etc/letsencrypt/live/mail.example.ru/fullchain.pem
/etc/letsencrypt/live/mail.example.ru/privkey.pem
Без TLS не надо подключать почтовые клиенты и ботов. Отправлять пароль к почте по голому соединению — это уже не минимализм, а бытовая диверсия.
DNS: место, где чаще всего все ломают
Почтовый сервер без правильных DNS-записей будет выглядеть подозрительно. Минимальный набор такой:
mail A 203.0.113.10
@ MX 10 mail.example.ru.
@ TXT "v=spf1 mx ~all"
_dmarc TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.ru"
selector._domainkey TXT "v=DKIM1; k=rsa; p=..."
Отдельно у провайдера VDS нужно прописать PTR:
203.0.113.10 -> mail.example.ru
SPF говорит, какие серверы могут отправлять почту от домена. DKIM подписывает письма ключом домена. DMARC объясняет получателям, что делать с письмами, которые не проходят SPF или DKIM.
На старте можно оставить SPF с ~all, чтобы мягко протестировать доставку. Когда все проверено, можно ужесточить до -all.
DKIM лучше не откладывать
DKIM — не украшение и не "потом прикрутим". Без него письма от нового сервера часто выглядят слабее для получателей.
Типовой порядок такой:
- Создать DKIM-ключ для домена.
- Подключить OpenDKIM к Postfix через milter.
- Опубликовать публичный ключ в DNS.
- Проверить, что исходящее письмо реально содержит DKIM-подпись.
Если доменов несколько, у каждого домена должен быть свой ключ или аккуратно настроенная таблица ключей. Вот тут уже начинается та самая админская скука, которая дешевле потери писем.
Установка Roundcube
Roundcube ставится только после того, как IMAP и SMTP уже работают. Иначе вы будете отлаживать сразу три слоя и не понимать, кто именно виноват.
Установка обычно состоит из таких шагов:
- Поставить nginx, PHP-FPM и MariaDB или PostgreSQL.
- Скачать Roundcube из официального релиза или поставить пакет из репозитория дистрибутива.
- Создать базу данных для Roundcube.
- Настроить подключение к IMAP и SMTP.
- Закрыть установщик после настройки.
- Открывать веб-почту только по HTTPS.
В актуальных версиях Roundcube базовые параметры выглядят примерно так:
$config['imap_host'] = 'ssl://mail.example.ru';
$config['smtp_host'] = 'tls://mail.example.ru';
$config['smtp_user'] = '%u';
$config['smtp_pass'] = '%p';
После установки обязательно убрать или закрыть installer. Оставленный установщик на боевом сервере — это не удобство, а приглашение на неприятный вечер.
Официальные точки входа:
Как переносить ящики
Перенос лучше делать до переключения MX.
Порядок такой:
- Создать ящики на новом сервере.
- Скопировать старую почту через IMAP.
- Проверить вход через Roundcube и обычный почтовый клиент.
- Проверить отправку наружу и прием снаружи.
- Понизить TTL DNS-записей заранее.
- Переключить MX на новый сервер.
- Несколько дней смотреть логи старого и нового сервера.
Для переноса писем часто используют imapsync. Это скучный, но рабочий инструмент: подключается к старому IMAP, подключается к новому IMAP и переносит папки с письмами. Главное — сначала прогнать один тестовый ящик, а не героически мигрировать все ночью.
Что проверить после запуска
Минимальный чеклист:
- входящие письма доходят с Gmail, Яндекс, Mail.ru и корпоративных ящиков
- исходящие письма не падают в спам
- DKIM-подпись есть в заголовках письма
- SPF и DMARC проходят проверку
- PTR совпадает с именем почтового сервера
- Roundcube открывается только по HTTPS
- submission
587требует авторизацию - сервер не принимает письма на чужие домены без авторизации
- логи Postfix и Dovecot понятны, а не полны красного фольклора
- бэкап ящиков реально восстанавливается
Последний пункт неприятный, но важный. Бэкап, который ни разу не восстанавливали, — это не бэкап, а психологическая поддержка.
Где легко ошибиться
Чаще всего проблемы появляются не в момент установки пакетов, а вокруг эксплуатации:
- забыли PTR
- не настроили DKIM
- сделали открытый relay
- отправляют рассылки с нового IP и удивляются спаму
- оставили слабые пароли
- открыли Roundcube без 2FA, fail2ban и ограничений
- не смотрят очередь Postfix
- не делают бэкапы Maildir и базы Roundcube
- держат почту и экспериментальные сайты на одном сервере без понимания рисков
Свой почтовый сервер — это контроль, но не бесплатный обед. Вы перестаете зависеть от чужого тарифного решения, зато начинаете отвечать за доставляемость, обновления и безопасность.
Когда свой сервер действительно имеет смысл
Я бы рассматривал свой почтовый сервер, если:
- есть доменная почта для сайта, CRM и служебных уведомлений
- нужны стабильные IMAP и SMTP без привязки к тарифу SaaS-сервиса
- есть человек, который умеет читать логи и обновлять сервер
- объем почты небольшой и не похож на массовую рассылку
- важно держать почту, сайты, базы и бэкапы в одной понятной инфраструктуре
Если нужна большая корпоративная почта с календарями, мобильными политиками, DLP, SSO и юридически чувствительной перепиской, я бы десять раз подумал. Самосборный Postfix не становится корпоративной платформой только потому, что мы положили рядом Roundcube.
Вывод
Настроить почту на своем домене можно без рекламы конкретной панели. Рабочая схема простая: VDS с нормальным IP, Postfix, Dovecot, DKIM, корректные DNS-записи, TLS и Roundcube как веб-интерфейс.
Но простая схема не значит безответственная. Почта держится на мелочах: PTR, SPF, DKIM, DMARC, закрытый relay, нормальные пароли, логи, бэкапы и аккуратная миграция.
Если все это сделать спокойно, почтовый клиент продолжит получать письма, бот продолжит отправлять уведомления, а домен перестанет зависеть от того, кому и когда пришло в голову переставить IMAP/SMTP в платный тариф.