MX-запись домена: как проверить и найти причину недоставки почты

Письма перестали приходить, а панель DNS показывает зелёную галочку. В такой ситуации одной проверки «MX существует» мало. Нужно пройти весь маршрут входящего письма: увидеть ответ авторитетных DNS-серверов, сравнить его с публичными резолверами, разрешить имена почтовых узлов в IP, установить соединение на TCP/25 и проверить SMTP с STARTTLS.

Ниже — именно такой runbook. Он помогает отделить ошибку DNS от сетевой блокировки, проблемы TLS и отказа уже внутри почтовой системы.

Нужно быстро увидеть опубликованные записи? Запустите проверку MX-записей домена. Сервис покажет приоритеты и адреса почтовых серверов через публичные DNS. Команды ниже нужны, когда результат надо разобрать глубже.

Что проверять в первые пять минут

Замените example.com своим доменом и начните с четырёх команд:

dig +noall +answer MX example.com
dig +noall +answer MX example.com @1.1.1.1
dig +noall +answer MX example.com @8.8.8.8
dig +short NS example.com

Для Windows без WSL:

Resolve-DnsName example.com -Type MX
Resolve-DnsName example.com -Type MX -Server 1.1.1.1
nslookup -type=mx example.com 8.8.8.8

Нормальный ответ выглядит примерно так:

example.com.  300  IN  MX  10  mx1.example.net.
example.com.  300  IN  MX  20  mx2.example.net.

Здесь 300 — TTL в секундах, 10 и 20 — предпочтения, а последние значения — полные доменные имена почтовых серверов. Меньшее число имеет больший приоритет. Отправляющий MTA сначала пробует доступные серверы с минимальным значением. Если несколько MX имеют одинаковый приоритет, SMTP-клиент должен распределять попытки между ними, а не всегда выбирать первый. Это поведение задано в разделе 5 RFC 5321.

Как MX участвует в доставке письма

MX отвечает за входящий маршрут к домену получателя. Он не определяет, через какой сервер сотрудник отправляет письмо, не настраивает DKIM и сам по себе не влияет на репутацию отправителя.

Когда MTA отправителя обрабатывает адрес user@example.com, он делает MX-запрос для example.com, сортирует пригодные записи по предпочтению, получает A/AAAA для выбранного имени и подключается к нему по SMTP. Обычная межсерверная доставка идёт на TCP/25. Порты 465 и 587 относятся прежде всего к отправке письма клиентом через submission-сервер и не заменяют доступный порт 25 для входящей почты.

Неочевидная деталь: отсутствие MX не всегда означает мгновенный отказ. По RFC 5321, если MX-записей нет, SMTP может считать A/AAAA самого домена неявным MX с приоритетом 0. Полагаться на этот fallback в рабочей почте не стоит: поведение сложнее диагностировать, а веб-сервер на адресе домена обычно не принимает SMTP.

Если домен принципиально не должен принимать почту, используйте Null MX:

example.com.  IN  MX  0  .

Такая единственная запись явно сообщает отправителям «почтового сервиса нет». Смешивать её с обычными MX нельзя; формат и семантика определены в RFC 7505.

Шаг 1. Спросить авторитетные DNS-серверы

Публичный резолвер показывает закэшированную картину. Чтобы понять, что опубликовано у источника прямо сейчас, сначала получите NS домена:

dig +short NS example.com

Затем опросите каждый сервер отдельно:

dig @ns1.provider.net example.com MX +noall +answer +comments
dig @ns2.provider.net example.com MX +noall +answer +comments

Ответы должны совпадать по набору MX. Разный serial в SOA или разные RRset на NS — сильный признак, что зона обновилась не на всех узлах провайдера.

dig @ns1.provider.net example.com SOA +noall +answer
dig @ns2.provider.net example.com SOA +noall +answer

Если вы не уверены, где ломается делегирование, запустите трассировку DNS:

dig +trace MX example.com

Она идёт от корневой зоны через TLD к авторитетным серверам. Так обнаруживаются старые NS у регистратора, отсутствующий glue и lame delegation. Для быстрой визуальной сверки можно параллельно открыть DNS lookup.

Шаг 2. Сравнить кэши публичных резолверов

После изменения зоны ответы некоторое время могут различаться. Сравните хотя бы два независимых резолвера:

for resolver in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo "--- $resolver"
  dig @$resolver example.com MX +noall +answer
done

