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

На этой странице

Чтобы интерпретировать результат проверки email, сначала убедитесь, что проверка закончена. При pending повторно запросите ту же проверку. В итоговом ответе прочитайте status и action, затем reason_codes и checks, которые объясняют решение. confidence обобщает свидетельства, а freshness указывает, когда они получены.

Сохраняйте эти поля вместе. Адрес с недостаточными свидетельствами требует другого решения, чем адрес, для которого ошибка ввода или домена дает однозначный повод для отказа.

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

У Emvero четыре итоговых статуса. Отдельное значение pending означает, что проверка еще стоит в очереди или выполняется.

`status`	Что устанавливает результат	Следующий шаг
`deliverable`	Сервер принял получателя, и более сильный сигнал риска не изменил вывод.	Следуйте `action`, обычно `allow`; доставка и доступ к ящику остаются недоказанными.
`risky`	Признак вроде одноразовой почты или catch-all меняет подход к адресу.	Прочитайте причину и действие: возможны `allow` и `allow_with_email_confirmation`.
`undeliverable`	Найдена однозначная причина отказа: например, некорректный ввод, `DNS_NXDOMAIN` или null MX.	Выполните `reject`; при необходимости попросите исправить адрес или указать другой.
`unknown`	Свидетельства не позволяют сделать определенный вывод.	В зависимости от причины запросите подтверждение, проверьте позже или отложите адрес.
`pending`	Проверка еще не завершена.	Повторно получите ту же проверку после `retry_after_ms`, прежде чем применять правило для итогового результата.

Поля описаны в справочнике статусов. Статус обобщает технические свидетельства, действие рекомендует сценарий приложения. У них разные задачи. Одноразовый адрес может быть risky с allow, а установленное catch-all поведение — дать risky с allow_with_email_confirmation.

Отрицательное SMTP-наблюдение тоже требует внимания. Свидетельство «ящик не найден» во время пробы Emvero сейчас возвращает как unknown с SMTP_RECIPIENT_REJECTED_AMBIGUOUS. Действие — allow_with_email_confirmation. Такой пробы недостаточно для отказа, который дает однозначная ошибка синтаксиса или домена.

Найдите причину в `reason_codes` и `checks`

reason_codes содержит машинные идентификаторы наблюдений и ограничений. SMTP_RCPT_ACCEPTED относится к принятию получателя, DISPOSABLE_DOMAIN — к свойству домена, DNS_NXDOMAIN — к отсутствующему домену, а SMTP_GREYLISTED — к временной отсрочке SMTP. Прежде чем писать правило для адреса, выясните, какой этап описывает код.

Ограничение принимающего сервера показывает, что удалось узнать во время пробы. Ошибка сервиса относится к проблеме самого проверяющего. Ни один из этих случаев не доказывает неисправность ящика. Полный словарь находится в справочнике кодов причин. Коды служат стабильными идентификаторами, но список может пополняться. Сохраняйте незнакомое значение и применяйте запасное правило, вместо того чтобы отклонять адрес по одному названию кода.

Поля checks показывают, до какого этапа дошла проверка:

syntax принимает valid или invalid. Для domain и mail_routing также возможно unknown.
smtp принимает accepted, rejected, skipped, unknown или pending. Пропущенный этап не запускался. Значение smtp: rejected может сочетаться с итоговым unknown.
accept_all принимает yes, no или unknown.
disposable, role_account, public_provider и smtp_utf8_required описывают свойства адреса или домена.

Например, mail_routing: valid с smtp: unknown указывает на другой пробел, чем domain: unknown. В первом случае уже есть свидетельства о маршруте, во втором не установлен даже результат для домена. По причине можно решить, поможет ли еще одна проверка. Более узкий выбор разобран в сравнении unknown и undeliverable.

Учитывайте ограничения `confidence` и `freshness`

