Антиспам на уровне почтового сервера: почему SPF, DKIM и DMARC — это не про входящий спam

За несколько лет я поднял и починил десятки почтовых серверов — от бухгалтерии на пять человек до производства на сорок рабочих мест. Разговор каждый раз примерно одинаковый: «У нас всё настроено, SPF есть, DKIM есть, DMARC на strict, а спам всё равно валится тоннами». И вот тут начинается неловкий момент. SPF, DKIM и DMARC вообще не про это. Они защищают вашу репутацию как отправителя — и только. Фильтрует входящий мусор совершенно другой слой, о котором почему-то не думают, пока не наступят.

SPF, DKIM, DMARC — это ваш паспорт, а не охрана на входе

Давайте разберёмся, как оно на самом деле устроено. SPF — DNS-запись, где вы прямо указываете: письма с моего домена приходят только вот с этих IP-адресов, и ни с каких других. DKIM — цифровая подпись, доказывающая, что письмо не тронули по дороге. DMARC — правило для получателя: что делать, если проверки провалились — отклонить, бросить в спам или пропустить с пометкой. Все три протокола работают в одну сторону. Они говорят получателю: да, это действительно мы, а не мошенник, притворяющийся вашей бухгалтерией.

Я сам настраиваю это в первую очередь на любом новом сервере — это не обсуждается. Без корректных SPF и DKIM ваши письма клиентам будут падать в спам. А хуже другое: кто-то запросто подделает вашего гендиректора и разошлёт «срочно оплатите счёт» прямо от имени вашего домена. DMARC с политикой reject этот сценарий закрывает.

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

Почему спамер тоже может настроить у себя идеальный DMARC

Расскажу случай, который когда-то поставил меня в тупик — пока не разобрался. Клиент, небольшая юрфирма человек на пятнадцать, жалуется: письма от каких-то «поставщиков офисной техники» с левыми ссылками проходят прямо во входящие — и это при том, что DMARC у них настроен строго. Лезу в заголовки письма. SPF pass, DKIM pass, DMARC pass. Всё чисто, как в учебнике.

Дело в том, что спамер тоже не идиот. Он зарегистрировал собственный домен и настроил на нём собственные SPF, DKIM и DMARC — абсолютно корректно. Письмо технически подлинное: пришло именно с того IP, с которого должно было прийти, подпись совпадает. Просто содержимое — фишинг. Протоколы аутентификации проверяют личность отправителя. Не то, что он написал и зачем.

Хорошая аналогия — проверка паспорта на входе в бизнес-центр. Паспорт настоящий, человек действительно тот, за кого себя выдаёт. Но что у него в портфеле — это уже вопрос другой службы. SPF, DKIM, DMARC — это ресепшн с паспортным контролем. А нужна ещё служба безопасности, которая смотрит в портфель.

Что реально фильтрует входящую почту: rspamd

Вот тут начинается настоящая работа. На большинстве серверов, которые я настраиваю — в связке mailcow-dockerized — фильтрацией занимается rspamd. Это движок, который прогоняет каждое входящее письмо через десятки проверок одновременно и выдаёт числовой скор. Грубо говоря: письмо с 15 баллами — почти наверняка спам, с минус 3 — почти наверняка легитимное.

Что именно он проверяет. Репутацию отправляющего IP по чёрным спискам RBL — их штук пятнадцать разных, от Spamhaus до SORBS. Соответствие содержимого письма и его заголовков: если в теме кириллица, а кодировка в заголовке от другого языка — плюс к скору. Байесовский фильтр — обучаемая штука, которая запоминает, какие слова и фразы именно у вас в компании чаще всего встречаются в спаме, и со временем начинает узнавать паттерны сама. Ссылки в письме тоже проверяет: смотрит репутацию доменов, ищет маскировку под банки и госсайты.

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

SpamAssassin — старый конь, но кое-где ещё пашет

На старых серверах, которые ко мне приходят в наследство от предыдущих админов, нередко стоит SpamAssassin. Штука постарше rspamd, принцип похожий: набор правил, каждое добавляет или вычитает баллы, в конце — сравнение с порогом. Разница в том, что SpamAssassin менее гибкий и заметно прожорливее по ресурсам. На сервере с большим потоком писем он реально упирается в CPU — на нашей практике это видно очень отчётливо.

Я обычно советую мигрировать на rspamd, если сервер потянет докеризацию. Он быстрее, у него человеческий веб-интерфейс для управления правилами, и с ClamAV в связке антивирусная проверка вложений идёт параллельно, а не последовательно. Но если у клиента древний почтовик на голом Postfix и перестраивать инфраструктуру нет возможности — дорабатывать SpamAssassin вполне разумно. Зачем ломать то, что худо-бедно едет.

Была история с производственной компанией — сорок рабочих мест, сервер 2016 года, никто не трогал годами. SpamAssassin стоял, но с настройками по умолчанию, база правил не обновлялась три года. Обновил базы, подправил пороги — количество спама во входящих упало примерно в четыре раза буквально за неделю. Без единой замены железа.

Кейс: бухгалтерская фирма и письма от «налоговой»

Ещё один показательный случай — бухгалтерская компания, восемь человек, аутсорсинговое обслуживание клиентов. Начали приходить письма якобы от ФНС: корректный домен-подделка, никаких ошибок в тексте, вложение — архив с якобы требованием. SPF и DKIM у отправителя были настроены идеально, потому что домен зарегистрировали буквально накануне рассылки и всё правильно под себя подстроили.

