Проверка MX-записей домена

Что такое MX-запись

MX-запись отвечает на вопрос «куда доставлять почту для этого домена». Когда сервер отправителя видит адрес ivan@example.com, он запрашивает MX-записи домена example.com и получает список имён почтовых серверов с приоритетами. Дальше он резолвит эти имена в IP-адреса и подключается к первому доступному.

Без MX-записей домен почту не принимает. Это первое, что проверяют сервисы валидации. Если у домена нет MX, адрес на нём заведомо нерабочий, и дальше можно не проверять.

Что покажет проверка

Кроме списка серверов с приоритетами вы увидите IP-адреса, в которые резолвится каждое имя, и определённого по этим именам провайдера: Google Workspace, Microsoft 365, Яндекс 360 и так далее. Это удобный способ понять, на чьей почте сидит компания, до того как отправлять ей письмо.

Отдельно проверяются две поломки, которые не видно в панели DNS: MX, указывающая на CNAME (запрещено RFC 2181), и MX, чьё имя не резолвится ни в один адрес. В обоих случаях запись в панели выглядит нормально, а часть писем не доходит.

Как выглядят записи популярных провайдеров

Так записи выглядят у крупных почтовых сервисов. Данные сняты из DNS 17 сентября 2026 года, у корпоративных тарифов в колонке указан шаблон, который провайдер просит прописать.

Как читать приоритеты

Число перед именем сервера — это приоритет, и меньшее значение означает более высокий. Отправитель начинает с самого низкого числа и переходит к следующему, только если предыдущий сервер недоступен. Абсолютные величины не важны: пары 10/20 и 1/2 ведут себя одинаково.

Одинаковые приоритеты у нескольких записей это не ошибка, а балансировка: отправитель выбирает между ними случайно, и нагрузка распределяется. Именно так устроена схема Google Workspace, где два резервных сервера стоят с одинаковым весом 5.

Отсюда частое заблуждение про «резервный MX». Дополнительный сервер с большим числом помогает, только если он действительно умеет принимать и потом отдавать почту основному. Пустой резерв, который принимает письма и никуда их не передаёт, работает хуже, чем его отсутствие: при сбое основного сервера отправитель получит подтверждение доставки, а письмо исчезнет. Без резерва отправитель просто подождёт и повторит попытку, очереди живут несколько суток.

Ошибки, которые встречаются чаще всего

• IP-адрес вместо имени. В MX допустимо только доменное имя. Запись вида 10 192.0.2.25 часть серверов отвергнет полностью, часть попробует резолвить как имя и тоже не доставит.
• Имя, указывающее на CNAME. Формально запрещено RFC 2181. Google и Microsoft такие записи обрабатывают, а более строгие серверы нет, и потери выглядят случайными.
• Точка в конце имени. В большинстве панелей имя дописывается доменом автоматически, поэтому mx.example.com без точки превращается в mx.example.com.example.com. Проверка покажет это сразу: имя не резолвится.
• Остатки прежнего провайдера. После переезда старые MX часто забывают удалить. Они продолжают принимать часть почты, и письма оседают в ящике, куда никто не заходит.
• MX есть, а SPF не обновлён. Приём почты и право на отправку это разные вещи. Смена почтового провайдера требует правки обеих записей.

Null MX: домен, который почту не принимает

Запись 0 ., где вместо имени стоит одна точка, называется Null MX и описана в RFC 7505. Она явно сообщает, что домен почту не принимает, и отправитель отказывает сразу, вместо того чтобы неделю держать письмо в очереди. Так настроен, например, example.com: домен зарезервирован под примеры в документации.

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

MX-проверка при валидации email

Когда uChecker чистит базу, MX проверяется вторым, сразу после синтаксиса. Из адреса берётся часть после @, по ней уходит DNS-запрос типа MX, и от ответа зависит, есть ли смысл идти дальше.

• MX-записи нашлись. Домен принимает почту, проверка переходит к SMTP.
• MX нет, но у домена есть A-запись. RFC 5321 в этом случае разрешает доставку прямо на адрес из A-записи, так что адрес не бракуется сразу, хотя доверия к нему меньше.
• Нет ни MX, ни A. Принимать почту на этом домене некому, адрес нерабочий.
• NXDOMAIN, то есть домена в DNS нет вовсе. Чаще всего это опечатка в имени домена или давно брошенный проект.

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

Ответы DNS кэшируются на время TTL. Если домен зарегистрировали час назад или компания только что сменила почтового провайдера, резолвер ещё какое-то время отдаёт старые записи. Спорный результат в таком случае стоит перепроверить позже.

Почему одной MX для валидации мало

Наличие MX означает, что домен готов принимать почту, и ничего больше не говорит о конкретном ящике. Домен может быть настроен идеально, а адрес на нём уже год как удалён. Поэтому MX-проверка это только первый фильтр: она отсеивает опечатки в домене и мёртвые домены целиком, дальше нужна SMTP-проверка конкретного адреса.

Второй нюанс это catch-all. Если домен принимает почту на любой адрес, SMTP-ответ будет положительным и для несуществующего ящика. Отличить такой домен можно только пробной проверкой заведомо случайного адреса; в отчёте uChecker такие адреса помечаются отдельным статусом, а не выдаются за валидные.