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

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

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

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

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

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

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

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

Google Workspace:

1 aspmx.l.google.com
5 alt1.aspmx.l.google.com
5 alt2.aspmx.l.google.com

Яндекс 360:

10 mx.yandex.net

Домен без почты:

0 .

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

Число перед именем сервера — это приоритет, и меньшее значение означает более высокий. Отправитель начинает с самого низкого числа и переходит к следующему, только если предыдущий сервер недоступен. Абсолютные величины не важны: пары 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. Она явно сообщает, что домен почту не принимает, и отправитель отказывает сразу, вместо того чтобы неделю держать письмо в очереди.

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

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

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

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