Если authoritative уже отдаёт новые MX, а публичный DNS — старые, посмотрите оставшийся TTL в ответе. Не меняйте запись туда-сюда: каждое новое изменение продлевает период, когда пользователи видят разные версии.

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

Шаг 3. Проверить цели MX, а не только сам RRset

Каждое имя из MX должно разрешаться хотя бы в один адрес:

dig +short A mx1.example.net
dig +short AAAA mx1.example.net

MX указывает на имя хоста, а не на IP-адрес. Цель MX также не должна быть CNAME: RFC 2181 требует каноническое имя с адресными записями. Некоторые системы всё равно пройдут цепочку alias, другие потеряют дополнительную DNS-информацию или откажут. Здесь «у нас работает» не равно совместимости.

Проверьте все адреса, включая IPv6. Типичный скрытый инцидент: AAAA опубликована, удалённый сервер предпочитает IPv6, а маршрут или фаервол по IPv6 сломан. В итоге часть отправителей получает таймаут, хотя IPv4 и веб-проверка выглядят исправно.

dig +short A mx1.example.net
dig +short AAAA mx1.example.net
nc -4 -vz mx1.example.net 25
nc -6 -vz mx1.example.net 25

Если IPv6 для почтового узла не обслуживается, не публикуйте случайную AAAA «на будущее».

Шаг 4. Проверить TCP/25 и SMTP-диалог

Сначала отделите сетевую доступность от поведения SMTP:

nc -vz mx1.example.net 25

Интерпретация результата:

• succeeded или open — TCP-рукопожатие прошло; это ещё не доказывает приём письма;
• connection refused — адрес достижим, но порт никто не слушает либо соединение активно отклоняет firewall;
• timed out — пакет фильтруется, потерян в маршруте или ответ не возвращается;
• мгновенный ответ от неожиданного IP — перепроверьте NAT, load balancer и DNS.

Проверять нужно снаружи вашей сети. Облачные провайдеры нередко ограничивают исходящий TCP/25, поэтому таймаут с ноутбука или одной VM не доказывает недоступность MX для всего интернета. Повторите тест с другой сети или воспользуйтесь проверкой порта извне.

Чтобы увидеть баннер и STARTTLS:

openssl s_client \
  -starttls smtp \
  -connect mx1.example.net:25 \
  -servername mx1.example.net \
  -crlf

После соединения можно вручную отправить только безопасные диагностические команды:

EHLO diag.example.org
QUIT

В ответе на EHLO ищите 250-STARTTLS, лимит размера сообщения и другие расширения. После TLS проверьте имя сертификата, цепочку и срок действия. Не проводите RCPT-тесты на чужих серверах и не пытайтесь проверять open relay: для диагностики своего домена достаточно контролируемого адреса и своих логов.

Если нужен подробный разбор различий refused, timeout и filtered, используйте нашу шпаргалку по TCP-проверкам.

Шаг 5. Дойти до очереди и логов MTA

Исправные DNS и TCP говорят лишь о том, что удалённый сервер может начать разговор. Письмо всё ещё может быть отклонено на MAIL FROM, RCPT TO или после DATA.

На своей стороне найдите queue ID сообщения и проследите его по логам. Для Postfix базовый набор выглядит так:

postqueue -p
journalctl -u postfix --since "30 minutes ago"
grep 'status=' /var/log/mail.log | tail -n 50

Для Exim:

exim -bp
exigrep 'recipient@example.com' /var/log/exim/mainlog

Смотрите не только SMTP-код, но и расширенный статус вида 4.4.1, 5.1.1 или 5.7.1 и текст удалённого сервера. Первая цифра важнее всего:

• 2xx — команда принята;
• 4xx — временная ошибка, отправитель должен поставить сообщение в очередь и повторить попытку;
• 5xx — постоянный отказ, бесконечный retry не поможет.

Резервный MX не является внешним health check. Отправитель сам решает, когда перейти к следующему серверу и как долго повторять доставку. Поэтому «есть второй MX» не заменяет мониторинг DNS, порта 25, TLS и очереди.

Частые ошибки MX, которые проходят поверхностную проверку

Одинаковый приоритет у основного и слабого резервного сервера

Одинаковые значения означают распределение попыток, а не «первый — основной». Если backup рассчитан только на аварийный трафик, задайте ему большее числовое значение.

Резервный MX не знает получателей

