Как проверить, находится ли почтовый сервер в спам-листах

Попадание сервера в один из десятков публичных чёрных списков (RBL) часто остаётся незамеченным до тех пор, пока не просядет доставляемость по целому сегменту получателей — при этом сам список может быть локальным или редко используемым, и обнаружить проблему без целевой проверки почти невозможно. Регулярная проверка IP и домена по RBL — рутинная гигиена инфраструктуры для команды, ведущей холодный B2B-аутрич, а не разовая мера на случай аварии. Разберём, какими инструментами это делают и как встроить проверку в постоянный процесс.

Почему один список не даёт полной картины

RBL (Real-time Blackhole List) — общее название десятков независимых баз данных, которые почтовые серверы и антиспам-шлюзы используют как один из сигналов при решении, доверять ли входящему письму. Списки принципиально разные: одни (например, Spamhaus) влиятельны и используются крупными провайдерами и корпоративными шлюзами повсеместно, другие — узкоспециализированные и применяются в основном отдельными хостинг-провайдерами или корпоративными фильтрами конкретных отраслей.

Ключевое следствие для практики: проверка по одному списку, даже самому известному, не гарантирует, что сервер чист во всех остальных. Для команды, у которой сегмент получателей включает корпоративную почту с жёсткими антиспам-политиками (нередкость в некоторых отраслях B2B), попадание в малоизвестный, но используемый именно этим сегментом список может блокировать доставку так же ощутимо, как попадание в Spamhaus.

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

Инструменты для проверки по множеству списков сразу

Ручная проверка каждого списка по отдельности через его собственный lookup-инструмент занимает много времени и не масштабируется на регулярный мониторинг. Практичнее пользоваться агрегаторами, которые проверяют IP или домен сразу по десяткам-сотням баз и показывают сводный результат: где именно есть листинг, а где сервер чист.

Такие агрегаторы обычно разделяют результат на IP-адрес и на домен — оба стоит проверять по отдельности, потому что попадание может касаться только одного из них. Полезно также обращать внимание не только на факт листинга, но и на то, к какому типу список относится: репутационный (реакция на реальное поведение), политический (диапазон адресов, заведомо не предназначенный для отправки почты) или список-ловушка (реагирует на попадание в конкретные спам-трапы).

• Проверять и IP отправки, и домен — отдельно друг от друга
• Использовать агрегатор по множеству списков вместо ручной проверки каждого по отдельности
• Смотреть не только факт листинга, но и тип списка (репутационный, политический, спам-ловушка)
• Проверять все IP, задействованные в отправке, если используется несколько серверов или ротация
• Сохранять историю проверок, чтобы видеть, когда именно появился новый листинг

Как читать результат проверки

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

Листинг в широко используемом списке (Spamhaus и сопоставимые по влиятельности базы) требует немедленной реакции: диагностики причины и подачи заявки на делистинг после устранения. Между этими двумя крайностями стоит правило: если сегмент кампании включает конкретную отрасль или конкретных провайдеров с известной строгой антиспам-политикой, стоит заранее узнать, какими именно списками они пользуются, и мониторить их в первую очередь.

Регламент регулярной проверки

Проверка по факту жалоб на недоставку — запоздалая реакция: к этому моменту часть писем волны уже потеряна. Рабочий регламент — плановая проверка IP и домена по агрегатору RBL на регулярной основе, независимо от того, есть ли видимые проблемы прямо сейчас, и внеплановая проверка при любом заметном падении reply rate или росте bounce rate по кампании.

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

Что делать при обнаружении листинга

Порядок действий одинаков независимо от того, какой конкретно список сработал: сначала установить причину (объём отправки, качество базы, компрометация аккаунта, чужая активность на общем IP), затем устранить её полностью и только после этого подавать заявку на удаление через официальную форму конкретного списка — у каждого RBL она своя, но логика одна и та же.

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

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

Место рутинной проверки в общей системе доставляемости

Проверка по RBL — один из нескольких элементов гигиены инфраструктуры, наравне с мониторингом postmaster-кабинетов провайдеров, проверкой аутентификации SPF, DKIM, DMARC и посевными тестами перед новыми кампаниями. Ни один из этих элементов не заменяет остальные: RBL-проверка обнаруживает формальный листинг, postmaster-кабинеты показывают репутацию и жалобы даже без формального листинга, а посевной тест демонстрирует итоговое поведение конкретного письма у конкретного провайдера.

Для адресного B2B-аутрича, где каждая волна отправки идёт по узкому, тщательно отобранному сегменту, стоимость пропущенной проблемы с инфраструктурой выше, чем в массовой рассылке: недоставленное письмо — это не процент от большой базы, а конкретный упущенный контакт с ЛПР, который вы выбирали осознанно. Именно поэтому регулярная, а не разовая проверка списков должна быть частью стандартного регламента команды, а не реакцией на уже случившуюся просадку метрик.

Практический минимум для небольшой команды — пять минут раз в одну-две недели на проверку основного IP и домена через агрегатор, плюс внеплановая проверка при любом необъяснимом падении отклика. Этого достаточно, чтобы не пропустить проблему, которая иначе обнаружится только по факту остановленных диалогов с ключевыми контактами.

Вопросы и ответы