Стандартные DNS-проверки такое письмо пропускают — и всё. Спасло только то, что на сервере уже стоял rspamd с активным ClamAV-сканированием вложений и репутационной проверкой доменов моложе тридцати дней. Есть у rspamd такой модуль: смотрит возраст домена через whois и режет молодые домены баллами. Письмо ушло в карантин. Бухгалтер даже не увидел архив.

После того случая я всем клиентам из бухгалтерии и юриспруденции, которые получают много писем от новых контрагентов, ставлю именно этот модуль. Проверка возраста домена плюс повышенная настороженность к архивам с двойным расширением — .pdf.exe и подобным. Звучит как мелочь. Но на нашей практике именно такие мелочи ловят целевые атаки — не массовые рассылки, а точечные, заточенные под конкретную компанию.

Облачный фильтр или свой сервер: что выбрать

Здесь всё упирается в два вопроса: бюджет и количество почтовых ящиков. Работаете на Яндекс 360 или Mail.ru для бизнеса? Тогда облачная антиспам-фильтрация уже встроена и работает вполне прилично — городить что-то отдельное не нужно, максимум докрутить правила в административной панели. Цена вопроса — пара сотен рублей на пользователя в месяц. Для компании до пятнадцати человек поднимать ради этого собственный сервер просто нет смысла, ни экономического, ни практического.

Другая история — собственный почтовый сервер на железе или арендованном VPS. Именно так устроено у большинства моих клиентов с 20–50 рабочими местами. Там rspamd или SpamAssassin ставится один раз. Дальше — разовая настройка плюс периодическое обновление баз, это час-полтора моей работы в месяц, если всё изначально подкручено правильно. К своему серверу также можно подключить Kaspersky Security для почтовых серверов отдельным модулем — для медклиник, которые работают с персональными данными пациентов, это уже не опция, а требование регулятора.

Мой стандартный рецепт — гибрид. Базовый антиспам через rspamd на сервере плюс антивирус ClamAV для проверки вложений. Если отрасль критичная — медицина, юриспруденция, финансы — добавляю DLP-проверку исходящих вложений. Но это уже отдельная тема, к спаму отношения не имеет.

С чего начать, если у вас только SPF и DKIM

Начните с простого: проверьте, работает ли вообще хоть какая-то входящая фильтрация. Звучит очевидно, но на практике нередко выясняется, что на сервере стоит голый Postfix, который принимает всё подряд без разбора. Проверяется за десять минут — открываете конфиг main.cf, находите строчку smtpd_recipient_restrictions и смотрите, есть ли там хоть что-то помимо базовой проверки на существование получателя.

Если инфраструктура позволяет — ставим rspamd. Для связки Postfix и Dovecot он интегрируется через milter довольно безболезненно, без переустановки всего почтового стека. Настраиваем базовые RBL-списки, включаем байесовский фильтр и даём ему две-три недели поучиться на реальном потоке писем, вручную помечая ложные срабатывания. Этот шаг многие пропускают — зря. Без обучения фильтр работает процентов на шестьдесят своей мощности. С нормальным обучением — на девяносто пять.

И последнее, про что часто забывают: настройте карантин, а не немедленное удаление. Мы сталкивались с этим не раз — клиент выставлял жёсткий порог срабатывания, и легитимное письмо от важного контрагента улетало в корзину безвозвратно. Карантин на семь-десять дней с еженедельным просмотром со стороны администратора полностью закрывает эту проблему. Ничего важного не потеряется.

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

Если у меня настроены SPF, DKIM и DMARC, нужен ли вообще отдельный антиспам-фильтр?
Да, обязательно. SPF/DKIM/DMARC проверяют подлинность отправителя, но никак не анализируют содержимое письма и репутацию домена в целом. Спамер вполне может настроить у себя все три протокола идеально правильно и всё равно рассылать мусор или фишинг. Фильтрация содержимого — это отдельная задача, и решает её именно rspamd, SpamAssassin или облачный сервис.

Сколько стоит настроить rspamd на существующем почтовом сервере?
Если сервер уже на Postfix и Dovecot, установка и базовая настройка rspamd занимает у меня обычно один рабочий день, включая интеграцию с существующей инфраструктурой и первичную калибровку правил. Дальше нужно две-три недели на обучение байесовского фильтра под конкретный поток писем компании, это происходит уже в фоновом режиме без дополнительных трудозатрат.

Замедлит ли антиспам-фильтр доставку писем сотрудникам?
На современном железе задержка от анализа rspamd измеряется долями секунды и незаметна пользователям. Грейлистинг может добавить задержку в несколько минут для писем с совсем новых, ранее не встречавшихся адресов — но это разовая история, повторные письма с того же адреса проходят уже без задержки.

Стоит ли переходить с SpamAssassin на rspamd, если старый фильтр вроде работает?
Если сервер справляется по нагрузке и спама приходит немного, спешить не обязательно — сначала обновите базы правил, часто дело именно в этом. Но если сервер уже упирается в CPU или вы планируете расширять почтовую инфраструктуру, миграция на rspamd окупается за счёт меньшего потребления ресурсов и более гибкой настройки через веб-интерфейс.