Как установить mailcow и запустить почту своего домена

Развернём mailcow на отдельной Ubuntu Server 26.04 LTS с Docker Engine и Compose. Понадобятся постоянный публичный IP, домен example.com и имя почтового сервера mail.example.com. Заменяйте эти имена и адрес 203.0.113.10 своим доменом и IP. Команды выполняйте в SSH-терминале сервера, панели провайдера и DNS открывайте в браузере своего компьютера.

До установки получите подтверждение провайдера, что TCP 25 разрешён в обе стороны и можно задать PTR — обратную DNS-запись для IP. Для почты важно не только входящее соединение: сервер должен отправлять письма другим почтовым серверам. Если провайдер запрещает это, сначала решите вопрос с ним.

Пройдите подготовку Ubuntu только до Docker/Compose: дополнительный Nginx на хосте не устанавливайте. Веб-интерфейс обслуживает встроенный контейнер Nginx, сертификатом управляет mailcow. Подбор сервера объясняет расход памяти и диска на почту. До смены MX рабочего домена сохраните прежнюю почту и подготовьте её перенос.

Если домен уже получает рабочую почту, сначала проверяйте установку на отдельном тестовом домене. Не переключайте его действующий MX раньше готовности ящиков. Ниже предполагается новый домен. IPv6 не включайте и AAAA не создавайте, если не настроены его связность и PTR.

Добавим Git для загрузки официального комплекта, openssl и curl для проверок, а dnsutils — для команд dig. apt update обновляет список пакетов, следующая команда их устанавливает.

Обе команды должны завершиться без ошибок. Проверьте docker version и docker compose version: Docker должен работать, Compose — быть версии 2 или новее.

Посмотрите, какие службы уже слушают сеть. Mailcow нужны 25 для обмена почтой, 465/587 для отправки пользователями, 993 для IMAP, 80/443 для сайта и сертификата. IMAP позволяет почтовому клиенту читать ящик. Разрешите эти TCP-порты на сетевом экране провайдера. До смены пароля администратора ограничьте 443 своим IP; 80 оставьте доступным для проверки сертификата.

На нужных портах не должно быть чужого SMTP/IMAP или веб-сервера. Не останавливайте неизвестную службу без выяснения её назначения. Docker публикует порты по собственным правилам, поэтому дополнительно проверяйте периметр у провайдера.

В DNS-панели добавьте A-запись mail.example.com с публичным IPv4 сервера. Если сервис предлагает HTTP-проксирование, отключите его для почтового имени. SMTP и IMAP должны обращаться к самому серверу.

Ответ должен совпадать с публичным IP сервера. Если пусто или адрес другой, дождитесь применения DNS или исправьте запись.

В панели провайдера задайте PTR для вашего IP: mail.example.com. Это обратная проверка «какому имени принадлежит адрес». В команде обязательно замените документальный IP своим.

Ожидается mail.example.com. с точкой в конце. Имя из PTR должно через A возвращать тот же IP. Если изменить PTR нельзя, решите это с провайдером до рабочего запуска.

В DNS-панели создайте MX для example.com: приоритет 10, значение mail.example.com. MX сообщает внешним отправителям, куда доставлять письма домена. На новом домене делаем это сейчас; на рабочем — после испытаний и готовности всех ящиков.

Ожидается 10 mail.example.com.. Если осталась старая запись, проверьте приоритеты и план переключения; не удаляйте старую почту.

SPF — TXT-запись, которая перечисляет разрешённые источники отправки домена. В DNS добавьте для example.com v=spf1 mx -all, только если почту отправляет один этот сервер. Если есть внешний сервис рассылок или CRM, объедините его разрешения по инструкции провайдера.

Для домена должна быть одна SPF-запись, начинающаяся с v=spf1. Две отдельные SPF-записи приводят к ошибке проверки.

DMARC задаёт действия при ошибках SPF/DKIM и адрес для отчётов. В DNS добавьте TXT для _dmarc.example.com: v=DMARC1; p=none; rua=mailto:dmarc@example.com. Пока только собираем отчёты. Ящик dmarc создадим ниже. DKIM — подпись письма — настроим после появления домена в mailcow.

Ответ должен содержать вашу запись с p=none и обслуживаемым адресом отчётов. Строгую политику включайте после проверки всех законных отправителей.

Склонируем репозиторий в /opt/mailcow-dockerized. Git загрузит конфигурацию и скрипты; контейнеры пока не запускаются.

Загрузка должна завершиться успешно. Дальше команды запускайте из этого каталога; не заменяйте официальный Compose сокращённым файлом из другого руководства.

В инструкции закреплён 2026-09a. checkout выбирает соответствующее состояние официального комплекта вместо плавающего master.

Git должен выбрать тег без ошибки. Сообщение detached HEAD нормально для установленного по тегу релиза.

Запустим официальный генератор. На вопросы введите полное имя mail.example.com с вашим доменом, часовой пояс и стабильный выпуск. Не вводите один example.com вместо имени сервера.

