Выбор RBL и DNSBL: какие чёрные списки реально работают и как не блокировать своих
Наивная схема «любое совпадение в DNSBL — reject» бьёт по вашим же клиентам сильнее, чем по спамерам. Разбираем, какие зонные списки держать на reject, какие только на score, как читать return-коды 127.0.0.x и как выставить правильные веса в postscreen и SpamAssassin.
EvilMail Team21 июля 2026 г.11 мин чтения
Почему «включить все DNSBL на reject» — это выстрел себе в ногу
Классический тикет, который я разбирал десятки раз: «письмо от нашего подрядчика не доходит, а они клянутся, что отправляют». Лезешь в лог — и видишь 550 5.7.1 Service unavailable; client host [x.x.x.x] blocked using dnsbl-3.uceprotect.net. Подрядчик ничего не рассылал. Просто их сервер стоит в дата-центре, где в соседней стойке кто-то держал скомпрометированный хост, и UCEPROTECT Level 3 забанил всю автономную систему целиком. Ваш почтовик честно отработал правило — и легитимный отправитель ушёл в отбой.
Это и есть главная ошибка в работе с чёрными списками: относиться к DNSBL как к бинарному вердикту «виновен / невиновен». На практике DNSBL — это входной сигнал для скоринга, а не приговор. Есть ровно одно-два исключения, которым можно доверить reject в одиночку. Всё остальное должно складываться в очки, и только сумма очков принимает решение.
Второй миф, который надо сломать сразу: «больше списков — лучше защита». Нет. Каждый добавленный агрессивный список увеличивает вероятность ложной блокировки нелинейно, а прирост пойманного спама после третьего качественного листа стремится к нулю. Два-три точных зонных списка в связке со скорингом ловят подавляющую часть мусора. Дальше вы покупаете себе не защиту, а тикеты вида «почему не дошло письмо от важного клиента».
Ниже — какие списки держать, как читать их ответы, и как разложить всё это по весам так, чтобы одиночное совпадение не рубило легитимную почту.
Выбор RBL и DNSBL: рабочие чёрные списки, веса и защита от ложных блокировок — EvilMail Blog
Как устроен DNSBL-запрос и почему return-код решает всё
Механика простая. Берём IP отправителя, разворачиваем октеты, приклеиваем суффикс зоны и делаем обычный DNS-запрос A-записи. Для IP 203.0.113.45 и зоны Spamhaus ZEN запрос выглядит так:
bash
# 203.0.113.45 -> 45.113.0.203 + .zen.spamhaus.org
dig +short 45.113.0.203.zen.spamhaus.org A
# если IP в листе -> вернётся 127.0.0.x
dig +short 45.113.0.203.zen.spamhaus.org TXT
# TXT содержит причину и ссылку на страницу делистинга
Ключевой момент, который игнорирует большинство «включил и забыл» конфигов: ответ 127.0.0.x — это не флаг, это категория. У Spamhaus:
127.0.0.2 — SBL, ручной листинг известного спам-источника
127.0.0.3 — SBL CSS, автоматический листинг источников с устойчиво низкой репутацией
127.0.0.4–.7 — XBL (бывший CBL): заражённые/эксплуатируемые машины, open proxy
127.0.0.9 — SBL DROP, захваченные или «арендованные под спам» сети (не маршрутизировать вовсе)
127.0.0.11 — PBL, policy-листинг самого провайдера («тут не должно быть прямой отправки»)
Разница принципиальная. Попадание в .2 или .4 — это реальный спам-сигнал. Попадание в .10/.11 (PBL) означает всего лишь «этот IP не предназначен для прямой отправки почты» — что абсолютно нормально для многих легитимных, но неправильно настроенных отправителей. Схема «есть A-запись → блок» уравнивает пойманный ботнет и бабушкин роутер.
Отдельная ловушка — код 127.0.0.1 и диапазон 127.255.255.x. Если Spamhaus или SpamCop возвращает вам такое, ваш IP тут ни при чём — это значит, что вы сами делаете запросы неправильно:
127.255.255.252 — ошибка в запросе (typo)
127.255.255.254 — вы ходите через публичный резолвер (8.8.8.8, 1.1.1.1) или без DQS-ключа
127.255.255.255 — rate limit, вас режут за объём
Да, Google DNS и Cloudflare забанены в Spamhaus. Если ваш Postfix настроен на публичный резолвер, вы получаете 127.255.255.254 на каждый запрос — и в худшем сценарии наивный конфиг трактует это как листинг и блокирует всех подряд. Нужен собственный рекурсивный резолвер (unbound/bind на localhost) или платный DQS-ключ с запросами вида <key>.zen.dq.spamhaus.net.
Список списков: кого держать, кого выкинуть
Разбор по категориям с вердиктом каждому. Это моя рабочая позиция на 2026 год, а не паспорт качества на все времена — списки деградируют, и ревизовать их надо раз в квартал.
Spamhaus ZEN (zen.spamhaus.org) — рабочая лошадь. Комбинированная зона SBL+XBL+PBL+CSS в одном запросе, очень низкий процент ложных срабатываний. Единственная зона, которой я доверяю reject в одиночку. Требует собственного резолвера или DQS-ключа, потому что на бесплатном публичном DNS её не поднять.
Barracuda (b.barracudacentral.org) — хороший независимый сигнал, но требует бесплатной регистрации отправляющего IP на их портале, иначе запросы не обслуживаются. Только на score.
SpamCop (bl.spamcop.net) — агрессивный, живёт на автоматических спам-трапах, авто-делистинг за 24–48 часов. Ловит быстро, но и ложняков даёт больше. Только на score, никогда на reject.
SORBS (dnsbl.sorbs.net) — исторически уважаемый, но к 2024 году деградировал: устаревшие листинги, нестабильность зоны, медленный делистинг. Не рекомендую тащить в прод; если оставляете — минимальный вес.
UCEPROTECT L2/L3 (dnsbl-2/-3.uceprotect.net) — L2 банит по /24, L3 — по всей автономной системе. Плюс платный «экспресс-делистинг», то есть у оператора списка прямой финансовый интерес держать в бане как можно больше диапазонов. Это конфликт интересов, а не антиспам. Только с крошечным весом на score или, честнее, выкинуть совсем.
DBL (dbl.spamhaus.org) и URIBL/SURBL — это другой класс: они про домены и URI в теле письма, а не про IP. Крайне полезны, но живут в контентном фильтре (SpamAssassin), а не в postscreen.
DNSWL (list.dnswl.org) — это белый список, а не чёрный. Даёт отрицательные очки известным легитимным отправителям и спасает от ложных reject. Обязателен.
Правило одной строкой: reject только на комбинированные высокоточные зоны (ZEN); всё остальное — веса.
Правильные веса: скоринг вместо приговора
Двухуровневая архитектура. postscreen работает на TCP-уровне ещё до команды DATA — это дёшево и отсекает ботнеты, не доводя дело до приёма тела письма. Контентные списки (URIBL/SURBL/DBL) живут в SpamAssassin, потому что им нужен доступ к телу и заголовкам.
Логика вся в арифметике. Порог 3. ZEN весит 3 — то есть попадание в ZEN само по себе рубит соединение, и это осознанное решение (доверяем зоне). А вот SpamCop (2) или SORBS (1) поодиночке порога не достигают — одиночное совпадение в агрессивном листе не блокирует. Но SpamCop + Barracuda вместе дают 4 → reject. Идея в том, что два независимых списка, согласившихся между собой, — это уже сигнал, которому можно верить, а один — нет.
DNSWL работает в обратную сторону: чем выше уровень доверия отправителя, тем более отрицательный вес (-2 до -5). А postscreen_dnsbl_whitelist_threshold = -1 означает, что при суммарном счёте ≤ -1 соединение получает whitelist-статус и проходит без дальнейших проверок. Так письмо от известного банка не отобьётся, даже если его IP случайно всплыл в SpamCop.
Контентный уровень настраивается в /etc/mail/spamassassin/local.cf:
URIBL-правила бьют по доменам в теле письма, а спамеры куда чаще меняют отправляющий IP, чем домен посадочной страницы, поэтому URIBL часто точнее IP-листов. Веса 1.5–3 — разумный диапазон; выше 3 на один DNS-фактор задирать не стоит.
Ложные блокировки: поймать до того, как поймают вас
Никогда не включайте новый список сразу на enforce. Прогоните его в режиме наблюдения минимум неделю:
ini
# только логировать совпадения, ничего не блокировать
postscreen_dnsbl_action = ignore
Смотрите в лог, кого бы вы забанили, и сверяйте с реальностью. Типичные источники ложняков, которые вы увидите:
Shared hosting и облачные IP. AWS, Hetzner, DigitalOcean переиспользуют адреса; вам достаётся IP, который вчера принадлежал спамеру и ещё висит в SpamCop.
Forwarders и рассылочные списки. Сервер, который пересылает чужую почту, ловит чужую же репутацию.
Взаимодействие с greylisting. Отправитель ретраится с другого IP пула, и один из адресов оказывается в PBL.
Метрика, за которой надо следить, — соотношение доли reject по DNSBL к числу жалоб на недоставку. Если reject-ов много, а жалоб нет — хорошо. Если жалобы растут — у вас ложняки, и порог/веса надо пересматривать. Именно DNSWL с отрицательными весами и whitelist_threshold спасают здесь чаще всего.
Обратная сторона: когда в списке ваш IP
Для нас на evilmail.pro это не абстракция. Temp-email инфраструктура по своей природе живёт под постоянным риском листинга: стоит одному абьюзеру прогнать через диапазон что-то мусорное — и вы в PBL или SBL. Поэтому мы смотрим на DNSBL с двух сторон: как потребитель сигнала и как потенциальная жертва. Это ещё один аргумент за score-подход, а не за reject: тот, кто сам знает цену ложному листингу, не будет рубить чужую почту по одному совпадению.
Проверка себя:
bash
# по каждой зоне вручную
dig +short 45.113.0.203.zen.spamhaus.org
# или разом через агрегаторы
# multirbl.valli.org / mxtoolbox.com/blacklists
Порядок делистинга всегда один: сначала устранить причину, потом просить снять. Если вы запросите делистинг при живом open relay или скомпрометированном аккаунте, вас залистят обратно за часы, и повторный делистинг будет медленнее. Причина — это обычно open relay, взломанный SMTP-аккаунт клиента или пользователь, рассылающий спам через ваш сервер.
Профилактика policy/PBL-листингов — гигиена DNS отправителя:
Корректный PTR/rDNS, совпадающий с HELO-именем. Generic-имя вида 45-113-0-203.pool.isp.net — прямая дорога в PBL.
SPF с -all или ~all.
DKIM-подпись на весь исходящий поток.
DMARC с политикой p=quarantine или reject.
И отдельно: не платите UCEPROTECT за экспресс-делистинг. Вы финансируете модель, где оператор зарабатывает на банах, и приучаете себя к тому, что проблему можно «купить» вместо того, чтобы починить. Естественный делистинг из L2/L3 происходит сам, когда прекращается абьюз в диапазоне.
Чек-лист внедрения
Поднимите собственный рекурсивный резолвер (unbound/bind на localhost) или возьмите Spamhaus DQS-ключ. Никаких 8.8.8.8/1.1.1.1 для DNSBL.
Стартуйте в режиме postscreen_dnsbl_action = ignore минимум на неделю — сначала наблюдение, потом enforce.
На reject — только zen.spamhaus.org (вес 3). Больше ни одна зона не рубит в одиночку.
Barracuda, SpamCop — только на score (веса 2). Зарегистрируйте IP для Barracuda.
Подключите list.dnswl.org с отрицательными весами и postscreen_dnsbl_whitelist_threshold = -1.
Держите порог reject ≥ 3, чтобы одиночное совпадение PBL не блокировало легитимную почту.
Учитывайте семантику return-кодов; не приравнивайте PBL (.10/.11) к спам-источникам (.2/.4).
Контентные списки (URIBL/SURBL/DBL) — в SpamAssassin с весами 1.5–3, не в postscreen.
Настройте PTR/SPF/DKIM/DMARC на исходящем потоке — это профилактика листинга вас самих.
Ревизуйте состав списков раз в квартал: SORBS и UCEPROTECT деградируют, и то, что было хорошим сигналом в 2019-м, в 2026-м может стать источником ложняков.
Чёрные списки — это не тумблер «вкл/выкл», а система весов, которую вы настраиваете под свой поток. Два-три точных списка плюс DNSWL плюс скоринг закрывают 90% задачи. Всё, что сверх этого, вы платите не спамерам, а собственным клиентам, чьи письма ушли в отбой.
