Разворачиваем mailcow с нуля: пошаговый регламент ITfresh — от выбора VPS до первого письма, которое не упало в спам

Меня зовут Евгений Семёнов, я технический директор компании «АйТи Фреш». Мы больше пятнадцати лет занимаемся IT-аутсорсингом московских компаний до 50 рабочих мест, и наша собственная почта — не Яндекс 360 и не облако, а mailcow на своём сервере в дата-центре МТС: 21 домен, за две сотни ящиков, это боевой прод, на котором живут и наши, и клиентские адреса. В обзорной статье о mailcow в 2026 году я объяснял, почему из всех бесплатных почтовых сборок мы остановились именно на этой. Сегодня — практика: наш внутренний регламент внедрения, по которому инженер разворачивает клиенту почтовый сервер за 3–4 часа чистой работы плюс сутки на прогрев DNS.

Главное отличие этого регламента от типовых инструкций из интернета сформулирую сразу: DNS и репутация IP-адреса настраиваются ДО команды docker compose up, а не после. По моему опыту, четыре из пяти обращений «поставили почтовый сервер, письма падают в спам» — это проблемы, заложенные ещё на этапе выбора VPS и заведения DNS-записей. Сама установка mailcow занимает двадцать минут и почти никогда не ломается. Ломается фундамент под ней. Поэтому и нумерация этапов у нас начинается с нуля — с того, что делается до какой-либо оплаты.

Этап 0. Выбор VPS и проверка IP до оплаты

Требования к железу у mailcow скромные, но с одной развилкой. Полный стек включает антивирус ClamAV, который в одиночку съедает пару гигабайт памяти. Наш стандарт для клиентского внедрения: 4 vCPU, 8 ГБ RAM, 60 ГБ SSD — с запасом под ClamAV и рост ящиков. Если бюджет жмёт, допустимый минимум — 6 ГБ RAM с отключённым антивирусом (параметр SKIP_CLAMD=y, к нему вернёмся на этапе установки). Меньше шести гигабайт брать не надо: стек будет уходить в swap, а тормозящий IMAP пользователи прощают хуже, чем его отсутствие. Операционная система — Debian 12 или Ubuntu 24.04, чистая, без панелей управления и чужих веб-серверов на 80/443 портах.

Проверка репутации IP — до того, как отдали деньги

Виртуалку вам выдадут с IP-адресом, у которого есть прошлое. Возможно, полгода назад с него слал рассылки чей-то взломанный сайт, и адрес до сих пор числится в чёрных списках. Почтовый сервер на таком IP обречён: Gmail и Mail.ru будут заворачивать письма в спам или отклонять их вовсе, что бы вы ни делали с SPF и DKIM. Поэтому первое действие после выдачи VPS (у большинства хостеров IP виден до полной настройки) — прогнать адрес через blacklist-проверку на mxtoolbox и посмотреть его напрямую в Spamhaus. Если адрес засвечен хотя бы в одном-двух серьёзных списках — не выкупаем, а сразу пишем тикет хостеру с просьбой заменить IP. Это нормальная просьба, хостеры к ней привыкли. «Отмывать» грязный адрес самостоятельно — месяцы переписки с операторами списков, и я не знаю ни одного случая, когда это оказалось дешевле замены.

Порт 25: закрыт по умолчанию почти у всех

Исходящий 25-й порт у большинства российских хостеров заблокирован по умолчанию — это их защита от спамеров, арендующих VPS пачками. Без него ваш сервер сможет принимать почту, но не сможет отправлять её другим серверам. Открывается порт тикетом в поддержку: пишете, что разворачиваете корпоративный почтовый сервер для собственного домена, укажите домен и назначение. Обычно открывают за несколько часов, иногда просят подтвердить, что массовых рассылок не будет. Важно сделать это заранее: обнаружить закрытый 25-й порт в момент контрольной отправки — значит потерять день.

PTR-запись: без неё дальше идти бессмысленно

PTR — запись обратной DNS-зоны, которая по IP-адресу возвращает имя. Принимающие серверы, в первую очередь Mail.ru и Gmail, сверяют её с тем именем, которым ваш сервер представился в SMTP-сессии. Нет PTR или она не совпадает с hostname — письмо с высокой вероятностью едет в спам, а часть серверов отклонит его на пороге. Обратная зона принадлежит хостеру, поэтому PTR заказывается у него: в панели или тикетом. Значение должно в точности совпадать с полным именем сервера, которое мы выберем для mailcow, — например, mail.company.ru. Заведите её в тот же день, что и VPS: у некоторых хостеров PTR применяется до суток.

