Мониторинг чёрных списков: как узнать, что письма компании попали в спам у всех клиентов

Есть один звонок, который я запомнил на всю жизнь. Бухгалтер клиента, вторник, девять утра: «Женя, мы три дня не можем отправить акты сверки, все письма улетают в никуда». Три дня. Никто из компании этого не заметил, потому что письма уходили с сервера нормально — просто оседали в спаме у получателей или вообще не долетали. С тех пор мониторинг чёрных списков у меня в обязательном чек-листе для любого клиента с собственным почтовым доменом.

Как это вообще происходит и почему вы узнаёте последним

Механика простая и от этого обидная. Спам-фильтры вроде Spamhaus, SORBS, Barracuda Reputation Block List собирают репутацию IP-адресов и доменов по десяткам признаков: жалобы получателей, попадание в honeypot-ловушки, резкие всплески объёма рассылки, скомпрометированный сервер, с которого вдруг полез спам. Список обновляется автоматически, без предупреждений и без письма вам на почту — потому что письмо на почту, которая в блэклисте, тоже не дойдёт. Замкнутый круг.

С точки зрения отправителя всё выглядит нормально. Postfix или Exchange честно рапортует «250 OK, message queued», письмо физически ушло с сервера. А дальше принимающая сторона — Яндекс, Mail.ru, Gmail, корпоративный Exchange клиента — молча кладёт его в папку «Спам» или вообще отбрасывает на этапе SMTP-диалога с кодом 550. Отправитель эту ошибку часто даже не видит, если она произошла на стороне получателя после локального приёма.

Я насчитал в своей практике три источника, из-за которых компания попадает в списки: скомпрометированный аккаунт сотрудника, через который спамеры начинают рассылку с легитимного домена; неправильно настроенный SPF/DKIM/DMARC, из-за чего провайдеры считают домен подделкой; и банальный расшаренный IP на дешёвом хостинге, где до вас уже «наследили» соседи по серверу. Последнее, кстати, встречается чаще всего у малого бизнеса — экономят на выделенном IP, а потом удивляются.

Почему это не паранойя, а вопрос денег

Считайте сами. У юридической фирмы, о которой я говорил выше, в почте — переписка с судами, договоры с контрагентами, счета на оплату. Три дня писем, которые не дошли, это не абстрактная «репутационная потеря». Это реальный пропущенный процессуальный срок и разъярённый клиент фирмы, который был готов уходить к конкурентам.

У медклиники похожая история была с уведомлениями пациентам — не письма про суды, а результаты анализов и напоминания о записи. Когда домен клиники попал в список из-за скомпрометированного ящика администратора (пароль был вроде qwerty123, не шучу), уведомления просто перестали доходить. Никто не понял почему, пока не разобрались через две недели — обзвонили пациентов, извинились, потеряли часть из них.

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

Что конкретно проверять: домен, IP и записи DNS

Мониторить нужно минимум три вещи одновременно, потому что попасть в список можно по любой из них независимо. Во-первых, сам IP-адрес почтового сервера — против баз вроде Spamhaus ZEN, SORBS, Barracuda, UCEPROTECT. Во-вторых, домен отправителя — против доменных списков, типа Spamhaus DBL или SURBL, куда попадают за фишинговые ссылки в письмах или подделанные заголовки. В-третьих — состояние SPF, DKIM и DMARC записей, потому что провайдеры вроде Gmail с 2024 года формально требуют их наличие для массовой отправки, а без DMARC-отчётов вы вообще не узнаете, что кто-то рассылает спам от вашего имени.

На практике я использую связку: DNSBL-запросы к десятку основных списков через утилиту вроде dig или готовый Python-скрипт с библиотекой pydnsbl, плюс регулярный разбор DMARC-отчётов (aggregate reports), которые провайдеры сами присылают на адрес, указанный в записи _dmarc. Отчёты приходят в формате XML, руками их читать невозможно, нужен парсер — я использую связку self-hosted парсера, который складывает данные в базу и строит понятную картину: сколько писем ушло от имени домена, сколько прошли проверку, сколько нет и с каких IP.

Отдельно стоит проверять репутацию через сервисы вроде MXToolbox или Google Postmaster Tools — последний вообще бесценен для доменов, которые массово шлют на Gmail: показывает динамику спам-жалоб буквально по дням, ещё до реальной блокировки.

