Open-source и свой сервер 4 мин чтения

Мёртвые адреса губят рассылку: чистим базу check-if-email-exists

Reacher (check-if-email-exists) проверяет, существует ли почтовый адрес, и не отправляет письмо. Разбираем, как он помогает чистить базу перед рассылкой и где упирается в порт 25, точность и лицензию. Отдельно про закон: проверять и писать можно только тем, у кого есть согласие.

Open Sourceemail-рассылкидоставляемость152-ФЗ
Коротко. check-if-email-exists (проект Reacher) проверяет, существует ли почтовый адрес, и не отправляет на него письмо. Работает как HTTP-сервис в Docker или как командная строка, возвращает один из четырёх статусов: safe, invalid, risky, unknown. Для чистки базы перед рассылкой это удобный инструмент, но у него три жёстких условия: открытый исходящий порт 25, ограниченная точность у крупных почтовых провайдеров и лицензия, которую нужно читать до запуска. Плюс закон: проверять и писать можно только тем, у кого есть основание и согласие на рекламу.

Чем мёртвые адреса вредят рассылке

Типичная история. В CRM лежит база за несколько лет, пять тысяч адресов. Часть людей сменила работу, часть ящиков закрыта, часть адресов набрана с опечаткой на выставке. Рассылка уходит всем, и заметная доля писем возвращается с ошибкой. Это прикидка по опыту таких баз, точный процент зависит от возраста списка.

Почтовые сервисы смотрят на долю возвратов и жалоб. Много отказов выглядит как рассылка по купленной базе, и репутация домена падает. После этого письма начинают оседать в спам и у тех, кто их ждёт. Как настроить подписи и политику домена, чтобы доставляемость держалась, я разбирал в статье про SPF, DKIM и DMARC. Чистка базы работает в паре с этой настройкой: без неё письма летят в спам даже живым адресам.

Что такое check-if-email-exists

Это проект на Rust, репозиторий reacherhq/check-if-email-exists, около 10 тысяч звёзд на GitHub. Последний релиз v0.11.7 вышел в январе 2026 года. Сервис живёт в нескольких видах: HTTP-бэкенд в Docker, бинарник для командной строки и библиотека для Rust.

Бэкенд поднимается одной командой и принимает запросы вида «проверь вот этот адрес». В ответе приходит JSON с полем is_reachable. Есть и пакетная проверка списка, по документации она доступна в самостоятельной установке.

Как идёт проверка и что значат статусы

Сначала инструмент смотрит синтаксис адреса и DNS-записи домена: принимает ли домен почту вообще. Затем подключается к почтовому серверу получателя по SMTP и выясняет, готов ли тот принять письмо для этого ящика. Само письмо не отправляется. Попутно он замечает одноразовые адреса, служебные ящики вроде support@ и admin@, домены, принимающие всё подряд (catch-all), отключённые и переполненные ящики.

Итог укладывается в четыре статуса, их значение описано в документации Reacher.

safe. Письмо с высокой вероятностью дойдёт, доля возвратов ниже 2 процентов. Редкие отказы остаются из-за чёрных списков IP.

invalid. Письмо почти наверняка не дойдёт. Эти адреса вычёркиваем сразу.

risky. Ящик есть, но возможны проблемы: одноразовая почта, общий адрес, домен catch-all, полный ящик. Такие адреса отделяем в отдельный список и шлём осторожно.

unknown. Почтовый провайдер заблокировал проверку в реальном времени, определить ничего нельзя. Для рассылки это отдельная группа, к ней нужен свой подход.

Где это не сработает: порт 25, точность, лицензия

Главное практическое ограничение: исходящий порт 25 должен быть открыт. Так прямо написано в README. Именно через него идёт SMTP-диалог с чужими серверами. Документация отдельно называет ограничение провайдеров на порт 25 частой проблемой, особенно на облачных площадках. Если вы подняли сервис на обычном VPS, проверьте это до начала работы: часто порт закрыт, и проверка просто не запустится.

Второе ограничение: репутация IP. Авторы пишут, что своими адресами можно работать только при малых объёмах, для больших нужны SMTP-прокси (поддерживается SOCKS5). Важна репутация IP прокси, а не вашего. Если гонять тысячи проверок с одного адреса, он может попасть в чёрные списки. Поэтому проверку не стоит запускать с того же сервера, с которого уходит рассылка.

Третье: точность. Часть почтовых провайдеров блокирует проверку в реальном времени, и по таким адресам вы получите unknown. Домены catch-all отвечают «принимаю» на любой адрес, поэтому они попадают в risky. Какие именно крупные сервисы дают unknown чаще всего, документация не перечисляет, так что проверьте на выборке из своей базы. Кроме того, safe означает «вероятно дойдёт» и ничего не говорит о том, прочтёт ли человек письмо.

