Как настроить веб-почту на своем сервере на Mox
29 июня Яндекс закрывает протоколы IMAP, SMTP и POP3 для пользователей без платного тарифа. Похожие ограничения VK WorkMail ввел с 12 июня.
Что это значит на практике:
- сторонние почтовые клиенты перестанут получать и отправлять почту;
- боты, CRM и сайты, которые отправляют письма через SMTP, могут просто замолчать;
- веб-интерфейс почтового сервиса останется, но автоматизация вокруг доменной почты сломается.
Можно заплатить за тариф и жить дальше. Иногда это самый дешевый вариант. Но если почта нужна не только как ящик в браузере, а как инфраструктура для сайта, админки, кодов входа и служебных уведомлений, я бы хотя бы посмотрел в сторону своего почтового сервера.
Один из самых адекватных вариантов сейчас — Mox. Это не связка из Postfix, Dovecot, OpenDKIM и Roundcube, которую надо собирать по кускам. Mox сразу дает SMTP, IMAP, webmail, админку, DKIM, SPF, DMARC, MTA-STS, TLS-RPT, автоконфигурацию клиентов и нормальные команды для проверки DNS.
Когда Mox подходит
Mox хорошо ложится на небольшой домен, где нужно:
- принимать почту на адресах вида
user@example.com; - отправлять служебные письма от сайта или админки;
- читать почту через браузер;
- подключать обычный почтовый клиент по IMAP и SMTP;
- не держать отдельный зоопарк из Postfix, Dovecot, Roundcube и антиспам-компонентов.
Это не значит, что свой сервер всегда выгоднее тарифа. У своей почты есть операционка: DNS, репутация IP, бэкапы, обновления, логи, доставляемость. Но если VDS уже есть, домен свой, писем немного, а зависимость от чужого SMTP раздражает, Mox выглядит вполне разумно.
Что проверить до установки
До установки надо проверить не Mox, а саму возможность нормально держать почту на этом VDS.
Минимальный чеклист:
- есть статический IPv4;
- провайдер разрешает исходящий порт
25; - можно задать PTR / rDNS для IP;
- входящие порты
25,465,587,993можно открыть; 80и443доступны для HTTPS, MTA-STS, autoconfig и webmail;- есть доступ к DNS домена;
- IP не выглядит совсем убитым по почтовой репутации;
- понятно, где будут бэкапы.
Для почты лучше использовать отдельный hostname:
mail.example.com
И у провайдера VDS прописать reverse DNS:
203.0.113.10 -> mail.example.com
PTR важен. Если сервер представляется как mail.example.com, а обратная запись ведет в случайное имя провайдера, крупные получатели будут смотреть на письма подозрительно.
Лучше отдельная машина, но можно рядом с сайтом
Самый простой вариант — отдельный VDS, где Mox забирает себе 80/443 и сам выпускает TLS-сертификаты через ACME.
Но в реальной жизни на сервере часто уже живет сайт за nginx. Тогда Mox можно ставить в режиме -existing-webserver: почтовые порты идут напрямую в Mox, а HTTP-часть проксируется через существующий nginx.
Схема получается такая:
internet
-> 25/465/587/993 -> Mox
-> 80/443 -> nginx -> Mox HTTP listeners
Это сложнее, чем чистый сервер под почту, но нормально работает, если не пытаться изобразить магию в nginx.
Установка Mox
Официальный quickstart у Mox простой. Сначала создаем отдельного пользователя:
useradd -m -d /home/mox mox
cd /home/mox
Дальше скачиваем бинарник или собираем из исходников. В документации Mox есть актуальная ссылка на сборку для linux/amd64, поэтому перед установкой лучше свериться с официальной страницей установки.
Для чистого почтового сервера команда будет примерно такой:
./mox quickstart -hostname mail.example.com admin@example.com mox
Если на 80/443 уже стоит nginx или другой webserver:
./mox quickstart -existing-webserver -hostname mail.example.com admin@example.com mox
Quickstart делает важные вещи:
- создает
mox.confиdomains.conf; - добавляет домен и первый аккаунт;
- генерирует пароль админки и пароль почтового аккаунта;
- печатает DNS-записи, которые надо добавить;
- пишет команды для запуска systemd-сервиса;
- сохраняет все инструкции в
quickstart.log.
quickstart.log нельзя тащить в git, заметки, публичные статьи и чаты. Там есть пароли. Файл должен жить только на сервере с нормальными правами доступа.
Пароль админки и пароль ящика — разные вещи
В Mox есть минимум два разных секрета:
- пароль админки Mox;
- пароль почтового аккаунта для IMAP, SMTP и webmail.
Это не одно и то же. Пароль от SMTP не обязан пускать в админку, а пароль админки не надо использовать в приложениях.
Если пароль аккаунта нужно сменить:
cd /home/mox
./mox setaccountpassword accountname
Если нужно сменить пароль админки:
cd /home/mox
./mox setadminpassword
Пароли хранить в менеджере секретов или хотя бы в root-only файле на сервере. В репозитории должны быть только примеры env без реальных значений.
DNS-записи
Mox сам печатает DNS-записи, которые нужны конкретному домену. Это сильно лучше, чем копировать случайный шаблон из интернета.
В базовой схеме будут такие записи:
mail A 203.0.113.10
@ MX 10 mail.example.com.
@ TXT "v=spf1 ip4:203.0.113.10 mx ~all"
mail TXT "v=spf1 a -all"
selector._domainkey TXT "v=DKIM1; k=ed25519; p=..."
_dmarc TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_mta-sts TXT "v=STSv1; id=2026061801"
_smtp._tls TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
DKIM-селекторы не надо придумывать руками. Берите то, что выдал Mox.
Проверки:
cd /home/mox
./mox config test
./mox config dnsrecords example.com
./mox config dnscheck example.com
Важный момент: не включайте MTA-STS в режиме enforce, если MX домена еще указывает на старого провайдера. Policy должна соответствовать реальному MX. Иначе часть отправителей может отказаться доставлять письма, потому что вы сами сказали им ходить на один mail host, а MX показывает другой.
Nginx и webmail
Если Mox работает за существующим nginx, нужно проксировать HTTP-часть Mox без переписывания важных путей.
Обычно наружу нужны:
https://mail.example.com/— account UI и webmail;https://mail.example.com/webmail/— веб-почта;https://mta-sts.example.com/.well-known/mta-sts.txt— MTA-STS policy;https://autoconfig.example.com/...— автоконфигурация клиентов;https://autodiscover.example.com/...— autodiscover.
Админку я бы не оставлял на стандартном публичном пути без дополнительной защиты. Если хотите вынести ее на нестандартный путь, path должен быть настроен в самом Mox, а nginx не должен переписывать его в другой URL.
Пример идеи:
AdminHTTP:
Path: /private-admin/
Forwarded: true
И nginx проксирует этот путь как есть:
location ^~ /private-admin/ {
proxy_pass http://127.0.0.1:1080;
proxy_set_header Host localhost;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
Почему это важно: Mox использует path для login-token cookie. Если снаружи открыть /private-admin/, а внутри проксировать это как /admin/, можно получить ошибку входа из-за cookie path. Это неприятная мелочь, на которой легко потерять час.
После правок:
nginx -t
systemctl reload nginx
systemctl restart mox
SMTP для сайта и ботов
Для backend-приложения лучше завести отдельный адрес или хотя бы отдельный пароль. Настройки держим только в env:
SMTP_HOST=mail.example.com
SMTP_PORT=465
SMTP_SECURE=true
SMTP_USER=bot@example.com
SMTP_PASS=<secret>
MAIL_FROM=bot@example.com
Для порта 465 обычно используется TLS сразу, поэтому SMTP_SECURE=true.
Для 587 соединение начинается обычным SMTP и потом поднимает STARTTLS, поэтому в некоторых библиотеках, например в Nodemailer, secure=false для 587 — это нормально. Безопасность там дает STARTTLS, а не название boolean-поля.
Главное:
- не коммитить
.env; - не отправлять письма с личного пароля админки;
- проверять
nodemailer.verify()или аналог перед боевым переключением; - иметь понятный fallback, если SMTP временно недоступен.
IPv6 лучше не включать автоматически
Если у сервера есть IPv6, Mox может попытаться отправлять письма через него. Технически это нормально. Практически новый IPv6 без PTR, SPF, нормального hostname и репутации может получить отказ от крупных получателей.
Если вы не готовы отдельно настраивать IPv6-почту, стартуйте с IPv4:
- не публикуйте
AAAAдляmail.example.com; - не добавляйте IPv6 в SPF;
- настройте исходящий transport только через IPv4.
Идея конфига:
Transports:
direct-ipv4:
Direct:
DisableIPv6: true
А для домена:
Routes:
-
FromDomain:
- example.com
Transport: direct-ipv4
После этого обязательно:
./mox config test
systemctl restart mox
Что проверить после запуска
Минимальный набор проверок:
systemctl status mox;journalctl -u mox;ss -ltnpпоказывает Mox на25,465,587,993;openssl s_client -connect mail.example.com:465 -servername mail.example.com;openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com;./mox config dnscheck example.com;- отправка письма на Gmail, Яндекс, Mail.ru и свой ящик;
- проверка заголовков письма: SPF, DKIM и DMARC должны проходить;
- очередь Mox после теста не должна быть забита ошибками.
Если Gmail принял письмо, но положил его в спам, это еще не значит, что Mox настроен неправильно. Новый IP и новый почтовый поток часто требуют прогрева. Сначала смотрим на техническую часть: SPF pass, DKIM pass, DMARC pass, корректный PTR, TLS без ошибок. Потом уже занимаемся репутацией.
Бэкапы
Без бэкапов свой почтовый сервер превращается в азартную игру.
Минимально надо сохранять:
- конфиги Mox;
- данные аккаунтов и письма;
- DKIM-ключи;
- TLS-ключи, если они не восстанавливаются автоматически;
- отдельную инструкцию восстановления.
Бэкап без тестового восстановления — это просто надежда в красивой упаковке. Раз в какое-то время стоит поднять копию или хотя бы проверить, что архив читается и в нем есть нужные каталоги.
Итог
Mox хорош тем, что убирает большую часть ручной сборки почтового стека. Webmail, SMTP, IMAP, DKIM, DMARC, MTA-STS и проверки DNS живут в одном понятном инструменте.
Но магии нет. Доставляемость все равно держится на базовых вещах: чистый IP, PTR, правильный DNS, TLS, аккуратная отправка, нормальные логи и бэкапы.
Если нужна просто почта в браузере для пары сотрудников, тариф у провайдера может быть дешевле по времени. Если почта завязана на сайт, админку и автоматические письма, свой Mox на VDS дает больше контроля и меньше зависимости от внезапных тарифных флажков.