confidence — оценка силы свидетельств от 0 до 1. Это не откалиброванная вероятность доставки: 0.7 не означает, что дойдут 70 % писем. Правило вроде confidence > 0.85 тоже не устанавливает доступ к ящику и не гарантирует доставку. Используйте оценку для сортировки внутри одного статуса или очереди ручной проверки. Документация о confidence объясняет значение поля; сравнение оценки и свидетельств показывает, почему оно не заменяет остальные поля.

freshness отдельно сохраняет время DNS- и SMTP-наблюдений:

{
  "freshness": {
    "dns_checked_at": "2026-09-05T09:14:22Z",
    "smtp_checked_at": "2026-09-05T09:14:23Z"
  }
}

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

Пример: принятый одноразовый адрес

Этот полный ответ — учебный пример с зарезервированным доменом. Он не получен при проверке настоящего адреса или измерением для конкретного провайдера.

{
  "id": "00000000-0000-4000-8000-000000000001",
  "generation": 1,
  "email": "person@disposable.example",
  "normalized": { "domain": "disposable.example", "ascii_domain": "disposable.example" },
  "status": "risky",
  "confidence": 0.85,
  "action": "allow",
  "checks": {
    "syntax": "valid",
    "domain": "valid",
    "mail_routing": "valid",
    "smtp": "accepted",
    "accept_all": "unknown",
    "disposable": true,
    "role_account": false,
    "public_provider": false,
    "smtp_utf8_required": false
  },
  "reason_codes": ["SMTP_RCPT_ACCEPTED", "DISPOSABLE_DOMAIN"],
  "freshness": {
    "dns_checked_at": "2026-09-05T09:14:22Z",
    "smtp_checked_at": "2026-09-05T09:14:23Z"
  }
}

SMTP-сервер принял получателя, но DISPOSABLE_DOMAIN меняет статус на risky. Действие остается allow. Временный ящик может технически работать, хотя срок его использования не подходит вашему продукту.

Определите бизнес-правило отдельно. Для рассылки вы можете принять адрес, а для платного пробного периода — попросить постоянный. Сохраняйте полученные свидетельства, чтобы решение продукта не выглядело как провал технической проверки.

Пример: проба, отложенная грейлистингом

Второй полный ответ тоже учебный. Синтаксис и маршрут прошли проверку, но принимающий сервер отложил сессию.

{
  "id": "00000000-0000-4000-8000-000000000002",
  "generation": 1,
  "email": "person@greylisted.example",
  "normalized": { "domain": "greylisted.example", "ascii_domain": "greylisted.example" },
  "status": "unknown",
  "confidence": 0.4,
  "action": "allow_with_email_confirmation",
  "checks": {
    "syntax": "valid",
    "domain": "valid",
    "mail_routing": "valid",
    "smtp": "unknown",
    "accept_all": "unknown",
    "disposable": false,
    "role_account": false,
    "public_provider": false,
    "smtp_utf8_required": false
  },
  "reason_codes": ["SMTP_GREYLISTED"],
  "freshness": {
    "dns_checked_at": "2026-09-05T09:14:22Z",
    "smtp_checked_at": "2026-09-05T09:14:23Z"
  }
}

SMTP_GREYLISTED оставляет результат unknown. Он не доказывает ни существование, ни отсутствие ящика. В форме регистрации следуйте действию: если нужен доступ к ящику, ваше приложение должно отправить подтверждение. Проба Emvero не отправляет письмо. Проверка позже может добавить свидетельства, но не обещает определенного исхода.

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

Сохраняйте основание решения вместе с адресом

Сначала повторно запросите незавершенные проверки. Для итогового результата начните с action. Читайте reason_codes, чтобы уточнить правило, и checks, чтобы найти непроверенные или неопределенные этапы. Применяйте confidence для сортировки, а freshness — для оценки возраста данных.

Сохраняйте свидетельства вместе с решением, чтобы позже объяснить прием адреса, запрос подтверждения или отказ. На странице API проверки email показано, как запросить проверку и получить результат.