Этап 1. DNS-фундамент до установки

Пока хостер открывает порт и прописывает PTR, заводим прямые DNS-записи. Именно здесь решается судьба доставляемости, и именно этот этап типовые гайды задвигают в конец — «а теперь настройте SPF». У нас наоборот: сервер ещё не установлен, а DNS уже опубликован. Вот полный чек-лист для домена company.ru и сервера с адресом 203.0.113.10:

Пара комментариев к таблице. SPF v=spf1 mx -all означает «отправлять от имени домена может только сервер из MX-записи, остальных — отвергать жёстко». Если у клиента есть CRM или сайт, шлющие почту через сторонние сервисы, их включения добавляются сюда же — но SPF-запись у домена всегда одна, вторая TXT с v=spf1 ломает проверку целиком. DMARC на старте ставим в режим p=quarantine: подозрительное — в спам, отчёты — на ящик постмастера; до p=reject дорастаем через месяц спокойной статистики. Записи autodiscover и autoconfig нужны, чтобы Outlook и мобильные клиенты подхватывали настройки по одному только адресу почты — сотрудникам не придётся диктовать порты.

А вот DKIM-записи в таблице сознательно нет: пара ключей генерируется самим mailcow после установки, тогда и опубликуем TXT для селектора dkim._domainkey. Это единственная запись, которая физически не может появиться раньше сервера.

Почему порядок именно такой

DNS — система инертная: изменения расползаются по резолверам от минут до часов, а PTR у некоторых хостеров — до суток. Если публиковать записи после установки, у вас будет работающий сервер, который несколько часов рассылает письма без SPF и с несовпадающим PTR, — и первые же письма новорождённого сервера уйдут получателям с максимально подозрительными признаками. Репутация IP у крупных провайдеров строится с первых сообщений, испортить её на старте легко, выправлять — долго. Делая DNS в начале, мы получаем обратную картину: к моменту docker compose up записи уже прогрелись, и самое первое письмо уходит с полным комплектом подписей.

Этап 2. Установка: шесть команд до работающего стека

Теперь то, ради чего всё затевалось, — и это правда самая короткая часть. mailcow-dockerized ставится клонированием репозитория и генерацией конфигурации. Актуальный на момент написания релиз — 2026-07 «Mooly» от 13 июля 2026 года: внутри Postfix 3.10.12, Rspamd 4.1.0 и Nginx 1.30.3, а сам postfix-контейнер переехал на свежий Debian Trixie. На сервере должны стоять Docker и docker compose plugin, дальше:

cd /opt
git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
./generate_config.sh
# скрипт спросит FQDN сервера: mail.company.ru
# и часовой пояс: Europe/Moscow

Скрипт создаст файл mailcow.conf — главный конфиг всего стека. Перед запуском правим в нём две вещи под нашу схему:

nano mailcow.conf

# если на сервере 6 ГБ RAM — отключаем ClamAV:
SKIP_CLAMD=y

# дополнительные имена в TLS-сертификат,
# чтобы autodiscover/autoconfig работали по HTTPS:
ADDITIONAL_SAN=autodiscover.company.ru,autoconfig.company.ru

И запускаем стек — эти две команды скачают образы и поднимут всё хозяйство, на типовом VPS уходит 10–20 минут:

docker compose pull
docker compose up -d

Что поднялось: разбор docker compose ps

Команда docker compose ps покажет около 18 контейнеров — и у новичка этот список вызывает лёгкую панику. На деле всё логично: mailcow не изобретает почтовые велосипеды, а упаковывает проверенные десятилетиями компоненты, по контейнеру на роль. Вот кто есть кто:

Понимать этот список стоит хотя бы ради диагностики: когда что-то идёт не так, ответ почти всегда лежит в логах конкретного контейнера (docker compose logs --tail=100 postfix-mailcow), а не «где-то в mailcow».

Первый вход: admin/moohoo и немедленная смена

Панель администратора открывается по адресу https://mail.company.ru, логин по умолчанию — admin, пароль — moohoo. Эта пара одинакова у каждой свежей установки в мире, поэтому первое действие в панели — смена пароля, второе — включение двухфакторной аутентификации (TOTP-приложение). С весеннего релиза 2026-03 «Moorch» mailcow умеет принудительную 2FA: политикой можно запретить админам и доменным администраторам работать без второго фактора вообще. В клиентских внедрениях мы включаем её всегда — панель почтового сервера смотрит в интернет, и перебирать admin/moohoo боты начинают в первые же часы жизни сервера.