Четвёртое: лицензия. Проект выпускается по двум схемам: AGPL-3.0 для открытых проектов и коммерческая лицензия для закрытых продуктов и сервисов. По документации, если вы отдаёте ПО как веб-сервис, по AGPL придётся открыть и свой код с доработками. Пробная коммерческая версия для самостоятельной установки ограничена: внутренние тесты, 60 проверок в минуту и 10 тысяч в сутки, в рабочей среде использовать нельзя. Как документация относится к чисто внутреннему использованию по AGPL, там прямо не написано, это вопрос к юристу. Если вы встраиваете проверку в продукт для клиентов, берите коммерческую лицензию.

Какие адреса вообще можно проверять

Адрес вида ivan.petrov@компания.ru относится к конкретному человеку, а значит, чаще всего это персональные данные. Проверка адреса уже его обработка. По статье 6 закона 152-ФЗ обработка допустима, в частности, с согласия субъекта, у закона есть и другие основания, например исполнение договора. Для рассылки рекламы действует ещё и статья 18 закона «О рекламе»: реклама по сетям электросвязи допускается только при предварительном согласии адресата. Если вы не докажете, что согласие было, реклама считается разосланной без него. Требование перестать слать нужно выполнять сразу.

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

Что можно сделать уже сейчас

1. Сначала отделить тех, кто согласился. Выгрузите из CRM тех, у кого есть согласие на рассылку, и тех, кому вы писали по заказам. Остальное в проверку не отправляйте.

2. Проверить порт 25. Узнайте у хостинга, открыт ли исходящий 25-й порт. Если нет, закладывайте SMTP-прокси или другую площадку.

3. Прогнать выборку на пару сотен адресов. Посмотрите, сколько получилось unknown. Это покажет реальную точность на вашей базе до больших трат.

4. Разложить по спискам. invalid убрать, risky отправить малой партией с живым содержанием, unknown добавить в рассылку постепенно и следить за возвратами. Для самой отправки подойдёт Listmonk на своём сервере.

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

Можно ли проверять адреса без отправки письма?

Да, инструмент не отправляет письмо. Он подключается к почтовому серверу получателя и узнаёт, примет ли тот адрес. Но некоторые серверы на такой запрос не отвечают, и тогда результат unknown.

Статус safe гарантирует доставку?

Нет. По документации, доля возвратов у таких адресов ниже 2 процентов, редкие отказы остаются. Попадёт ли письмо во «Входящие», зависит ещё от репутации вашего домена и содержания.

Это бесплатно?

Исходный код открыт по AGPL-3.0, но для коммерческого использования нужна платная лицензия. Расценки на сайте Reacher я здесь не называю, они могут меняться. Плюс ваши расходы на сервер и прокси.

Коротко о главном

check-if-email-exists помогает отсеять мёртвые адреса до рассылки и разделить базу на надёжную, рискованную и неизвестную части. Условия у него жёсткие: открытый порт 25, прокси на больших объёмах, лицензия под ваш сценарий и согласие людей на рекламу.

Мы разворачиваем проверку и встраиваем её в вашу рассылку под ключ, в связке с автоматизацией бизнес-процессов: чистка базы, настройка отправки, отчёт по возвратам. Напишите мне в Telegram слово «ПРОВЕРКА», разберём вашу базу и подберём схему.

Ещё open-source для бизнеса

Эта статья — часть каталога бесплатных решений, которые я разворачиваю на вашем сервере под ключ: CRM, аналитика, документы, почта, безопасность, магазины, AI.

Услуги по теме

Что я делаю для бизнеса

  • Боты в Telegram, MAX, VK
  • Автоматизация процессов и CRM
  • Аналитика и дашборды
  • Сайты и лендинги под ключ

Бесплатно: чек-лист «Готов ли ваш бизнес к 152-ФЗ»

12 пунктов, которые проверяют готовность за час: данные, согласия, уведомление в РКН, локализация, защита. Отметьте, что уже сделано, и увидите дыры, за которые сейчас штрафуют.

Готовы обсудить вашу задачу?

Бесплатная консультация — разберём, как внедрить это в вашем бизнесе под ключ. Без форм, пишите напрямую.

Пишу о разработке, ИИ и законах для бизнеса

Разборы, кейсы и практика — без воды. Выходит регулярно, читать 3–5 минут.

Готовые решения под ключTurnkey solutionsSoluciones llave en mano交钥匙解决方案Түлхүүр гардуулах шийдэл 451 готовых IT-решений для бизнеса451 ready-made IT solutions for business451 soluciones IT listas para empresas451 个面向企业的现成 IT 解决方案Бизнест зориулсан 451 бэлэн IT шийдэл Автоматизация, боты, AI, 152-ФЗ и платформы · бесплатная консультацияAutomation, bots, AI, data privacy and platforms · free consultationAutomatización, bots, IA, privacidad de datos y plataformas · consulta gratis自动化、机器人、AI、数据合规与平台 · 免费咨询Автоматжуулалт, бот, AI, өгөгдлийн хамгаалалт ба платформ · үнэгүй зөвлөгөө Смотреть каталогView catalogVer catálogo查看目录Каталог үзэх