Domain intelligence для работы с почтой объединяет сведения о почтовых настройках домена, его сетевой инфраструктуре и, когда они доступны, регистрации. Эти данные помогают изучить домен клиента или дополнить его карточку в CRM технической информацией. Каждое наблюдение отвечает на свой вопрос: куда приходит почта, какая политика отправки опубликована, какая сеть анонсирует IP-адрес или когда зарегистрирован домен.
Прежде чем принимать решение, разберите эти сведения по отдельности. Рабочий почтовый маршрут не подтверждает существование конкретного ящика, а давняя регистрация не доказывает надежность нынешнего пользователя домена. Domain Intelligence в Emvero собирает данные об инфраструктуре, не открывая SMTP-сессию и не отправляя писем.
Начните с маршрута входящей почты
Проверьте, есть ли у домена маршрут для приема писем. В профиле Emvero поле mail_routing.status может содержать значение routable. Оно подтверждает маршрут в полученной конфигурации DNS; конкретный получатель при этом не проверяется.
MX-записи указывают принимающие серверы. Совпадение с провайдером определяет видимого оператора входящей почты. Им может оказаться фильтрующий шлюз перед сервисом, где находятся ящики. Если mx.provider_match содержит unknown, оставьте провайдера неизвестным. Незнакомое имя сервера не означает, что организация обслуживает почту сама. В отдельной статье описано, как определить почтового провайдера по MX-записям.
Пустой ответ на MX-запрос требует внимания: при отсутствии MX протокол SMTP допускает неявный маршрут к адресу самого домена. Этот механизм описан в RFC 5321. Разбор диагностических случаев есть в статье про домен без MX-записи.
Учитывайте смысл настроек отправки и классификаций
Поля SPF и DMARC описывают опубликованные настройки отправки почты. В Domain Intelligence значение not_performed означает, что аутентификация конкретного письма не проверялась. Запрос проверяет поддерживаемый синтаксис записей и поля политики. Он не обходит SPF includes для оценки отправителя и не ищет DKIM-ключи. Сравнение SPF и DMARC объясняет, как эти механизмы связаны с письмом.
Классификации в email.classification берутся из справочных данных. Отсутствие домена в списке временной почты не доказывает его безопасность. Отрицательный признак публичного почтового провайдера тоже не подтверждает, что адрес корпоративный.
Поле email.catch_all.state возвращает уже известные сведения о домене. Этот запрос не запускает новую проверку получателя. По значению unknown нельзя записать ни «принимает любых получателей», ни «проверяет каждый ящик».
Разберитесь, к чему относятся сетевые и регистрационные данные
Сетевые сведения есть в обоих вариантах: standard и extended. Раздел network.mail описывает адреса почтовых серверов, а network.web — адреса, полученные для запрошенного домена, и цепочку CNAME, по которой они найдены. Номер автономной системы, ASN, обозначает сеть, которая анонсирует адрес.
Эти данные позволяют сравнить инфраструктуру. Адреса почтовых серверов и сайта могут принадлежать одной сети, хотя выполняют разные задачи. Страна в сетевых данных обозначает место регистрации автономной системы и не определяет расположение сервера. Если виден CDN или прокси, его пограничные адреса могут скрывать исходный сервер. Наличие адреса в DNS также не доказывает, что по нему отвечает сайт.
Вариант extended добавляет регистрационные данные через RDAP, протокол доступа к данным регистрации. RDAP различает события регистрации и последующих изменений, у каждого из которых своя дата. Эти поля событий определены в RFC 9083.
Прежде чем использовать возраст, проверьте registration.registered_domain. При запросе поддомена регистрация относится к его регистрируемому родительскому домену. Поле registration.age_days считает полные дни от указанной даты регистрации до generated_at. Оно не сообщает, когда появилась компания, запустился сайт или домен перешел к нынешнему владельцу. Некоторые реестры не предоставляют дату. Сохраните этот пробел в данных, а не записывайте нулевой возраст.
Пример: читаем один профиль
Допустим, вы изучаете example.com, прежде чем дополнить карточку клиента техническими сведениями. Ниже приведены значения из синтетического примера, а не результат реального запроса. Это выбранные наблюдения, а не полный ответ API.
| Наблюдение | Что можно записать |
|---|---|
mail_routing.status: routable |
В полученной конфигурации есть маршрут входящей почты. |
mx.provider_match: unknown |
Единый провайдер входящей почты не определен. |
email.catch_all.state: unknown |
Поведение catch-all не установлено. |
| IP-адреса почтовых серверов относятся к AS64500 и AS64511, адреса сайта — к AS64500 | Часть адресов почты и сайта использует одну сеть. Общий оператор сервисов этим не установлен. |
registration.age_days: 2191 |
На момент формирования примера с указанной даты регистрации прошел 2191 полный день. |
SPF -all; DMARC reject |
Это опубликованные настройки отправки, а не результаты аутентификации письма. |
Профиль дает полезные сведения об инфраструктуре, но не позволяет сделать вывод об alex@example.com. Если при подключении клиента нужны свидетельства о конкретном адресе, проверьте его отдельно. Сравнение полной проверки и проверки домена объясняет возможности каждой глубины. Когда важно установить контроль над ящиком, дополнительно нужно подтверждение со стороны пользователя. Техническая проверка не устанавливает согласие на ваши письма и не гарантирует попадание во входящие.
В этом примере можно сохранить маршрут и возраст регистрации, оставив провайдера и catch-all неизвестными. Недавно зарегистрированный домен может стать поводом задать дополнительный вопрос, если это предусмотрено вашими правилами. Одного возраста регистрации недостаточно, чтобы принять или отклонить клиента.
Проверяйте нужное поле даже в полном профиле
Статус complete означает, что обязательные наблюдения выбранного варианта обработаны. Полный профиль может содержать неизвестного провайдера или статус catch-all. Он также может установить, что домен не принимает почту. Сетевые сведения не определяют общий статус, поэтому читайте их собственные метаданные.
Профиль extended получает статус partial, если дата регистрации недоступна. Полезные сведения о почтовом маршруте при этом сохраняются. Если же отказал сам источник маршрута, сервис может вернуть ошибку. Сбой DNS не доказывает, что домен не принимает почту.
Перед использованием поля посмотрите meta.status и reason, затем доступные значения source, source_version, observed_at, expires_at и stale. Профиль, сформированный сейчас, может содержать более ранние наблюдения. Эти поля описаны в документации Domain Intelligence.
Две даты истечения имеют разный смысл: registration.expires_at — дата окончания регистрации домена по данным реестра, а registration.meta.expires_at показывает, до какого момента можно повторно использовать сохраненные регистрационные сведения. Ни одна из дат не сообщает, когда перестанет работать ящик клиента.
Храните наблюдения отдельно от своего решения
При интеграции с CRM сохраняйте проверенный домен, нужные вашему процессу поля и даты наблюдений. Отделяйте профиль домена от результата проверки email-адреса контакта. Если несколько контактов используют один домен, профиль даст общие сведения о нем, но не подтвердит работу всех их ящиков.
Решение и его причину тоже храните отдельно. Тогда при изменении данных можно пересмотреть карточку, не превращая старую метку провайдера или отсутствующую дату регистрации в постоянную оценку клиента. Эти записи вносит ваша интеграция: запрос сам по себе не обновляет CRM.
Для завершенной операции API поддерживает повторное получение сохраненного ответа в течение ограниченного срока. Запрос с теми же Idempotency-Key, доменом и вариантом в этот срок вернет исходный результат. Наблюдения при этом не обновятся. Правила повторов и новых запросов описаны в руководстве Domain Intelligence API.
Чтобы прочитать профиль без собственной интеграции, изучите домен в Emvero. Начните с почтового маршрута, затем перейдите к дополнительным полям, которые отвечают на ваш вопрос.