Этап 3. Домен, DKIM, первый ящик

Стек работает, но пока не знает ни об одном домене. Идём в панели по маршруту E-Mail → Configuration → Domains → Add domain, вводим company.ru. Здесь же задаются лимиты: число ящиков, число алиасов и — внимание — квота домена, общий дисковый бюджет на все его ящики.

Следующий шаг — DKIM. В разделе Configuration → ARC/DKIM Keys генерируем для домена ключ длиной 2048 бит (1024 уже считается слабым, 4096 не всякая DNS-панель переварит в одной записи). Панель покажет готовое содержимое TXT-записи — публикуем её у DNS-провайдера с именем dkim._domainkey.company.ru. С этого момента Rspamd подписывает каждое исходящее письмо домена, а получатели могут проверить подпись по опубликованному открытому ключу. Это последний кирпич DNS-фундамента, который мы отложили на этапе 1.

Теперь первый ящик: Mailboxes → Add mailbox, имя, пароль, персональная квота. Сразу же заводим и алиасы — виртуальные адреса, которые сваливаются в реальные ящики: классика малого бизнеса — info@ и sales@, указывающие на ящик секретаря или руководителя. Алиас не занимает квоту и не требует отдельного пароля, поэтому адресов «на вырост» можно завести сколько угодно. На двадцать сотрудников у типового нашего клиента приходится двадцать ящиков и под сорок алиасов.

Этап 4. Сертификаты и доступ клиентов

TLS-сертификатами заниматься не придётся совсем — и это одна из причин, почему я советую mailcow новичкам. Контейнер acme-mailcow при старте сам запрашивает сертификат Let's Encrypt на имя сервера и все имена из ADDITIONAL_SAN, сам продлевает его и сам раскладывает по сервисам: панель, SOGo, IMAP, SMTP. Единственное условие — корректная A-запись, указывающая на сервер, и открытый снаружи 80-й порт для проверки владения именем. Мы её сделали ещё на этапе 1, поэтому к моменту первого входа в панель сертификат уже валиден.

DNS-01 challenge — когда 80-й порт закрыт

А если сервер стоит за NAT, или 80-й порт занят чужим сервисом, или безопасники требуют не открывать HTTP наружу? До недавнего времени это означало ручную возню с сертификатами. Релиз 2026-03 «Moorch» добавил поддержку DNS-01 challenge: владение доменом подтверждается не ответом по HTTP, а временной TXT-записью, которую mailcow создаёт через API DNS-провайдера. Сервер при этом может вообще не иметь входящего 80-го порта. Для инфраструктур за pfSense — а таких у наших клиентов половина — это сняло целый класс костылей.

Outlook и мобильные: параметры одним блоком

Благодаря autodiscover/autoconfig большинство клиентов настраиваются вводом адреса и пароля. Outlook подключается через ActiveSync (его отдаёт SOGo) — вместе с почтой синхронизируются календарь и контакты, что для переезжающих с Exchange принципиально. На случай клиентов, не умеющих автоконфигурацию, рассылаем сотрудникам стандартный блок параметров:

Сервер входящей почты:  IMAP  mail.company.ru  порт 993  SSL/TLS
Сервер исходящей почты: SMTP  mail.company.ru  порт 465  SSL/TLS
Логин: полный адрес (ivanov@company.ru)
ActiveSync (Outlook/смартфоны): https://mail.company.ru/Microsoft-Server-ActiveSync

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

Тем, кому клиент не нужен вовсе, достаточно ссылки https://mail.company.ru/SOGo. Сотрудник открывает её в браузере, входит своим адресом — и видит почту, календарь и адресную книгу на русском языке, без каких-либо действий администратора. По опыту, треть пользователей малого офиса так и живёт в вебе, не ставя локальный клиент никогда.

Этап 5. Контрольная отправка и диагностика доставляемости

Сервер собран, но сдавать его клиенту рано: сначала доказываем доставляемость. Инструмент номер один — mail-tester.com: сервис выдаёт одноразовый адрес, вы шлёте на него письмо из свежесозданного ящика (через SOGo или настроенный клиент) и получаете оценку до 10/10 с разбором: валидны ли SPF, DKIM, DMARC, PTR, не числится ли IP в чёрных списках, не выглядит ли содержимое спамом. Наш регламент требует 10/10 до передачи сервера клиенту; если фундамент из этапов 0–1 заложен честно, оценка получается с первой попытки.

