Как определить почтового провайдера домена

Начните с 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-записи, а RFC 5321 определяет выбор сервера в SMTP.

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

Сопоставьте серверы с провайдером

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

В примере оба имени заканчиваются на mailhost.example. Если это пространство имен относится к известному профилю, обе записи подтверждают одну атрибуцию. Сервис проверки может хранить такие соответствия и возвращать стабильный идентификатор. Вам не придется узнавать каждый сервер вручную.

Результат описывает свидетельства о входящем маршруте:

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

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

Шлюз может скрывать сервис почтовых ящиков

Многие организации ставят перед ящиками фильтр или защитный сервис. MX-записи указывают на этот шлюз, потому что он первым принимает SMTP-соединение. Затем шлюз пересылает принятые письма на платформу, имя которой не опубликовано в DNS.

В такой схеме MX-проверка должна назвать шлюз. Считать его сервисом почтовых ящиков без дополнительных данных нельзя. Это же ограничение действует для хостинговых релеев и собственных почтовых устройств.

Собственные имена серверов еще сильнее затрудняют атрибуцию. Компания может опубликовать mx1.company.example, хотя за этим именем работает сторонний сервис. Без проверенных данных о связи провайдер остается неизвестным. Догадка по бренду или IP-адресу легко превращает обычный хостинг в ложную атрибуцию.

Разделяйте соседние сервисы

Один домен может использовать разные компании для разных задач. Оператор MX-маршрута не обязан быть регистратором, авторитетным DNS-сервисом или хостингом сайта. Рассылки и транзакционные письма тоже могут уходить через другую платформу.

SPF не отвечает на вопрос о входящей почте. Эта запись задает правила для серверов, которым разрешено отправлять письма с идентификатором домена. Назначение SPF описано в RFC 7208. DMARC публикует правила согласования, политику и параметры отчетов для аутентифицированных писем. Область действия DMARC определена в RFC 9989. Ни одна из этих записей не заменяет MX при поиске оператора входящей почты.

Посмотрите пример, почему письмо может пройти SPF и не пройти DMARC.

Регистрационные данные отвечают на другой вопрос. Регистратор управляет регистрацией, а данные владельца относятся к контролю над доменом. Оператора входящей почты они не определяют.

Чтобы использовать сведения о провайдере вместе с сетевыми и регистрационными данными, прочитайте разбор профиля домена.

Иногда MX-запрос не позволяет определить провайдера

Отсутствие совпадения тоже может быть правильным результатом. Сначала проверьте состояние DNS:

• Если ответ на MX-запрос пуст, SMTP может использовать неявный маршрут к самому домену. Собственное имя домена обычно не дает достаточно данных для атрибуции провайдера.
• Единственная запись MX 0 . называется null MX. Она заявляет, что домен не принимает почту, поэтому определять входящего провайдера не нужно. Эта запись описана в RFC 7505.
• Если опубликованные MX-серверы не разрешаются в адреса, неявная подстановка не применяется. Явный маршрут сломан или временно недоступен.
• SERVFAIL или таймаут оставляет запрос без ответа. Повторите его или разберите ошибку DNS, прежде чем назначать провайдера.
• NXDOMAIN означает, что, согласно ответу DNS, запрошенного домена не существует. Атрибутировать почтовый маршрут в этом случае невозможно.

В статье о домене без MX-записи подробно разобраны неявная маршрутизация, null MX и нерабочие серверы назначения. Пустой ответ, явный отказ от почты и ошибка запроса требуют разных выводов.

Провайдер остается свидетельством уровня домена

Совпадение показывает, кто, по имеющимся данным, обслуживал видимый входящий маршрут во время проверки. Оно не доказывает, что alex@company.example существует. Доставку письма и его попадание во входящие это тоже не гарантирует.

Чтобы получить свидетельства о ящике, нужна полная проверка адреса. Ее результат зависит от того, какие данные раскрывает принимающий сервер. Catch-all домен и временные ответы могут сохранить неопределенность. Сравнение полной проверки и проверки домена объясняет эту границу.

База соответствий провайдеров со временем устаревает. Сервисы добавляют новые имена, клиенты меняют платформу, а маршруты перестраиваются. Если атрибуция влияет на решение, сохраните DNS-ответ и время наблюдения. Старый ярлык провайдера не должен перевешивать более свежую MX-запись.

Проверьте маршрут и профиль провайдера

Публичный инструмент проверки домена Emvero показывает, может ли домен принимать почту. Если сервер назначения совпадает с известным профилем провайдера, результат может содержать его идентификатор. Исходные имена MX-серверов и значения приоритетов инструмент не показывает. Для их проверки используйте dig.

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