Как я это автоматизировал у себя и у клиентов

Ручная проверка через веб-формы MXToolbox работает, пока у вас один клиент. У меня на обслуживании десятки почтовых доменов на разных серверах — Postfix на Debian, mailcow-инсталляции, немного legacy на старом Zimbra. Проверять каждый руками — гарантированно что-то пропустишь.

Решение получилось простым: скрипт на Python, который раз в три часа перебирает список IP и доменов клиентов и стучится в основные DNSBL через прямые DNS-запросы — это быстро и не требует API-ключей для большинства списков. Как только IP или домен где-то всплывает, скрипт формирует сообщение и кидает его ботом в Telegram-чат дежурного инженера. Отдельным заданием раз в сутки разбираются DMARC aggregate-отчёты — если вижу, что кто-то слева пытается слать письма от чужого домена, это сразу видно по IP, не совпадающему с легитимными серверами клиента.

Запускается всё через systemd timer, никакого отдельного сервера под это не нужно — обычная VPS тянет мониторинг сотни доменов без напряга. Важный момент: алерт должен приходить не на почту того же домена, который проверяется, — очевидная вещь, но я видел настройки, где уведомление о блокировке домена уходило на ящик в этом же домене. Как это письмо дойдёт, если домен как раз в блэклисте?

Что делать, когда вы всё-таки попали в список

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

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

После устранения причины подаёте заявку на исключение из списка — у большинства DNSBL это форма на сайте, ответ приходит от нескольких часов до пары суток. У Spamhaus, к примеру, если IP уже устранил проблему, delisting часто автоматический в течение 24 часов. Но если игнорировать первопричину и просто скандалить в форме «уберите нас, мы не спамеры» — заявку просто отклонят, и правильно сделают.

DKIM, SPF, DMARC — три буквы, которые экономят нервы

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

Без DMARC вы буквально не видите, что происходит с вашим доменом за пределами собственного сервера. У одного клиента из торговой сферы выяснилось через отчёты, что кто-то третий уже полгода рассылал фишинговые письма от их домена клиентам — просто потому что SPF был настроен так широко («разрешено всем»), что подделать отправителя не составляло труда. Спам-фильтры это в итоге заметили и понизили репутацию всего домена, хотя сама компания рассылок не вела.

Настройка занимает час работы для человека, который умеет читать DNS-записи, и всё. С p=none в DMARC для начала — только собирать отчёты, не блокируя ничего, — а через месяц-два, когда убедились, что все легитимные источники писем учтены, переходите на p=quarantine и потом p=reject.

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

Сколько стоит настроить такой мониторинг для небольшой компании?
Если делать своими силами на существующей VPS — это часы работы инженера на скрипт и настройку алертов, разовая история без ежемесячной подписки. Готовые сервисы мониторинга репутации домена обычно берут от 1500 до 5000 рублей в месяц в зависимости от числа доменов и глубины отчётов. Для одного-двух доменов я обычно советую самописный вариант — окупается за первую же предотвращённую блокировку.

Мы отправляем письма через Яндекс.Почту для бизнеса, нам это вообще актуально?
Да, причём в чём-то даже больше. Вы не контролируете IP отправки напрямую, но это не защищает от блокировки конкретно вашего домена в доменных списках — например, если через ваш ящик кто-то один раз разошлёт спам после взлома пароля. DMARC-отчёты и проверку домена всё равно стоит настроить, IP тут просто не ваша забота, это забота Яндекса.

Как быстро снимают из чёрного списка после устранения проблемы?
Разброс большой. Автоматические списки вроде Spamhaus ZEN снимают IP за несколько часов после того, как проблема ушла и повторных инцидентов нет. Списки, которые требуют ручной модерации заявки на delisting, могут отвечать от суток до недели. Хуже всего с внутренними спам-фильтрами крупных провайдеров типа Mail.ru — там нет прозрачной процедуры, только форма обратной связи и ожидание.

Можно ли обойтись без мониторинга, если писем немного?
Формально да, но риск не в объёме писем, а в цене одного пропущенного. Если у вас три письма в день и одно из них — счёт крупному клиенту на оплату, попадание в список вы заметите ровно тогда, когда клиент спросит, куда пропал счёт. Небольшой объём переписки — не защита от блокировки, IP и домен репутацию теряют не по вашему объёму, а по тому, что происходит на общем хостинге или при взломе.