Сервисы проверки email часто рекламируют одну цифру точности: 97%, 98%, 99%. Без пояснений такая цифра мало что говорит, поскольку объединяет проверки с очень разной надёжностью.
Часть проверок даёт конкретный результат. Наличие MX-записей можно установить запросом к DNS, хотя ответ зависит от доступности сервера и актуальности кеша. Существование отдельного ящика за этими записями уже нельзя надёжно подтвердить одним внешним запросом. Особенно ограничены возможности такой проверки у крупных провайдеров.
Чтобы пользоваться результатами осмысленно, нужно понимать, на каком основании вынесено заключение. Разберём, что проверки действительно устанавливают, на что лишь указывают и где их возможностей не хватает.
Почему важна доля возвратов
Провайдеры получателей учитывают, сколько писем отправитель направляет на несуществующие адреса. Высокая доля постоянных отказов в доставке может указывать на плохо поддерживаемую базу. Она повышает риск ограничений и фильтрации наряду с жалобами, аутентификацией и другими факторами, но сама по себе не доказывает покупку списка.
В исходной статье доля постоянных отказов выше 2% приведена как тревожный ориентир. Это не универсальный порог и не установленный Google лимит возвратов. Рекомендации Google для отправителей требуют следить за качеством отправки, аутентификацией и жалобами; жалобы и возвраты являются разными показателями. Последствия не всегда заканчиваются вместе с кампанией: ухудшение репутации может затронуть следующие отправки, включая счета, сброс пароля и подтверждения заказов. Сроки и масштаб зависят от провайдера.
Проверка адресов помогает уменьшить этот риск. Она не улучшает текст письма и не заменяет согласие получателя. Её задача состоит в том, чтобы выявить часть проблем до отправки, а не гарантировать доставку. Подробнее о показателях рассказываем в статье о том, что означает доля возвратов.
Три уровня достоверности проверки email
Если разделить проверки по тому, насколько можно полагаться на их результат, картина станет понятнее.
Уровень 1: непосредственные проверки
Здесь проверяются формат, DNS и записи в известных списках. Результат относится к конкретному правилу и доступным данным, а не ко всем свойствам адреса сразу.
| Проверка | Что она устанавливает |
|---|---|
| Синтаксис | Адрес соответствует правилам формата, которые поддерживает валидатор |
| Punycode / IDN | Адрес проходит ограничения сервиса на международные домены; это не доказательство отсутствия всех похожих доменов и подмен |
| MX-записи | В DNS найдены почтовые маршруты; это не подтверждает работоспособность сервера или отдельного ящика |
| Доступный извне IP для MX | MX не направляет на закрытые диапазоны вроде 10.x или адреса обратной петли вроде 127.x |
| Временный почтовый домен | Домен найден в списке известных сервисов временной почты; в оригинале указано более 5,000 записей, фактический состав меняется |
| Наличие в DNSBL | Домен найден в Spamhaus DBL или SURBL; это отдельный сигнал репутации, а не доказательство отсутствия ящика |
| Исключение после возврата | Адрес уже отмечен в списке исключений вашего аккаунта после постоянного отказа |
Отказ на этом этапе может сразу привести к статусу «недействителен» по правилам сервиса. Но не стоит подменять это универсальным выводом о доставке. Например, валидатор требует MX, тогда как SMTP допускает неявный почтовый маршрут через адресные записи домена при отсутствии MX. А фильтр международных доменов может исключить вполне существующий адрес. Для важных решений смотрите конкретную причину отказа.
Уровень 2: вероятностные проверки
SMTP-проверка подключается к принимающему серверу, начинает обмен командами, спрашивает, примет ли сервер указанного получателя, и отключается до передачи письма. Ответ 550 на RCPT TO с явным указанием, что получатель не найден, даёт веское основание считать ящик отсутствующим. Сам код может также означать запрет доступа или отказ по политике.
Это свидетельство, а не безусловное доказательство. Надёжность зависит от принимающего сервера, о чём и пойдёт речь дальше.
Уровень 3: эвристики
Это косвенные признаки риска. Они влияют на оценку по правилам сервиса, но не доказывают, что адрес плохой:
| Признак | Влияние на оценку |
|---|---|
| Похоже на случайный набор символов до @ | −15 |
| Нет SPF-записи | −10 |
| Нет DMARC-записи | −10 |
| Домен зарегистрирован менее 30 дней назад | −10 |
Адрес с дополнительной меткой (user+tag@) | −5 |
| Собственный домен с MX, SPF и DMARC | +5 |
Адрес отдела или службы (info@, support@) | 0, отмечается без снижения оценки |
| Бесплатный провайдер (Gmail, Yahoo) | 0, нейтральный признак |
Вероятная опечатка (gmial.com) | 0, подсказка с предложением исправления |
Два признака заслуживают отдельного пояснения, поскольку у других поставщиков подход может отличаться.
Адреса отделов не снижают оценку. Через info@ и sales@ компании действительно получают почту. Для холодного обращения такой адрес может означать, что вы не знаете конкретного человека, но для других задач это не недостаток. Сервис отмечает признак, чтобы вы могли использовать его как фильтр, не вычитая баллы.
Бесплатные провайдеры оцениваются нейтрально. Адрес Gmail сам по себе не хуже адреса на собственном домене. Такой почтой пользуются многие реальные люди.
SMTP-проверка и её ограничения
Именно эту процедуру часто представляют, говоря о проверке email. При этом ожидания от неё нередко превышают реальные возможности.
Она может быть полезна для корпоративных доменов: собственных серверов компаний, почтового хостинга и самостоятельно размещённых систем. Если сервер явно отклоняет неизвестного получателя на этапе RCPT TO, это содержательный результат. Однако отказ может относиться и к самому проверочному подключению, а не к ящику.
Для крупных публичных сервисов такая проверка не является надёжным способом установить существование ящика. Gmail, Yahoo, Outlook.com, iCloud и AOL могут ограничивать проверочные подключения, принимать получателя без окончательной проверки или иначе препятствовать перебору адресов. Нельзя утверждать, что все они всегда отвечают одинаково. В нашем сервисе соответствующие домены исключены из внешней SMTP-проверки; пройденные остальные проверки не подтверждают наличие ящика.
Поэтому глубокая проверка адреса из списка исключённых доменов тарифицируется здесь как быстрая: один кредит, а не два. Дополнительная SMTP-проверка для него пропускается. Разделение стоимости показывается перед запуском и возвращается в ответе API; проверьте текущий расчёт для выбранных адресов.
Итог такой: на подходящем корпоративном сервере SMTP-проверка может добавить уверенности. Для Gmail и подобных сервисов она не даёт общей гарантии существования ящика. Если поставщик обещает точный ответ, выясните, какими данными он располагает и какие ограничения у метода.
Почему catch-all затрудняет проверку email
Домен с catch-all принимает почту на любые имена получателей, даже если отдельного ящика нет. Запрос о anything@catchall-domain.com поэтому может получить положительный ответ. По одному такому ответу нельзя определить, существует ли нужный ящик.
Результат catch-all означает неопределённость. Письмо может попасть к человеку, в непросматриваемый общий ящик или в другой обработчик; сам признак не доказывает наличие спам-ловушки. Внешняя проверка не различает эти варианты. Читайте флаг catch-all отдельно от итогового статуса: в текущем расчёте он не обязательно переводит адрес в категорию риска.
Это один из менее очевидных компромиссов catch-all на собственном домене: внешнему проверяющему сложнее подтвердить адрес. Для контекста полезна статья о том, как работает почта catch-all, где разобраны и другие особенности.
Быстрая и глубокая проверка
| Быстрая | Глубокая | |
|---|---|---|
| Число проверок в исходном описании | 22 | 25 |
| SMTP-проверка ящика | Нет | Да, для подходящих доменов, не включённых в исключения |
| Эвристика спам-ловушек | Нет | Да |
| Кредиты за адрес корпоративного домена | 1 | 2 |
| Кредиты за адрес исключённого публичного провайдера | 1 | 1 |
| Ориентир для 10,000 адресов | 1-5 минут | 5-15 минут |
| Когда использовать | Регулярная проверка известного списка | Внешние или унаследованные списки после проверки права на отправку, особо важные кампании |
Для собственного поддерживаемого списка обычно достаточно быстрой проверки. Если происхождение списка неизвестно, сначала разберитесь с разрешением на отправку, а затем определите, нужны ли дополнительные проверки. Число выполненных проверок и время зависят от ранних отказов, настроек, очереди и ответов серверов. Таблица не обещает выполнить все проверки для каждого адреса.
Как читать статусы
Каждый адрес получает статус и оценку доверия от 0 до 100. Это внутренняя шкала, а не вероятность доставки.
| Статус | Оценка | Что делать |
|---|---|---|
| Безопасный | 90-100 | Можно рассматривать для отправки при наличии согласия; доставка не гарантирована |
| Действительный | 60-89 | Учитывайте основания результата и следите за возвратами |
| Рискованный | 20-59 | Не используйте для холодных обращений; сервисные письма известным получателям требуют оценки конкретной причины |
| Недействительный | 0-19 | Исключите из отправки и изучите причину |
| Неизвестно | Не указана в таблице | Если показан такой статус, повторите проверку позже. Тайм-ауты и временные ошибки также ищите в отдельных флагах. |
Особенно важно различать рискованный и недействительный адрес. Недействительный статус может означать отказ по правилам валидатора, запись в исключениях или отказ сервера, а не всегда отсутствие ящика. Риск тоже требует контекста. Неопределённый адрес из купленного списка не становится допустимым для отправки после проверки. У клиента, который платит вам два года, тот же результат может объясняться catch-all, но нужно проверить конкретные флаги, историю доставки и канал связи, прежде чем отправлять счета.
Проверка не знает ваших отношений с получателем. Эти сведения нужно учитывать отдельно.
Списки устаревают, поэтому проверка email должна быть регулярной
В оригинале приведён ориентир устаревания списка примерно на 2% в месяц: люди меняют работу, компании закрываются, адресами перестают пользоваться. Реальный темп различается. За восемнадцать месяцев доля устаревших записей может стать значительной, но утверждение о четверти неверных адресов нельзя считать универсальным прогнозом. Ориентируйтесь на собственные результаты и возвраты.
Поэтому проверку лучше включить в обслуживание базы, а не проводить только один раз:
- При вводе адреса. Проверка на регистрации помогает заметить опечатку вроде
gmial.com, пока человек ещё может её исправить. Предлагайте исправление, а не заменяйте адрес молча. - Перед крупной отправкой. Особенно для сегмента, которому давно не писали.
- Ежеквартально для активной базы. Это исходный ориентир; частоту стоит менять по фактическому состоянию списка.
- При получении унаследованного списка. После покупки компании, объединения или передачи таблицы от коллеги проверьте и адреса, и основания для отправки.
Как организовать проверку
Проверяйте адрес при вводе, а не постфактум. Опечатку на регистрации можно исправить вместе с человеком. Через полгода восстановить контакт будет сложнее. Проверка формата и репутации не заменяет подтверждения адреса самим пользователем.
Исключайте из отправки, а не просто удаляйте. Сохраняйте необходимую запись в списке исключений, чтобы адрес не вернулся в рассылку после следующей загрузки CSV. Учитывайте правила хранения данных и возможность исправить ошибочное исключение.
Не покупайте списки. Проверка выявляет часть технических проблем, но не подтверждает согласие человека получать ваши письма. Даже действительные адреса могут привести к жалобам и проблемам с соблюдением применимых правил. Прошедший проверку купленный список не становится разрешением на рассылку.
После долгого перерыва увеличивайте объём постепенно. Одной чистки базы недостаточно. Следите за реакцией получателей и ответами серверов, а не только за числом удалённых адресов. Подробнее рассказываем в статье о повышении доставляемости.
Проверка email не исправляет плохую практику отправки. Она уменьшает часть рисков, связанных с адресами, но не настраивает ваши SPF, DKIM или DMARC. Принимающий сервер учитывает аутентификацию, репутацию и другие факторы; нет универсальной последовательности, которая сделает проверенный список достаточным условием доставки.
Частые вопросы
Можно ли проверкой установить, существует ли адрес Gmail?
Не надёжно с помощью обычного внешнего SMTP-запроса. Провайдеры могут ограничивать такие подключения и скрывать сведения о получателях; их ответы не обязаны быть одинаковыми. Здесь Gmail включён в список пропуска SMTP-проверки. Пройденные проверки формата, MX и репутации не подтверждают существование ящика.
Почему глубокая проверка адресов Gmail стоит дешевле?
Потому что дополнительная SMTP-проверка для доменов из списка исключений пропускается. Даже внутри глубокой проверки такие адреса тарифицируются по быстрой ставке. Расчёт разделяется перед запуском; проверяйте актуальную оценку стоимости.
Что означает catch-all и стоит ли отправлять на такой адрес?
Сервер принимает произвольные имена получателей, поэтому положительный ответ не подтверждает отдельный ящик. Для известного клиента учитывайте историю доставки и назначение письма. Не используйте неопределённость как основание для холодной рассылки.
Адреса вроде info@ считаются плохими?
Нет. Этот признак не снижает оценку. Он отмечается для фильтрации, если она нужна в вашей задаче. Пригодность адреса для сервисных писем или обращений определяется контекстом, а не одним названием ящика.
Может ли проверка повредить репутации отправителя?
Проверочное подключение заканчивается до передачи письма, поэтому сообщение не попадает в почтовый ящик. Но гарантировать отсутствие любых последствий для репутации IP нельзя: массовые запросы могут восприниматься как перебор адресов и блокироваться. Для принимающих узлов предусмотрены ограничения частоты; они уменьшают риск, но не дают безусловной гарантии.
Как часто повторять проверку?
Ежеквартально для активного списка, перед крупной отправкой и при получении унаследованной базы как начальный ориентир. Пример из оригинала с устареванием на 2% в месяц не является универсальным законом. Подбирайте частоту по возрасту базы, истории доставки и фактическим изменениям адресов.
Можно ли запускать проверку через API?
Да, для отдельных адресов и массовых заданий, со статусами и результатами, доступными программно. Поддерживаемые операции и разрешения описаны в справочнике API проверки адресов.
Что на самом деле означает оценка доверия?
Расчёт начинается со 100, затем учитывает признаки риска и положительные сигналы, включая настройки домена. Жёсткие отказы могут сразу установить нулевую оценку. Это итог правил сервиса, а не независимое измерение или вероятность существования ящика. Для важного решения читайте отдельные флаги и сведения о пропущенных проверках.
