--- title: "Как определить почтового провайдера домена | Emvero" description: "Определите почтового провайдера по MX-записям, разберитесь в приоритетах и шлюзах и узнайте, когда DNS не раскрывает сервис почтовых ящиков." url: https://emvero.io/ru/blog/how-to-find-email-provider/ language: ru updated: 2026-10-07 --- Блог # Как определить почтового провайдера домена MX-записи показывают, куда домен направляет входящую почту. Однако видимый сервер может оказаться шлюзом, резервным маршрутом или собственным именем домена. Опубликовано 2026-09-21 Начните с MX-записей домена. В них указаны серверы для входящей почты, а узнаваемое имя сервера часто позволяет определить провайдера этого маршрута. Иногда ответ однозначен. В других случаях DNS показывает только фильтрующий шлюз, частное имя или несколько провайдеров. Тогда сервис почтовых ящиков остается неизвестным. Эта граница защищает от неверной атрибуции. MX-запрос дает свидетельства о видимом входящем маршруте. Он не определяет владельца домена, человека за email-адресом или сервис для исходящей рассылки. ## Сначала запросите домен Для `alex@company.example` запросите `company.example`. Часть перед `@` обозначает ящик и не участвует в поиске MX-записей. Используйте DNS-утилиту, которая показывает все MX-записи и их значения приоритета: ``` dig MX company.example ``` Ниже приведен искусственный пример. Имена в зоне `.example` зарезервированы для документации и не описывают реального провайдера: ``` company.example. 3600 IN MX 10 inbound-a.mailhost.example. company.example. 3600 IN MX 20 inbound-b.mailhost.example. ``` Каждая MX-запись содержит значение приоритета и имя сервера назначения. Отправляющие серверы сначала пробуют меньшие значения. Поэтому маршрут с приоритетом `10` предшествует маршруту с `20`. Одинаковые значения равноправны. [RFC 1035 описывает оба поля MX-записи](https://www.rfc-editor.org/rfc/rfc1035.html#section-3.3.9), а [RFC 5321 определяет выбор сервера в SMTP](https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1). Проверьте весь набор записей. Резервный сервер с большим значением может принадлежать другому оператору. Несколько равноправных записей, напротив, могут относиться к одному сервису. Подробнее правила маршрутизации разобраны в [словарной статье об MX-записях](https://emvero.io/ru/glossary/mx-record/). ## Сопоставьте серверы с провайдером Сравните окончания имен серверов с именами, которые документируют или контролируют известные почтовые провайдеры. Если несколько MX-записей заканчиваются в пространстве имен одного провайдера, обычно это один сервис с несколькими входящими серверами. В примере оба имени заканчиваются на `mailhost.example`. Если это пространство имен относится к известному профилю, обе записи подтверждают одну атрибуцию. Сервис проверки может хранить такие соответствия и возвращать стабильный идентификатор. Вам не придется узнавать каждый сервер вручную. Результат описывает свидетельства о входящем маршруте: - Один известный провайдер на всех предпочтительных маршрутах подтверждает однозначное совпадение. - Несколько известных провайдеров с одинаковым предпочтительным приоритетом дают смешанный результат. - Собственное имя сервера или неизвестное окончание оставляет провайдера неизвестным. - Если домен заявляет об отказе от входящей почты, провайдер к нему неприменим. Приоритет влияет на вывод. Резервный сервер с большим значением может не обрабатывать письма в обычных условиях. Но если полностью его игнорировать, можно пропустить второго оператора, который вступает в работу при сбое. ## Шлюз может скрывать сервис почтовых ящиков Многие организации ставят перед ящиками фильтр или защитный сервис. MX-записи указывают на этот шлюз, потому что он первым принимает SMTP-соединение. Затем шлюз пересылает принятые письма на платформу, имя которой не опубликовано в DNS. В такой схеме MX-проверка должна назвать шлюз. Считать его сервисом почтовых ящиков без дополнительных данных нельзя. Это же ограничение действует для хостинговых релеев и собственных почтовых устройств. Собственные имена серверов еще сильнее затрудняют атрибуцию. Компания может опубликовать `mx1.company.example`, хотя за этим именем работает сторонний сервис. Без проверенных данных о связи провайдер остается неизвестным. Догадка по бренду или IP-адресу легко превращает обычный хостинг в ложную атрибуцию. ## Разделяйте соседние сервисы Один домен может использовать разные компании для разных задач. Оператор MX-маршрута не обязан быть регистратором, авторитетным DNS-сервисом или хостингом сайта. Рассылки и транзакционные письма тоже могут уходить через другую платформу. SPF не отвечает на вопрос о входящей почте. Эта запись задает правила для серверов, которым разрешено отправлять письма с идентификатором домена. Назначение SPF описано в [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html#section-2.3). DMARC публикует правила согласования, политику и параметры отчетов для аутентифицированных писем. Область действия DMARC определена в [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html#section-3.1). Ни одна из этих записей не заменяет MX при поиске оператора входящей почты. Посмотрите пример, [почему письмо может пройти SPF и не пройти DMARC](https://emvero.io/ru/blog/spf-vs-dmarc/). Регистрационные данные отвечают на другой вопрос. Регистратор управляет регистрацией, а данные владельца относятся к контролю над доменом. Оператора входящей почты они не определяют. Чтобы использовать сведения о провайдере вместе с сетевыми и регистрационными данными, прочитайте [разбор профиля домена](https://emvero.io/ru/blog/reading-domain-intelligence/). ## Иногда MX-запрос не позволяет определить провайдера Отсутствие совпадения тоже может быть правильным результатом. Сначала проверьте состояние DNS: - Если ответ на MX-запрос пуст, SMTP может использовать неявный маршрут к самому домену. Собственное имя домена обычно не дает достаточно данных для атрибуции провайдера. - Единственная запись `MX 0.` называется null MX. Она заявляет, что домен не принимает почту, поэтому определять входящего провайдера не нужно. Эта запись описана в [RFC 7505](https://www.rfc-editor.org/rfc/rfc7505.html#section-3). - Если опубликованные MX-серверы не разрешаются в адреса, неявная подстановка не применяется. Явный маршрут сломан или временно недоступен. - `SERVFAIL` или таймаут оставляет запрос без ответа. Повторите его или разберите [ошибку DNS](https://emvero.io/ru/glossary/dns-failure/), прежде чем назначать провайдера. - `NXDOMAIN` означает, что, согласно ответу DNS, запрошенного домена не существует. Атрибутировать почтовый маршрут в этом случае невозможно. В статье о [домене без MX-записи](https://emvero.io/ru/blog/domain-without-mx-record/) подробно разобраны неявная маршрутизация, null MX и нерабочие серверы назначения. Пустой ответ, явный отказ от почты и ошибка запроса требуют разных выводов. ## Провайдер остается свидетельством уровня домена Совпадение показывает, кто, по имеющимся данным, обслуживал видимый входящий маршрут во время проверки. Оно не доказывает, что `alex@company.example` существует. Доставку письма и его попадание во входящие это тоже не гарантирует. Чтобы получить свидетельства о ящике, нужна полная проверка адреса. Ее результат зависит от того, какие данные раскрывает принимающий сервер. Catch-all домен и временные ответы могут сохранить неопределенность. [Сравнение полной проверки и проверки домена](https://emvero.io/ru/compare/full-check-vs-domain-check/) объясняет эту границу. База соответствий провайдеров со временем устаревает. Сервисы добавляют новые имена, клиенты меняют платформу, а маршруты перестраиваются. Если атрибуция влияет на решение, сохраните DNS-ответ и время наблюдения. Старый ярлык провайдера не должен перевешивать более свежую MX-запись. ## Проверьте маршрут и профиль провайдера Публичный [инструмент проверки домена Emvero](https://emvero.io/ru/email-domain-checker/) показывает, может ли домен принимать почту. Если сервер назначения совпадает с известным профилем провайдера, результат может содержать его идентификатор. Исходные имена MX-серверов и значения приоритетов инструмент не показывает. Для их проверки используйте `dig`. Если профиль не найден, это означает только отсутствие известного совпадения в текущих данных. Такой результат не доказывает, что компания обслуживает почту сама или что домен принадлежит организации. Проверка бесплатна и не требует аккаунта. ## Термины, которые здесь встречаются ### MX-запись DNS-запись с именем сервера для входящей почты домена и его приоритетом. Она не подтверждает существование ящика. ### Сбой DNS DNS-запрос не дал нужных сведений о домене или почтовом маршруте. Отсутствующее имя и временный сбой требуют разных решений. ### SMTP-рукопожатие Обмен командами и ответами с почтовым сервером. При проверке адреса позволяет запросить прием конкретного получателя. [Все статьи](https://emvero.io/ru/blog/) ## Выберите, что проверить дальше. Запустите проверку в личном кабинете и посмотрите данные в результате. Начать бесплатно