Mailcow: письма попадают в спам — решение

MAATRIX

Вы подняли Mailcow, создали ящики, всё вроде работает — а письма получатели находят в папке «Спам» или не находят вовсе. Общая теория тут одна и та же для любого почтового сервера: PTR, SPF, DKIM, DMARC и репутация IP — мы подробно разбирали её в статье про Postfix и попадание в спам, и повторять её здесь смысла нет. Разница в том, что Mailcow — готовый Docker-стек со своей веб-админкой и встроенным антиспам-движком Rspamd, и у него есть особенности, о которых общая теория молчит: где в интерфейсе искать DKIM-ключ, что значит «новый IP» с точки зрения почтовиков, и как посмотреть, за что конкретно Rspamd понизил письмо. Пройдёмся именно по этому.

Сначала: за 2 минуты проверьте домен на mail-tester.com

Прежде чем лезть в настройки, получите объективную картину. Сервис mail-tester.com — это бесплатный инструмент, который присылает вам одноразовый адрес; вы отправляете на него письмо с вашего Mailcow, а сервис в ответ показывает разбор: прошли ли SPF, DKIM, DMARC, есть ли PTR, не засветился ли ваш IP в чёрных списках (списках адресов, которые ранее слали спам), и итоговую оценку по 10-балльной шкале.

Практически это выглядит так: откройте mail-tester.com, скопируйте показанный им адрес вида test-abc123@mail-tester.com, отправьте на него письмо из вашего ящика в Mailcow (через webmail SOGo или любой почтовый клиент), затем вернитесь на сайт и нажмите «Check your score». Полезно делать это на каждом этапе настройки — до и после публикации DKIM, до и после смены IP — чтобы видеть, какой конкретно пункт изменил ситуацию, а не гадать. Сервис не идеален (иногда занижает балл за формальности вроде отсутствия unsubscribe-ссылки в тестовом письме), но для диагностики технических проблем доставляемости он даёт самую быструю и честную картину из всех доступных бесплатных инструментов.

DKIM в Mailcow: где искать и как публиковать ключ через веб-интерфейс

DKIM — это цифровая подпись письма: сервер подписывает исходящую почту закрытым ключом, а получатель проверяет подпись открытым ключом, который лежит у вас в DNS. Если подписи нет или она не проходит проверку, почтовик меньше доверяет письму. В отличие от классического Postfix, где DKIM настраивают вручную через OpenDKIM и правят конфиги в консоли, в Mailcow всё делается мышкой в веб-интерфейсе — и здесь чаще всего теряются новички, потому что ищут файлы там, где их просто нет.

