---
title: "Domain Intelligence: как читать профиль домена | Emvero"
description: "Что показывают MX, SPF/DMARC, сетевые и регистрационные данные домена. Разбираем пример профиля, неизвестные значения и использование результатов в CRM."
url: https://emvero.io/ru/blog/reading-domain-intelligence/
language: ru
updated: 2026-10-07
---

Блог

# Domain Intelligence: как читать профиль домена

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

Опубликовано 2026-10-03

Domain intelligence для работы с почтой объединяет сведения о почтовых настройках домена, его сетевой инфраструктуре и, когда они доступны, регистрации. Эти данные помогают изучить домен клиента или дополнить его карточку в CRM технической информацией. Каждое наблюдение отвечает на свой вопрос: куда приходит почта, какая политика отправки опубликована, какая сеть анонсирует IP-адрес или когда зарегистрирован домен.

Прежде чем принимать решение, разберите эти сведения по отдельности. Рабочий почтовый маршрут не подтверждает существование конкретного ящика, а давняя регистрация не доказывает надежность нынешнего пользователя домена. Domain Intelligence в Emvero собирает данные об инфраструктуре, не открывая SMTP-сессию и не отправляя писем.

## Начните с маршрута входящей почты

Проверьте, есть ли у домена маршрут для приема писем. В профиле Emvero поле `mail_routing.status` может содержать значение `routable`. Оно подтверждает маршрут в полученной конфигурации DNS; конкретный получатель при этом не проверяется.