Вторая проверка — заголовки реального письма. Отправляем сообщение на любой ящик Gmail, открываем в нём «Показать оригинал» и смотрим три строки: SPF: PASS, DKIM: PASS, DMARC: PASS. Те же проверки в заголовках показывает и Mail.ru. Три зелёных «pass» в оригинале письма — объективное свидетельство, что криптографический паспорт сервера в порядке; всё остальное — вопрос репутации и содержимого.

Типовые фейлы новичка — четыре из практики

Когда балл ниже десятки, причина почти всегда одна из этих:

• Сервер представляется IP-адресом вместо имени. В SMTP-приветствии уходит голый адрес — верный признак кривой конфигурации, за который принимающие режут балл. В mailcow это следствие неверного FQDN, указанного в generate_config.sh; лечится правкой MAILCOW_HOSTNAME в mailcow.conf.
• PTR не совпал. Хостер прописал запись с опечаткой, или вы сменили hostname после заказа PTR. Сверяйте посимвольно: mail.company.ru в PTR и в конфиге должны быть идентичны.
• Две SPF-записи у домена. Классика: у домена уже была TXT с v=spf1 от сайта или CRM, и рядом добавили вторую. Стандарт трактует это как перманентную ошибку — проверку не проходит ни одна. SPF-запись всегда одна, источники объединяются внутри неё.
• Не тот DKIM-селектор. Ключ опубликован с именем default._domainkey, а сервер подписывает селектором dkim — подпись есть, но получатель ищет ключ не там. Селектор из панели mailcow и имя TXT-записи должны совпадать.

Прогрев IP: первые две недели — тишина

Даже безупречно настроенный сервер на свежем IP для Gmail и Mail.ru — незнакомец. Репутация зарабатывается объёмом нормальной переписки: если с нового адреса в первый же день улетает пятьсот писем, антиспам-системы отреагируют жёстко — у крупных провайдеров для неизвестных отправителей действуют негласные лимиты, и превышение конвертируется в спам-папку или временные отказы. Наше правило: первые две недели — только живая деловая переписка сотрудников, никаких массовых уведомлений, рассылок и импорта очередей из старой системы. Заодно за эти две недели накапливаются DMARC-отчёты на ящике постмастера — по ним видно, кто ещё пытается слать от имени домена, и можно спокойно ужесточать политику до p=reject.

Сколько это стоит и когда звать подрядчика

Посчитаем экономику честно. VPS с 8 ГБ RAM у российских хостеров — порядка 2500 рублей в месяц, домен — копейки в пересчёте на месяц, лицензий нет вообще: mailcow бесплатен при любом числе ящиков. Работы по этому регламенту — 3–4 часа инженерного времени плюс сутки календарного ожидания DNS и PTR. Для сравнения: те же 20 сотрудников на облачной корпоративной почте обходятся в 5–10 тысяч рублей ежемесячно, навсегда. Сервер окупается за первые месяцы — при условии, что им кто-то занимается.

И вот здесь честность требует назвать красные флаги, при которых я не советую делать это самостоятельно:

• В команде нет никого с опытом Linux. Установка по инструкции получится, а вот первый инцидент — переполненный диск, очередь из-за заблокированного получателем IP — превратится в простой почты на дни.
• Хостер не даёт PTR или не открывает 25-й порт. Это не преодолевается настройками; либо менять хостера, либо не начинать.
• Почта критична в режиме 24/7, а резервного канала нет. Один сервер без мониторинга и бэкапов — это не «своя почта», это лотерея с бизнес-перепиской в качестве ставки.

В клиентских внедрениях мы поэтому не ограничиваемся регламентом из этой статьи: на сервер сразу встаёт мониторинг с алертами в Telegram (падение контейнера, рост очереди, место на диске, попадание IP в чёрные списки), а бэкапы уезжают на отдельную площадку по расписанию. Про резервное копирование mailcow и сценарии восстановления — отдельная статья уже в работе. Если же разворачивать и сопровождать почту самим некому — напишите мне в Telegram @ITfresh_Boss или позвоните +7 903 729-62-41: пройдём по этому же регламенту, только руками инженеров, которые держат на mailcow собственный прод не первый год.