Письмо ушло — и через минуту вернулось с пометкой вроде «domain not found» или «no mail server for domain». Адрес выглядит нормально, домен открывается в браузере, сайт работает как ни в чём не бывало. А почта всё равно не доходит. Причина почти всегда в одной строчке DNS, которую никто никогда не видит.
Эта строчка называется MX-записью, и она отвечает на единственный вопрос: на какой сервер нести письмо, адресованное домену. Если нужно быстро понять, способен ли конкретный адрес вообще принимать почту, проще всего прогнать его через проверку домена и ящика — валидатор начинает ровно с MX и сразу показывает, есть ли куда доставлять.
Что на самом деле делает MX-запись
MX расшифровывается как mail exchanger, «обменник почты». Это запись в DNS-зоне домена, в которой указано имя сервера, принимающего для этого домена входящие письма. Когда отправляющий сервер видит адрес вида имя@example.com, он отбрасывает всё до собаки и спрашивает у DNS: какие MX у example.com? В ответ приходит список имён с числами-приоритетами.
Дальше отправитель превращает эти имена в IP-адреса, подключается к первому доступному серверу и передаёт письмо. Ни сайт, ни A-запись, ни то, что домен красиво открывается в браузере, на этот путь не влияют. Веб и почта описываются разными записями и обычно живут на разных серверах: домен куплен у регистратора, сайт стоит на хостинге, почта — в Google Workspace, Zoho или на собственном сервере. Одна DNS-зона, несколько независимых строк, и MX среди них отвечает только за входящую почту.
Приоритеты и резервный MX
У каждой MX-записи есть число — приоритет. Правило простое и слегка контринтуитивное: чем меньше число, тем выше приоритет. Запись с 10 обслуживается раньше записи с 20.
- 10 mx1.example.com — основной сервер, туда идут все обычные попытки доставки.
- 20 mx2.example.com — резерв: сюда письмо пойдёт, только если первый сервер не отвечает.
- 10 mx1 и 10 mx2 — одинаковые числа означают, что нагрузка распределяется между серверами примерно поровну.
Резервный MX — это не «второй ящик», а перевалочный пункт. Он принимает письмо, держит его в очереди и передаёт основному серверу, когда тот вернётся в строй. Отсюда неочевидное последствие: если резервный сервер настроен небрежно и не знает списка существующих адресов на домене, он соглашается принять вообще всё, включая мусор, а потом честно пытается это доставить. Так домены с забытым «запасным» MX от старого хостера превращаются в собственный источник спама и отказов.
Как посмотреть MX-запись домена
Быстрее всего — из терминала, одной командой.
- dig MX example.com +short — на macOS и Linux выдаст компактный список приоритетов и имён серверов.
- nslookup -type=mx example.com — то же самое, работает и в Windows, только вывод многословнее.
- dig MX example.com @1.1.1.1 — тот же запрос, но напрямую к стороннему резолверу, мимо кэша провайдера. Полезно сразу после правки записи.
Если терминал не вариант, подойдёт любой веб-сервис проверки DNS: он покажет те же данные плюс то, как запись разошлась по разным резолверам мира. Отдельно держите в голове TTL — время жизни записи в кэше. После изменения MX старое значение продолжает жить в чужих кэшах ровно столько секунд, сколько указано в TTL, и всё это время часть отправителей будет упорно стучаться на прежний сервер.
«У домена нет MX-записи» — что это значит
За одной и той же формулировкой в отчёте валидатора прячутся три разные ситуации.
- MX действительно отсутствует. Домен зарегистрирован, но почтой на нём никто не занимался: он припаркован, куплен под будущий проект или используется только для сайта.
- Домена нет в DNS вообще. Резолвер отвечает NXDOMAIN. Обычно это опечатка в написании (gmial.com вместо gmail.com), непродлённый домен или снятая с обслуживания зона. Письмо отобьётся мгновенно.
- MX есть, но указывает в пустоту. Имя сервера не резолвится, сервер выключен или закрыт файрволом. Формально запись присутствует, фактически доставки нет.
По стандарту, если MX у домена нет, отправитель имеет право попробовать A- или AAAA-запись самого домена — это называется неявным MX. На практике так поступают не все, а сервер, который отвечает по HTTP, почти никогда не умеет принимать почту, так что письмо всё равно упирается в отказ. Полагаться на этот запасной путь нельзя: если домену нужна почта, MX должна быть указана явно.
Почему MX — первая настоящая проверка любого валидатора
Проверка адреса выстраивается лесенкой, от дешёвого шага к дорогому. Сначала синтаксис: есть ли собака, допустимы ли символы, не двойная ли точка. Потом домен и его MX. И только затем, если MX нашлись, — разговор с самим почтовым сервером о конкретном ящике.
Порядок именно такой, потому что MX отсекает огромную долю мусора за один DNS-запрос, вообще без соединения с почтовым сервером. Нет домена или нет MX — адрес мёртв, дальше идти незачем. С этого начинается любая нормальная чистка накопленной базы адресов, и делать это стоит до рассылки, а не после, когда отказы уже подпортили репутацию отправителя.
Дальше начинаются нюансы. Наличие MX не гарантирует, что конкретный ящик существует: домен может быть настроен как catch-all и вежливо соглашаться на любое имя, а может отвечать уклончивым «попробуйте позже» вместо честного ответа. Поэтому результат проверки правильнее читать как три состояния — «точно нет», «похоже, есть» и «сервер не дал определённого ответа». Если нужен живой эксперимент, заведите временный ящик на пару минут и отправьте на него тестовое письмо: увидите весь путь доставки своими глазами.
Типичные ошибки в MX-записях
- MX указывает на CNAME. Стандарт требует, чтобы в MX стояло имя, у которого есть собственная A- или AAAA-запись. Псевдоним вместо этого — частая причина плавающих проблем: у одних отправителей работает, у других нет.
- В MX вписан IP-адрес. Тоже нельзя: там должно быть имя хоста. Многие панели управления DNS такую запись примут молча, а доставка развалится.
- MX потеряли при переезде домена. Самый массовый сценарий: домен перевели к новому регистратору или сменили NS-серверы, зону создали заново, A-запись и сайт восстановили, а MX забыли. Сайт работает, почта исчезла.
- Рядом остался MX старого хостера. Часть писем уходит на сервер, который вы уже не читаете, и там тихо копится.
- Опечатка в имени или лишняя точка. Разные панели по-разному относятся к завершающей точке в имени хоста; в результате получается mx1.example.com.example.com.
MX и SPF, DKIM, DMARC: кто за что отвечает
Эти записи регулярно путают, хотя работают они в противоположные стороны. MX отвечает за входящую почту: куда нести письма, адресованные домену. SPF, DKIM и DMARC — за исходящую: как получатель поймёт, что письмо от вашего имени отправил не самозванец. Все они лежат в одной DNS-зоне, поэтому обычно и ломаются вместе — при переезде домена или смене почтового провайдера. Если хочется разобраться, кто из тройки что подписывает и что проверяет, есть отдельный разбор про SPF, DKIM и DMARC простыми словами.
Практическое правило после любой правки DNS: проверяйте обе стороны. Отправьте письмо с домена наружу и снаружи на домен, посмотрите заголовки полученного письма и убедитесь, что проверки подписи пройдены, а доставка пришла на тот сервер, на который вы рассчитывали. Одностороннего теста тут не хватает.
Частые вопросы
Сколько MX-записей нужно домену?
Достаточно одной, если сервер надёжный. Две и больше имеет смысл заводить ради отказоустойчивости, но резервный сервер должен знать список реальных адресов домена, иначе он превратится в приёмник спама.
Что означают числа 10 и 20 в MX-записи?
Это приоритеты. Меньшее число — более предпочтительный сервер, поэтому 10 обслуживается первым, а 20 берёт письмо только когда первый недоступен. Сами значения произвольны: пары 1 и 2 работают ровно так же, как 10 и 20.
Может ли домен принимать почту без MX-записи?
Формально да, через A-запись домена, если на ней стоит почтовый сервер. Но многие отправители такой вариант не пробуют, а веб-сервер письма принимать не умеет, так что рассчитывать на это не стоит.
Почему адрес не проходит проверку, если сайт домена открывается?
Потому что сайт живёт на A-записи, а почта — на MX, и это независимые настройки. Домен может прекрасно отдавать страницы и при этом не иметь ни одного почтового сервера.
Как быстро начинает работать новая MX-запись?
Как только истечёт TTL старой записи в кэшах резолверов. Если TTL был час, примерно час часть отправителей ещё будет видеть прежний сервер; уменьшить TTL заранее — хорошая привычка перед переездом.
Прежде чем отправлять письмо на незнакомый домен, проверьте его MX и сам адрес — это тридцать секунд против отказа и испорченной репутации.