Сервер принимает письмо, но не умеет валидировать адреса или доставить очередь на основной узел. Так появляется backscatter, задержки и накопление недоставляемых сообщений. Резерв должен иметь актуальную маршрутизацию и защиту не слабее основной площадки.

MX смотрит на имя за CDN или обычным reverse proxy

HTTP-прокси не становится SMTP-прокси автоматически. Убедитесь, что IP цели действительно принимает TCP/25 и передаёт соединение нужному MTA.

Из зоны удалили старый MX слишком рано

Во время миграции часть отправителей ещё видит старый RRset из кэша. Старую площадку держат в рабочем состоянии как минимум до истечения прежнего TTL и опустошения её почтовой очереди.

Диагностируют исходящую доставку только по MX

MX домена получателя может быть идеален, а ваши письма всё равно уходят в спам или получают 5.7.1. Тогда проверяйте PTR исходящего IP, SPF, DKIM, DMARC, репутацию, HELO и содержимое письма. Это другая ветка расследования.

Чек-лист безопасной миграции почты

1. За сутки или больше снизьте TTL текущего MX, если прежний TTL позволяет.
2. Создайте ящики, алиасы, маршруты и правила фильтрации на новой стороне до переключения DNS.
3. Проверьте новые SMTP-узлы напрямую по имени и IP: TCP/25, STARTTLS, сертификат, RCPT для контролируемого адреса.
4. Опубликуйте новые MX и спросите каждый authoritative NS.
5. Сравните ответы минимум двух публичных резолверов.
6. Отправьте тестовые письма в обе стороны с независимых провайдеров и сохраните полные заголовки.
7. Следите за очередями и кодами отказов на старой и новой площадках.
8. Не выключайте старый сервер до окончания предыдущего TTL и обработки его очереди.
9. После стабилизации верните нормальный TTL и добавьте мониторинг изменений DNS.

Актуальные значения MX конкретного провайдера всегда сверяйте с его документацией: например, у Яндекс 360 и Google Workspace набор записей и рекомендации могут меняться. Не копируйте адреса из старой статьи или случайного ответа на форуме.

Что поставить на мониторинг

Для рабочей почты полезнее контролировать не одну запись, а цепочку зависимостей:

• RRset MX с ожидаемыми именами и приоритетами;
• одинаковый ответ авторитетных серверов;
• A/AAAA каждой цели MX;
• доступность TCP/25 с внешних площадок;
• наличие STARTTLS, срок и имя TLS-сертификата;
• глубину и возраст очереди MTA;
• долю ответов 4xx и 5xx по удалённым доменам;
• неожиданные изменения DNS и DNSSEC SERVFAIL.

Порог «порт открыт» слишком слабый. Хороший сигнал отвечает на вопрос: может ли внешний MTA сейчас найти правильный сервер, установить защищённую SMTP-сессию и получить ожидаемый ответ.

Проверить текущую публикацию можно в инструменте MX Lookup PingMap, а затем пройти команды из статьи по тому узлу, который выглядит подозрительно.

FAQ: частые вопросы про MX-записи

Как проверить MX-запись домена?

Выполните dig MX example.com, Resolve-DnsName example.com -Type MX в PowerShell или используйте онлайн-проверку MX. Для инцидента дополнительно спросите authoritative NS, разрешите цели MX в A/AAAA и проверьте TCP/25.

Какой приоритет MX считается самым высоким?

Самым предпочтительным считается наименьшее число. MX с приоритетом 10 пробуют раньше MX с приоритетом 20. Одинаковые значения используются для распределения попыток между серверами одного уровня.

Может ли MX-запись указывать на IP-адрес?

Нет. Значение MX — доменное имя почтового узла. У этого имени должны быть A и/или AAAA. Указывать IP непосредственно в MX и использовать CNAME в качестве цели не следует.

Почему письма не приходят, хотя MX правильный?

Чаще всего имя MX не разрешается в IP, недоступен TCP/25, сломан IPv6, SMTP отклоняет получателя, истёк TLS-сертификат или принимающий MTA не маршрутизирует домен. Проверяйте всю цепочку, а не только DNS-строку.

Нужны ли MX-записи для отправки почты?

MX предназначены прежде всего для поиска сервера входящей почты домена. Исходящую отправку определяют настройки submission/MTA, а доверие к письму — в том числе SPF, DKIM, DMARC, PTR и репутация IP.

Что означает MX с точкой вместо сервера?

Запись MX 0 . называется Null MX и явно сообщает, что домен не принимает почту. Она должна быть единственной MX-записью домена.