Null MX — запись MX со значением 0 .: домен объявляет, что не принимает почту. Если такой ответ получен для домена получателя, сначала выясните, нужен ли на нём почтовый ящик: для домена без почты это нормальная настройка, для рабочего адреса — повод проверить DNS.
Сама запись показывает опубликованное правило, но не доказывает намерение владельца. Ниже — порядок проверки, который помогает отделить осознанный запрет от ошибки после переноса зоны и выбрать действие без лишних изменений.
Что означает точка в MX
В обычной MX-записи указано имя почтового сервера, а в Null MX вместо него стоит точка. По RFC 7505, у такого домена должна быть единственная MX-запись; сочетать её с обычными MX нельзя.
Отсутствие MX и Null MX — разные ситуации. Если MX нет, SMTP предусматривает поиск адреса через A/AAAA; Null MX явно сообщает об отсутствии почтового сервиса. При этом наличие сайта на домене не подтверждает работоспособность почты.
1. Уточните, какой домен проверять
Возьмите часть адреса получателя после @. Для условного адреса user@example.com проверяйте example.com, а не адрес страницы сайта с www.
Запишите ожидаемое поведение: домен только для сайта, отдельный технический поддомен или домен корпоративной почты. Сверьте его с настройками почтового провайдера и ответственным за DNS; не удаляйте запись только потому, что проверяющий сервис пометил её как необычную.
Если проблема возникает при отправке формы, отдельно определите роль домена: он используется у получателя, у видимого отправителя или у адреса возврата ошибок. Это разные точки проверки, и MX домена сайта может вообще не относиться к адресу назначения.
2. Посмотрите полный DNS-ответ
Если доступна утилита dig, выполните запросы без изменения DNS, заменив пример своим доменом:
dig example.com MX
dig example.com MX +short
Краткий ответ вида 0 . указывает на Null MX. Полный ответ нужен для контекста: смотрите статус запроса, секцию ANSWER и сервер, который ответил. Пустой вывод +short сам по себе не означает Null MX: запрос мог завершиться ошибкой или без MX-записи.
Если нет терминала, используйте DNS-проверку с выбором типа MX и просмотром всех значений. Не ограничивайтесь сообщением «MX найден»: важно увидеть приоритет и имя сервера.
Синтаксис запросов и режим краткого вывода описаны в документации BIND dig.
3. Сравните ответы серверов зоны и кэша
При недавней смене DNS сравните опубликованную зону с ответом резолвера — сервера, которым пользуется проверяющее устройство. Найдите NS, затем запросите MX у каждого авторитетного сервера:
dig example.com NS +short
dig @ns1.example.net example.com MX +norecurse
ns1.example.net здесь условное имя: подставьте сервер из своей делегации. В полном ответе проверьте флаг aa, обозначающий авторитетный ответ; делегированный поддомен может обслуживаться отдельной зоной.
Сохраните небольшую таблицу: сервер, время проверки с часовым поясом, статус и MX. Если один NS возвращает 0 ., а другой — обычный почтовый сервер, сначала устраняйте расхождение зоны, а не меняйте настройки почтовых клиентов.
Если все авторитетные серверы уже согласованы, а резолвер показывает старый ответ, проверьте кэш и TTL — срок хранения записи. Повторите запрос после истечения оставшегося срока; перезапуск браузера не исправляет кэш внешнего DNS-сервера.
4. Выберите действие по назначению домена
Почта на домене не нужна
Оставьте корректный Null MX, если владелец подтвердил отказ от почты и все серверы зоны возвращают одно значение. Проверьте, что этот домен не указан на сайте как адрес для связи и не используется в рабочих почтовых настройках.
Не переносите вывод автоматически на соседние поддомены: для адреса с другим доменным именем выполните отдельную проверку MX.
На домене должны работать ящики
Сверьте записи с инструкцией действующего почтового провайдера. Согласованно замените Null MX на его MX-набор, не угадывая имя сервера и приоритеты; перед изменением сохраните исходные значения для отката.
После обновления проверьте каждый NS, затем резолвер и контрольную доставку на разрешённый тестовый ящик. Если DNS уже верен, но письмо не приходит, переходите к SMTP-ответу и журналу доставки, а не продолжайте менять зону наугад.
Письма не уходят с сайта
Название no-reply не делает Null MX безопасным для отправителя. RFC 7505, раздел 4.2 предупреждает о риске отказа при использовании такого домена в адресах отправителя.
Проверьте настройки отправки и возврата ошибок у почтового провайдера. Для разбора всей цепочки используйте руководство «Письма с сайта не приходят»: оно поможет отделить DNS-проблему от сбоя формы или SMTP.
Как зафиксировать результат и передать проблему
Проверка завершена, когда назначение домена подтверждено, авторитетные ответы согласованы и результат соответствует задаче: отказ от почты ожидаем либо контрольное письмо доставляется. DNS-ответ не проверяет существование ящика, фильтрацию спама или выполнение формы.
Мониторинг доступности сайта в Web-Puls помогает отдельно следить за веб-страницей, но успешный HTTP-ответ не подтверждает доставку писем. Для почты нужен собственный контроль результата.
Если рабочий домен неожиданно получил Null MX и причина изменения непонятна, отправьте заявку на диагностику или воспользуйтесь контактами. Укажите домен, время появления проблемы, недавние изменения и обезличенные ответы DNS; специалист оценит задачу и предложит формат работ. Пароли, содержимое переписки и реальные адреса получателей передавать не нужно.