Антиспам на уровне почтового сервера: почему 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 он интегрируется через миллтер довольно безболезненно, без переустановки всего почтового стека. Настраиваем базовые RBL-списки, включаем байесовский фильтр и даём ему пару недель поучиться на реальном потоке писем вашей компании, вручную помечая ложные срабатывания. Это важный момент — фильтр без обучения работает процентов на шестьдесят своей мощности, с обучением — на девяносто пять.

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

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

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

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

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

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