Проверка email в реальном времени проверяет адрес, пока пользователь ещё находится в вашей форме. Она выполняется за несколько сотен миллисекунд между нажатием «Отправить» и переходом на следующий экран и отвечает на один вопрос: должен ли этот адрес попасть в вашу базу данных? API проверки email в реальном времени принимает это решение за вас. Он анализирует синтаксис, домен и его MX-записи, признаки одноразового и ролевого адреса, поведение catch-all и, если вы запрашиваете это, сам почтовый ящик. Затем он возвращает структурированный результат, с которым может работать ваш код.
Это руководство предназначено для разработчиков, добавляющих такую проверку в форму регистрации, оформления заказа или привлечения лидов. В нём рассказывается, что делают эти проверки, как вызвать API, как превратить каждый статус в решение для продукта и как сохранить высокую скорость, если почтовый сервер работает медленно. В примерах используется API проверки email BillionVerify, но приведённые рекомендации по проектированию применимы к любому провайдеру.
Что такое проверка электронной почты в реальном времени?
Проверка электронной почты в реальном времени выполняется в момент ввода адреса, а не через несколько дней, когда начинается рассылка. Пользователь вводит адрес. Ваш frontend или backend отправляет его в API проверки электронной почты. API возвращает статус, например valid, invalid или catchall, а также связанные с ним сигналы. Затем ваше приложение разрешает регистрацию, блокирует её или просит пользователя исправить опечатку.
Главное здесь — своевременность. Опечатку вроде gmial.com ничего не стоит исправить, пока пользователь ещё находится в форме. После того как приветственное письмо возвращается с ошибкой доставки, та же опечатка обходится вам потерей клиента. Неверные адреса также вредят репутации отправителя, поскольку каждый жёсткий возврат сообщает почтовым провайдерам, что вы отправляете письма на неподтверждённые адреса. Проверка электронной почты в реальном времени не пропускает их дальше.
Она также помогает бороться с мошенничеством: проверка в реальном времени может обнаружить одноразовый почтовый ящик ещё до создания аккаунта.
Проверка электронной почты в реальном времени vs массовая проверка
Оба подхода используют одни и те же проверки. Они различаются временем выполнения и доступным временем.
- Проверка в реальном времени выполняется для одного адреса за раз в рамках запроса пользователя. У неё строгий лимит времени — часто значительно меньше секунды, поскольку медленная форма приводит к потере регистраций. Она не позволяет недостоверным данным попасть в систему.
- Массовая проверка выполняется для всего списка в фоновом режиме. Она может занимать минуты или часы, и никто не ждёт результата у экрана. Она очищает данные, которые уже находятся в вашей системе, например перед большой кампанией или после импорта в CRM.
Большинству команд нужны оба подхода. Проверки в реальном времени поддерживают чистоту новых данных, а периодическая массовая проверка выявляет адреса, которые со временем стали недействительными, например адреса сотрудников, покинувших компанию. Для более подробного сравнения см. проверка электронной почты в реальном времени и массовая проверка.
Что на самом деле проверяет проверка в реальном времени
API проверки email выполняет серию проверок — от дешёвых к более затратным. Каждая из них исключает отдельный тип недействительного адреса.
Синтаксис
Первая проверка — формат. Есть ли ровно один символ @? Состоит ли локальная часть из разрешённых символов? Похож ли домен на домен? Синтаксическая проверка отклоняет очевидный мусор, например john@@example или jane.example.com. Она выполняется быстро и не требует сетевого запроса. Но идеальный синтаксис ничего не говорит о существовании почтового ящика.
Домен и записи MX
Затем API ищет домен в DNS. Домен без записей MX не может принимать email, поэтому адрес в нём бесполезен, каким бы корректным он ни выглядел. Это позволяет обнаружить домены с опечатками и неактивные корпоративные домены. BillionVerify возвращает найденные MX-хосты в mx_records, а domain_suggestion может содержать вероятное исправление, если домен похож на опечатку в распространённом домене.
Признаки одноразовых, ролевых и бесплатных адресов
Некоторые адреса существуют, но всё же плохо подходят для вашего продукта:
- Одноразовые адреса предоставляются сервисами временных почтовых ящиков и обычно перестают работать в течение нескольких часов. См. как работает обнаружение одноразовых email.
- Ролевые адреса, такие как
info@илиsupport@, ведут к команде, а не к конкретному человеку. Обычно они доставляемы, но, как правило, реже взаимодействуют. - Адреса бесплатных провайдеров, например Gmail, нормальны для потребителей, но их стоит фиксировать в форме B2B.
API сообщает об этом с помощью флагов (is_disposable, is_role, is_free), чтобы вы могли принимать решения для каждого продукта.
Домены catch-all
Некоторые почтовые серверы принимают письма на любой адрес своего домена — существующий или нет. Для таких доменов catch-all проверка почтового ящика не может доказать существование конкретного входящего ящика. Результат catch-all не является плохим результатом. Он означает, что уверенность ниже, поэтому оценка важнее метки. В статье Обнаружение email catch-all объясняется, как это работает и почему это важно.
Проверка почтового ящика через SMTP
Самая глубокая проверка спрашивает почтовый сервер получателя по SMTP, примет ли он сообщение, не отправляя его. Она обнаруживает адреса на реальных доменах, которые больше не существуют, например почтовый ящик бывшего сотрудника. Это также самый медленный этап, поскольку он зависит от чужого сервера. В BillionVerify им управляет параметр check_smtp. Если не указывать его, API выполняет проверку SMTP; отправьте check_smtp: false, чтобы пропустить её.
Репутация домена
BillionVerify также может вернуть объект domain_reputation с результатами проверки IP-адреса почтового сервера домена по чёрным спискам. Он предназначен только для информации: не изменяет статус, оценку или стоимость.
Как вызвать API проверки электронной почты в реальном времени
С BillionVerify одна проверка в реальном времени выполняется одним HTTPS-запросом. Базовый URL — https://api.billionverify.com/v1, а ваш API-ключ передаётся в заголовке BV-API-KEY. Храните этот ключ на сервере. Никогда не включайте его в код браузера.
Вот минимальный запрос на основе справочника API:
curl -X POST https://api.billionverify.com/v1/verify/single \
-H "BV-API-KEY: sk_xxx" \
-H "Content-Type: application/json" \
-d '{"email":"test@example.com","check_smtp":true}'
Запрос принимает три параметра:
| Параметр | По умолчанию | Назначение |
|---|---|---|
email | обязательно | Адрес для проверки |
check_smtp | включено | Установите false, чтобы пропустить проверку почтового ящика через live SMTP |
force_refresh | false | Пропускает кэшированные результаты; свежий результат тарифицируется как новая проверка |
Успешный ответ содержит результат в стандартной оболочке. Вот сокращённый пример для доставляемого адреса:
{
"success": true,
"code": "0",
"message": "Success",
"data": {
"email": "user@example.com",
"status": "valid",
"score": 0.95,
"is_deliverable": true,
"is_disposable": false,
"is_catchall": false,
"is_role": false,
"is_free": false,
"domain": "example.com",
"mx_records": ["mail.example.com"],
"check_smtp": true,
"reason": "smtp_deliverable",
"domain_suggestion": "",
"response_time": 250,
"credits_used": 1
}
}
Если вы предпочитаете SDK, BillionVerify публикует официальные SDK для Node.js, Python, TypeScript, Go, PHP и Java. В Node.js команда npm install billionverify-sdk устанавливает клиент с методом verify; в Python пакет называется billionverify.
Чтение ответа: статус, оценка и причина
Поле status — то, на что опирается большинство ветвей кода. Вот что означает каждый статус и какой вариант по умолчанию разумен для формы регистрации:
| Статус | Значение | Вариант по умолчанию для формы регистрации |
|---|---|---|
valid | Почтовый ящик существует и может получать письма | Принять |
invalid | Адрес не существует или не может получать письма | Заблокировать и попросить другой адрес |
disposable | Временный почтовый ящик | Заблокировать или принять с ограничениями |
catchall | Домен принимает любой адрес | Принять и отслеживать |
role | Общий почтовый ящик, например info@ | Принять, возможно, пометить для продаж |
unknown | Доставляемость не удалось подтвердить | Принять и проверить позже |
Поле score даёт более точный сигнал в диапазоне от 0 до 1. В качестве общего ориентира результаты valid получают оценку от 0.85 до 1.0, catchall — примерно от 0.55 до 0.75, unknown — от 0.3 до 0.6, disposable — 0.1, а invalid — 0. Результат role сохраняет оценку исходной проверки. Вы можете использовать оценку, чтобы задать собственный порог для пограничных случаев, например принимать адреса catch-all только при оценке выше определённого значения в форме с высокой ценностью.
Поле reason объясняет вердикт. Результат invalid может сопровождаться значениями invalid_syntax, no_mx_records или mailbox_not_found, и каждое указывает на отдельное сообщение для пользователя. Проблема с синтаксисом означает «проверьте формат». Отсутствующий почтовый ящик означает «этот ящик не существует». На странице причины проверки перечислены все причины и указано, какие причины unknown стоит проверять повторно.
Два поля помогают пользователю напрямую: domain_suggestion может использоваться для подсказки «Вы имели в виду gmail.com?», а is_disposable объясняет, почему одноразовый адрес был отклонён.
Проектирование процесса регистрации с учётом бюджета задержки
Самое сложное — встроить проверку в форму, не замедлив её. Начните с бюджета. Решите, как долго вы готовы удерживать пользователя, например от 300 до 500 миллисекунд после отправки формы. Всё остальное определяется этим числом.
В описании продукта BillionVerify кэшированные результаты появляются менее чем за 200 мс, а полная проверка SMTP в среднем занимает от 1 до 3 секунд. Эта разница оставляет вам два хороших варианта:
- Полная проверка с ограничением времени. Вызовите API с включённым SMTP и тайм-аутом 2–3 секунды. Большинство ответов придёт вовремя и даст вам понятный результат
validилиinvalid. Если сработает тайм-аут, разрешите регистрацию и выполните повторную проверку позже. - Быстрая проверка сейчас, глубокая проверка позже. Вызовите API с параметром
check_smtp: false. Это позволяет подтвердить только очевидные случаи: неверный синтаксис, домен без записей MX, одноразовые и ролевые адреса. Адрес на работающем домене вернётся со статусомunknownи причинойsmtp_unverifiable, что ожидаемо. Примите его, затем выполните второй вызов с включённым SMTP из фоновой задачи. Если почтового ящика не существует, пометьте аккаунт и попросите пользователя подтвердить свой адрес.
Также помогут несколько приёмов для frontend:
- Проверяйте при потере фокуса или отправке формы, а не после каждого нажатия клавиши. Проверка
j,jo,johприводит к лишним вызовам и расходу кредитов. - Сначала выполняйте локальные проверки синтаксиса, чтобы не тратить дополнительный запрос на очевидные ошибки.
- Вызывайте API из backend. Сервер хранит ключ API и записывает результат, а браузер только показывает итог.
Подробнее о UX — формулировках, размещении ошибок и моменте показа подсказки — см. в материале проверка электронной почты при регистрации.
Пропускать или блокировать? Обработка тайм-аутов и неопределённых результатов
Для большинства продуктов работает такой подход: при явных ошибках блокируйте, при неопределённости пропускайте.
- Блокировать означает запретить регистрацию. Делайте это, когда API сообщает, что адрес явно недействителен:
invalidсinvalid_syntaxилиno_mx_records, либо адресdisposableв форме, где одноразовые аккаунты создают проблемы. - Пропускать означает разрешить пользователю продолжить и проверить результат позже. Делайте это, когда ответ неопределён: статус
unknown, домен catch-all или ваш собственный тайм-аут срабатывает до ответа API.
Почему бы не блокировать неопределённые адреса? За многими из них стоят реальные люди. Корпоративные почтовые серверы часто используют серый список или ограничивают частоту SMTP-проверок, поэтому их блокировка приводит к потере реальных регистраций. Примите адрес, добавьте к записи метку и проверьте его позже.
Установите тайм-аут на стороне клиента для вызова API в соответствии с допустимой задержкой. Когда он сработает, считайте результат unknown: примите адрес, сохраните флаг и поставьте повторную проверку в фоновую очередь. Повторно проверяйте результаты unknown позже, а не в рамках текущего запроса.
Пример: проверка Email при регистрации в Node.js
Ниже показана быстрая проверка (дизайн 2) в обработчике регистрации. Она использует задокументированный REST-эндпоинт и поля ответа, тайм-аут, а также описанные выше правила пропуска или блокировки. Адаптируйте имена под свой фреймворк.
const BLOCK = new Set(['invalid', 'disposable']);
async function checkEmail(email) {
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), 400);
try {
const response = await fetch('https://api.billionverify.com/v1/verify/single', {
method: 'POST',
headers: {
'BV-API-KEY': process.env.BV_API_KEY,
'Content-Type': 'application/json',
},
body: JSON.stringify({ email, check_smtp: false }),
signal: controller.signal,
});
const body = await response.json();
if (!body.success) return { allow: true, recheck: true };
const { status, reason, domain_suggestion } = body.data;
if (BLOCK.has(status)) {
return { allow: false, reason, suggestion: domain_suggestion };
}
return { allow: true, recheck: status === 'unknown' || status === 'catchall' };
} catch {
// Timeout or network error: fail open and re-check in the background.
return { allow: true, recheck: true };
} finally {
clearTimeout(timer);
}
}
Без SMTP большинство действительных адресов возвращаются со статусом unknown и получают флаг recheck. После сохранения аккаунта фоновая задача вызывает тот же эндпоинт с включённым SMTP для каждой записи, отмеченной флагом recheck. В руководстве по Node.js подробно описана настройка, включая официальный SDK. Этот же запрос можно выполнять из Python или любого языка с HTTP-клиентом.
Ограничения запросов, кэширование и стоимость
Проверка в реальном времени выполняется при регистрации, поэтому её ограничения становятся вашими ограничениями. Планируйте это заранее.
Ограничения запросов. BillionVerify защищает свои ресурсы с помощью ограничений для каждого аккаунта. При достижении лимита API возвращает HTTP 429 с кодом 1003 и заголовком Retry-After. Выполните повторную попытку с задержкой и сохраните собственное правило разрешения при сбое, чтобы лимит никогда не блокировал реального пользователя.
Кэширование. Результаты кэшируются, поэтому повторные проверки выполняются быстро. Повторная проверка адреса, который ваш аккаунт подтвердил за последние 24 часа, бесплатна. Используйте force_refresh: true только при реальной необходимости получить свежий результат, поскольку это пропускает кэш и тарифицируется как новая проверка.
Стоимость. Одна проверка обычно использует 1 кредит, что отображается в credits_used. Каждый результат unknown бесплатен, как и ошибки синтаксиса. Проверяйте адрес при отправке формы, а не после каждого нажатия клавиши, и не проверяйте повторно адрес, который недавно уже был подтверждён. BillionVerify предоставляет 20 бесплатных кредитов каждый день при входе в аккаунт — до 600 в месяц, чего достаточно для создания и тестирования интеграции. Платные пакеты кредитов перечислены на странице с ценами.
За пределами формы: пакеты, файлы и Webhooks
Проверка в реальном времени охватывает новые адреса по одному. Для всего остального тот же API предлагает другие варианты:
- Небольшие пакеты.
POST /verify/bulkпроверяет до 50 адресов за один запрос — это удобно для синхронизации CRM или экрана импорта. - Большие списки.
POST /verify/fileпринимает файл CSV, TXT или XLSX и обрабатывает его в фоновом режиме. - Webhooks. Вместо опроса статуса обработки файла зарегистрируйте webhook для событий
file.completedиfile.failed. Ознакомьтесь с руководством по webhooks для проверки электронной почты, где описаны проверки подписей и повторные попытки. - Проверка только одноразовых адресов.
POST /verify/disposableотвечает только на вопрос об одноразовости и не использует кредиты.
Распространённая схема: проверки в реальном времени для каждой формы, ночная пакетная проверка записей, помеченных как recheck, и обработка файла перед крупными кампаниями.
Чек-лист проверки Email в режиме реального времени
Перед запуском пройдите этот список:
- Ключ API хранится на сервере, никогда не в браузере.
- Синтаксис проверяется локально до вызова API.
- Путь запроса использует
check_smtp: falseи тайм-аут, соответствующий вашему бюджету задержки. - Для
invalidиdisposableпредусмотрены понятные конкретные сообщения об ошибках. unknown,catchallи тайм-ауты пропускаются и ставятся в очередь на повторную проверку.domain_suggestionиспользуется для подсказки об опечатке.- Ответы 429 обрабатываются с увеличением интервала без блокировки пользователей.
- Результаты сохраняются вместе с записью пользователя, чтобы позднее можно было измерить процент возвратов.
Часто задаваемые вопросы
Что такое API проверки email в реальном времени?
API проверки email в реальном времени проверяет один адрес электронной почты, пока пользователь отправляет форму, и возвращает результат за долю секунды. Он выполняет проверки синтаксиса, домена, MX, одноразовых адресов, ролевых адресов и catch-all, а также при необходимости проверяет почтовый ящик через SMTP, чтобы ваше приложение могло принять, заблокировать или пометить адрес до его попадания в базу данных.
Чем проверка email в реальном времени отличается от массовой проверки?
Проверка email в реальном времени проверяет один адрес за раз в рамках пользовательского запроса и должна отвечать быстро. Массовая проверка проверяет весь список в фоновом режиме и может занимать гораздо больше времени. Используйте проверки в реальном времени, чтобы поддерживать чистоту новых данных, а массовые проверки — чтобы очистить уже имеющиеся данные.
Нужно ли запускать проверку SMTP при каждой регистрации?
Это зависит от допустимой задержки. Проверка SMTP подтверждает существование почтового ящика, поэтому без неё большинство действительных адресов получают результат unknown. Если вы можете подождать 2–3 секунды, запускайте её при отправке формы с тайм-аутом. Если нет, выполняйте быструю проверку с check_smtp: false, а проверку SMTP запускайте в фоновой задаче.
Что делать с результатами catch-all и unknown?
Принимайте их и перепроверяйте позже. Домен catch-all принимает любой адрес, поэтому проверка почтового ящика не может доказать существование входящих сообщений, а результат unknown означает, что проверка не завершилась. Блокировка таких пользователей приводит к потере реальных регистраций; если помечать их и перепроверять, данные останутся чистыми без снижения конверсии.
Можно ли вызывать API проверки email из браузера?
Нет. Это раскроет ваш ключ API. Вызывайте API из серверной части и возвращайте только решение.
Насколько быстро выполняется проверка email в реальном времени?
В BillionVerify результаты из кэша возвращаются менее чем за 200 мс, а полная проверка SMTP занимает в среднем 1–3 секунды. Поэтому быстрая проверка без SMTP должна выполняться в пути обработки запроса, а проверка SMTP — в фоновом режиме.
Сколько стоит API проверки email?
В BillionVerify одна проверка обычно использует 1 кредит, а каждый результат unknown предоставляется бесплатно. Вы получаете 20 бесплатных кредитов каждый день при входе в систему — до 600 в месяц, а платные пакеты кредитов доступны на странице тарифов. force_refresh пропускает кэш и тарифицируется как новая проверка.
Начните проверять электронные адреса в реальном времени
Проверка электронной почты в реальном времени означает меньше возвратов, меньше фиктивных аккаунтов и меньше пользователей, потерянных из-за опечатки. Добавьте быструю проверку в путь обработки запроса, перенесите медленную проверку в фоновый режим и позволяйте явным ошибкам блокировать запрос, а неопределённым результатам — проходить. Создайте бесплатный аккаунт BillionVerify, получите API-ключ и выполните свой первый вызов API для проверки электронной почты из документации выше.