MX-записи указывают принимающие серверы. Совпадение с провайдером определяет видимого оператора входящей почты. Им может оказаться фильтрующий шлюз перед сервисом, где находятся ящики. Если `mx.provider_match` содержит `unknown`, оставьте провайдера неизвестным. Незнакомое имя сервера не означает, что организация обслуживает почту сама. В отдельной статье описано, [как определить почтового провайдера по MX-записям](https://emvero.io/ru/blog/how-to-find-email-provider/).

Пустой ответ на MX-запрос требует внимания: при отсутствии MX протокол SMTP допускает неявный маршрут к адресу самого домена. Этот механизм описан в [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1). Разбор диагностических случаев есть в статье про [домен без MX-записи](https://emvero.io/ru/blog/domain-without-mx-record/).

## Учитывайте смысл настроек отправки и классификаций

Поля SPF и DMARC описывают опубликованные настройки отправки почты. В Domain Intelligence значение `not_performed` означает, что аутентификация конкретного письма не проверялась. Запрос проверяет поддерживаемый синтаксис записей и поля политики. Он не обходит SPF includes для оценки отправителя и не ищет DKIM-ключи. [Сравнение SPF и DMARC](https://emvero.io/ru/blog/spf-vs-dmarc/) объясняет, как эти механизмы связаны с письмом.

Классификации в `email.classification` берутся из справочных данных. Отсутствие домена в списке временной почты не доказывает его безопасность. Отрицательный признак публичного почтового провайдера тоже не подтверждает, что адрес корпоративный.

Поле `email.catch_all.state` возвращает уже известные сведения о домене. Этот запрос не запускает новую проверку получателя. По значению `unknown` нельзя записать ни «принимает любых получателей», ни «проверяет каждый ящик».

## Разберитесь, к чему относятся сетевые и регистрационные данные

Сетевые сведения есть в обоих вариантах: `standard` и `extended`. Раздел `network.mail` описывает адреса почтовых серверов, а `network.web` — адреса, полученные для запрошенного домена, и цепочку CNAME, по которой они найдены. Номер автономной системы, ASN, обозначает сеть, которая анонсирует адрес.

Эти данные позволяют сравнить инфраструктуру. Адреса почтовых серверов и сайта могут принадлежать одной сети, хотя выполняют разные задачи. Страна в сетевых данных обозначает место регистрации автономной системы и не определяет расположение сервера. Если виден CDN или прокси, его пограничные адреса могут скрывать исходный сервер. Наличие адреса в DNS также не доказывает, что по нему отвечает сайт.

Вариант `extended` добавляет регистрационные данные через RDAP, протокол доступа к данным регистрации. RDAP различает события регистрации и последующих изменений, у каждого из которых своя дата. Эти поля событий определены в [RFC 9083](https://www.rfc-editor.org/rfc/rfc9083.html#section-4.5).

Прежде чем использовать возраст, проверьте `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`. Если при подключении клиента нужны свидетельства о конкретном адресе, проверьте его отдельно. [Сравнение полной проверки и проверки домена](https://emvero.io/ru/compare/full-check-vs-domain-check/) объясняет возможности каждой глубины. Когда важно установить контроль над ящиком, дополнительно нужно подтверждение со стороны пользователя. Техническая проверка не устанавливает согласие на ваши письма и не гарантирует попадание во входящие.

В этом примере можно сохранить маршрут и возраст регистрации, оставив провайдера и catch-all неизвестными. Недавно зарегистрированный домен может стать поводом задать дополнительный вопрос, если это предусмотрено вашими правилами. Одного возраста регистрации недостаточно, чтобы принять или отклонить клиента.

## Проверяйте нужное поле даже в полном профиле

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

Профиль `extended` получает статус `partial`, если дата регистрации недоступна. Полезные сведения о почтовом маршруте при этом сохраняются. Если же отказал сам источник маршрута, сервис может вернуть ошибку. Сбой DNS не доказывает, что домен не принимает почту.

Перед использованием поля посмотрите `meta.status` и `reason`, затем доступные значения `source`, `source_version`, `observed_at`, `expires_at` и `stale`. Профиль, сформированный сейчас, может содержать более ранние наблюдения. Эти поля описаны в [документации Domain Intelligence](https://docs.emvero.io/using/domain-intelligence/).

Две даты истечения имеют разный смысл: `registration.expires_at` — дата окончания регистрации домена по данным реестра, а `registration.meta.expires_at` показывает, до какого момента можно повторно использовать сохраненные регистрационные сведения. Ни одна из дат не сообщает, когда перестанет работать ящик клиента.

## Храните наблюдения отдельно от своего решения

При интеграции с CRM сохраняйте проверенный домен, нужные вашему процессу поля и даты наблюдений. Отделяйте профиль домена от результата проверки email-адреса контакта. Если несколько контактов используют один домен, профиль даст общие сведения о нем, но не подтвердит работу всех их ящиков.

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

Для завершенной операции API поддерживает повторное получение сохраненного ответа в течение ограниченного срока. Запрос с теми же `Idempotency-Key`, доменом и вариантом в этот срок вернет исходный результат. Наблюдения при этом не обновятся. Правила повторов и новых запросов описаны в [руководстве Domain Intelligence API](https://emvero.io/ru/domain-intelligence-api/).

Чтобы прочитать профиль без собственной интеграции, [изучите домен в Emvero](https://emvero.io/ru/domain-intelligence/). Начните с почтового маршрута, затем перейдите к дополнительным полям, которые отвечают на ваш вопрос.

## Термины, которые здесь встречаются

### MX-запись

DNS-запись с именем сервера для входящей почты домена и его приоритетом. Она не подтверждает существование ящика.

### Catch-all-домен

Почтовый сервер принимает произвольных получателей в домене. Положительный ответ не подтверждает отдельный ящик.

## Ситуации, к которым это относится

### Чистка CRM без удаления хороших записей

Запись в CRM это история, а не адрес, поэтому здесь ничего не удаляется: проверка решает, кому вы можете писать, но никогда - кого вы можете хранить.

[Все статьи](https://emvero.io/ru/blog/)

## Выберите, что проверить дальше.

Запустите проверку в личном кабинете и посмотрите данные в результате.

Начать бесплатно