Должен появиться mailcow.conf без ошибки генератора. Он содержит секреты; не публикуйте файл и не пересылайте его целиком.

Генератор при выборе stable может переключить Git на master, поэтому вернём тег и проверим его. Затем откройте sudo nano mailcow.conf: проверьте MAILCOW_HOSTNAME и часовой пояс. В nano сохранение — Ctrl+O, Enter, выход — Ctrl+X. Если нет IPv6, примените официальный порядок отключения.

Ожидается 2026-09a. MAILCOW_HOSTNAME должен совпадать с A/PTR и будущим адресом браузера.

Закроем чтение файла с секретами и проверим структуру официальной конфигурации. --quiet не печатает секреты.

Проверка должна завершиться без ошибок. Если есть ошибка переменной или сети, исправьте её до скачивания образов.

Комплект включает веб-интерфейс, почтовые службы, фильтр и базы. Docker скачает все предусмотренные выбранным релизом образы.

Дождитесь успешной загрузки каждого образа. При сбое реестра повторяйте этот шаг после устранения подключения.

Команда запускает сервисы в фоне. Первый запуск также выпускает HTTPS-сертификат. После запуска посмотрите sudo docker compose ps и, если сертификат не готов, sudo docker compose logs --tail=100 acme-mailcow nginx-mailcow.

Сервисы не должны бесконечно перезапускаться. Для сертификата должны работать A/AAAA и входящий 80. Не вводите рабочие пароли на странице с предупреждением TLS.

Со своего разрешённого IP откройте https://mail.example.com/admin. Первые данные из официальной инструкции: admin и moohoo. Сразу установите новый длинный пароль и настройте второй фактор — дополнительный код при входе. Только после этого расширяйте доступ к панели.

Проверьте выход и повторный вход с новым паролем. Старый moohoo больше не должен подходить. Сохраните средства восстановления второго фактора.

В панели Configuration → Mail Setup → Domains добавьте example.com. Задайте понятные общие квоты и лимит ящиков. Квота ограничивает место для почты и защищает диск от переполнения.

Домен должен появиться в списке без ошибки. Проверьте, что используете почтовый домен example.com, а не имя самого сервера mail.example.com.

Создайте test@example.com с отдельным паролем и небольшой квотой. Добавьте postmaster, abuse и dmarc как ящики либо алиасы на обслуживаемый адрес. Алиас принимает письма на дополнительное имя и передаёт их существующему ящику.

Войдите в SOGo с полным адресом test@example.com и паролем ящика. Пароль администратора панели для этого не используется.

В разделе DKIM создайте ключ для домена. Скопируйте из панели точное имя TXT-записи с selector и её значение в DNS. DKIM подписывает исходящие письма; случайную строку из другого примера использовать нельзя.

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

Отправьте письмо с внешнего ящика на test@example.com, затем ответьте через SOGo. Повторите с адресом другого почтового оператора. В заголовках доставленного письма проверьте результаты SPF, DKIM и DMARC — они должны проходить.

В обычном почтовом клиенте задайте IMAP mail.example.com:993 с TLS и SMTP 465 с TLS либо 587 с STARTTLS. Логин — полный адрес, пароль — пароль ящика. Отправьте письмо с небольшим вложением. Не отключайте проверку сертификата ради входа.

Письма и ответы должны реально прийти, вложение — открыться, а сертификат — соответствовать имени. Если отправка зависла, смотрите sudo docker compose exec postfix-mailcow postqueue -p и журнал postfix-mailcow; timeout часто связан с TCP 25 у провайдера.

Используем штатный helper: backup all сохраняет все поддерживаемые компоненты, включая почту и базы. Команда может занять время и место на диске. После выполнения отдельно сохраните mailcow.conf, data/conf и свои override-файлы в тот же защищённый набор.

Проверьте успешное завершение helper и созданную папку mailcow_DATE. Перенесите комплект через SFTP вне сервера, сохранив имена и ограниченный доступ. Наличие только mailcow.conf не восстанавливает письма.

Хотя бы один раз восстановите набор на отдельной изолированной установке по официальной инструкции. Helper в режиме restore предлагает выбрать дату и компоненты; используйте полный набор. Не переименовывайте его папки. У тестовой машины не должно быть рабочего MX и неконтролируемой исходящей отправки.

Проверьте старое письмо, вложение, пароль ящика и ключ DKIM. Затем назначьте регулярные копии с контролем ошибок и свободного диска. Перед обновлением создайте свежую внешнюю копию и следуйте официальному update.sh; переход на stable предусмотрен самим скриптом. Откат только одного контейнера не возвращает старую схему баз.

Если нужно разбирать доставку, используйте sudo docker compose logs --since=15m postfix-mailcow dovecot-mailcow rspamd-mailcow. Не отключайте антиспам целиком ради одного адреса. Рабочий домен переключайте на новый MX после создания всех ящиков, проверки доставки и согласованного переноса прежних писем.