Откройте админку Mailcow (https://mail.вашдомен.ru) и зайдите в раздел конфигурации почты — там есть отдельная вкладка для DKIM/ARC-ключей, привязанная к доменам. Выберите домен, задайте селектор (обычно оставляют значение по умолчанию, например dkim) и длину ключа — берите 2048 бит, это стандарт на сегодня, 1024 бита слабее и некоторые почтовики к нему уже подозрительны. После генерации Mailcow сразу показывает готовую TXT-запись целиком: имя записи вида dkim._domainkey.вашдомен.ru и длинное значение публичного ключа. Это и есть главное удобство — не нужно вручную вытаскивать ключ из файла на сервере, интерфейс отдаёт готовую строку для копирования прямо в DNS вашего домена.

Частая ошибка именно в Mailcow — копировать значение ключа с лишними пробелами или переносом строки, из-за чего DNS-провайдер сохраняет запись неправильно и DKIM не проходит, хотя в админке Mailcow ключ выглядит нормально. После публикации в DNS подождите, пока запись разойдётся (обычно счёт идёт на минуты, но у некоторых DNS-провайдеров кэш живёт дольше), и проверьте командой:

dig txt dkim._domainkey.вашдомен.ru +short

Если ответ пуст — запись либо не сохранилась, либо ещё не разошлась. Если домены и ящики уже добавлены, а этой вкладки не видно — обновите Mailcow, в старых версиях интерфейс организован немного иначе, но сама логика («ключ генерируется и показывается через UI, а не создаётся вручную в файлах») не менялась.

Новый IP всегда «на испытательном сроке» — это нормально

Здесь важно снять лишнюю тревогу. Даже при идеально настроенных SPF, DKIM и DMARC свежий сервер с новым IP-адресом первое время может получать заниженную доставляемость у крупных почтовиков — Gmail, Outlook и других. Это называется репутацией IP: у почтовых систем нет истории по этому адресу, они не знают, легитимный вы отправитель или только что скомпрометированный спамерами сервер, и поэтому первое время присматриваются внимательнее — часть писем может уходить в спам или папку "Прочее" даже без явных ошибок в настройке.

Это не поломка и не повод переустанавливать Mailcow с нуля. Практический совет — не начинайте с массовой рассылки на десятки адресов в первый же день: отправляйте письма постепенно, в первую очередь реальным получателям, которые откроют письмо и ответят (это сильный положительный сигнал для почтовиков) — так репутация IP нарабатывается естественным путём. Ориентировочно на выход на нормальную доставляемость у нового IP уходит от нескольких дней до нескольких недель в зависимости от объёма и характера переписки — это именно ориентир, у вас может быть иначе, точных universal-цифр здесь никто честно не назовёт. Параллельно проверяйте IP по основным чёрным спискам (DNSBL) — если адрес чист и не встречался ранее в спам-рассылках, «испытательный срок» просто снижается со временем сам, вмешательство не требуется. Отдельно стоит выбирать сервер с изначально чистым выделенным IP, а не адресом из пула, где раньше уже мог сидеть спамер, — так и репутация будет чище с самого старта.

Rspamd внутри Mailcow: встроенный антиспам-движок и его вердикты

Rspamd — это движок, который в Mailcow встроен по умолчанию и отвечает не только за отсев входящего спама, но и косвенно влияет на репутацию исходящих писем: он же проверяет ваши собственные исходящие письма на признаки, которые могли бы насторожить принимающую сторону. В отличие от связки Postfix + отдельно устанавливаемый Rspamd (об этом у нас есть отдельная статья про настройку Rspamd на VPS), в Mailcow его не нужно ставить и связывать с почтовым сервером самостоятельно — контейнер rspamd-mailcow поднимается вместе со всем стеком и уже подключён к Postfix и Dovecot из коробки.

Rspamd оценивает каждое письмо по сумме «символов» (правил) — например, прошёл ли DKIM, похоже ли содержимое на фразы из спам-баз, совпадает ли IP отправителя с историей легитимной переписки — и выставляет итоговый балл. Если балл выше порога, письмо помечается как спам или уходит в карантин. Полезно понимать: то же самое происходит и с вашей исходящей почтой, если она проходит через тот же движок при пересылке между доменами внутри Mailcow, — поэтому даже собственные письма стоит время от времени проверять на реалистичные спам-триггеры: слишком много ссылок, капс в теме, подозрительные вложения.

Посмотреть состояние самого движка можно логами контейнера:

sudo docker compose -f /opt/mailcow-dockerized/docker-compose.yml logs rspamd-mailcow --tail 50

Это полезно, когда Rspamd вообще не отвечает или падает — тогда письма могут зависать в очереди Postfix без обработки. Но для повседневной диагностики «почему конкретное письмо получило такой балл» логи контейнера — не самый удобный инструмент, гораздо нагляднее вердикт смотреть там, где он адресован именно этому письму — в его заголовках.

Как посмотреть, за что конкретное письмо получило спам-балл

Самый надёжный и не зависящий от версии интерфейса способ — открыть заголовки конкретного письма. Rspamd в Mailcow добавляет к каждому обработанному письму служебный заголовок вида X-Spamd-Result, где построчно перечислены все сработавшие правила с их весом и итоговая сумма баллов. Выглядит это примерно так (сокращённо):

X-Spamd-Result: default: False [2.10 / 15.00]
  DKIM_SIGNED(0.00), R_SPF_ALLOW(-0.20), MIME_GOOD(-0.10),
  FROM_HAS_DN(0.00), BAYES_SPAM(1.50), MISSING_XM_UA(0.30)

Число в квадратных скобках — итоговый балл против порога срабатывания карантина. Каждая строка ниже — конкретная причина: например, BAYES_SPAM означает, что байесовский фильтр (статистический анализ текста на основе ранее размеченных писем) счёл содержимое похожим на спам, а R_SPF_ALLOW с отрицательным весом — это, наоборот, бонус за то, что SPF прошёл. Именно эта строка отвечает на вопрос «почему письмо получило такой балл» гораздо точнее, чем общий совет «настройте SPF/DKIM/DMARC» — вы видите конкретный вес каждого фактора.

Чтобы посмотреть заголовки: в веб-почте SOGo (встроенный webmail Mailcow) откройте письмо и выберите пункт вроде «Показать исходное сообщение» / «View source» — в исходном тексте письма в самом верху и будет блок заголовков с X-Spamd-Result. Для входящей почты, которую Mailcow поместил в карантин, тот же вердикт видно в разделе карантина в админке — там же можно вручную разрешить доставку письма, если Rspamd перестраховался и ошибочно занизил легитимное сообщение. Учтите, что менюшка карантина и точное название пунктов может немного отличаться между версиями Mailcow — общий принцип («карантин привязан к конкретному письму и его вердикту Rspamd») остаётся неизменным.

Частые причины у Mailcow, которые не покрывает общая теория SPF/DKIM/DMARC

Кроме классических PTR/SPF/DKIM/DMARC — а это база, которую стоит закрыть в первую очередь, — у Mailcow конкретно встречаются свои грабли. Первая: DKIM-ключ сгенерирован в интерфейсе, но забыт в DNS — Mailcow генерирует ключ сразу при добавлении домена, и если вы пропустили шаг с публикацией TXT-записи, письма будут уходить без подписи вообще, а не с ошибкой подписи, что иногда сбивает с толку при диагностике.

Вторая: ClamAV (встроенный антивирус) или Rspamd потребляют больше памяти, чем выделено серверу, контейнер начинает перезапускиваться, и часть писем обрабатывается некорректно или с задержкой — это выглядит как «случайные» проблемы с доставляемостью, хотя причина в ресурсах, а не в настройках почты. Проверяйте docker compose ps на предмет статуса restarting у контейнеров, если спам-баллы ведут себя нестабильно от письма к письму без видимой причины.

Третья: при миграции с другого почтового сервера на Mailcow старый DKIM-селектор остаётся в DNS, а Mailcow создаёт новый с тем же или другим именем — в DNS оказываются две конфликтующие DKIM-записи под одним селектором, и подпись у части писем не проходит непредсказуемо. Проверяйте DNS перед запуском Mailcow в бою на предмет старых записей от прежнего почтового решения — их нужно удалить, а не оставлять «на всякий случай». Общая установка Mailcow с нуля подробно разобрана в статье про установку и настройку Mailcow на VPS, а более широкий список типичных сбоев — в статье Mailcow: частые ошибки и решения.

Частые вопросы