MX-записи: что это, как проверить и зачем нужны для валидации email

Каждое электронное письмо начинается с DNS-запроса. Прежде чем сервер попытается доставить сообщение, он спрашивает: «Кто принимает почту для этого домена?» Ответ хранится в MX-записи. Без неё письмо просто некуда отправить.

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

MX расшифровывается как Mail Exchanger. Это тип DNS-записи, который указывает на сервер, ответственный за приём электронной почты для конкретного домена. Когда вы отправляете письмо на адрес user@example.com, ваш почтовый сервер обращается к DNS и ищет MX-запись для example.com.

MX-запись содержит два значения: приоритет (число) и имя хоста почтового сервера. Чем меньше число приоритета, тем выше предпочтение. Если основной сервер недоступен, отправитель пробует следующий по приоритету.

example.com.    IN  MX  10  mail1.example.com.
example.com.    IN  MX  20  mail2.example.com.
example.com.    IN  MX  30  mail3.example.com.

В этом примере mail1.example.com - основной сервер (приоритет 10). Если он не отвечает, почта пойдёт на mail2 (приоритет 20), потом на mail3 (приоритет 30). Это встроенная отказоустойчивость.

Как MX-записи работают на практике

Допустим, вы отправляете письмо на ivan@company.ru. Вот что происходит за кулисами:

1. Ваш почтовый сервер извлекает доменную часть адреса: company.ru
2. Отправляет DNS-запрос типа MX для company.ru
3. DNS-сервер возвращает список MX-записей с приоритетами
4. Сервер выбирает запись с наименьшим приоритетом и резолвит её hostname в IP-адрес (A или AAAA запись)
5. Устанавливает SMTP-соединение по порту 25 и начинает передачу письма

Весь процесс занимает миллисекунды. Но если на шаге 3 ответ пустой - письмо доставить невозможно. Отправляющий сервер вернёт bounce: «домен не принимает почту».

MX-записи реальных почтовых сервисов

Посмотрим, как выглядят MX-записи у крупных провайдеров. Это полезно для понимания, на какой инфраструктуре работает конкретный домен.

Gmail (google.com)

$ dig MX gmail.com +short
5   gmail-smtp-in.l.google.com.
10  alt1.gmail-smtp-in.l.google.com.
20  alt2.gmail-smtp-in.l.google.com.
30  alt3.gmail-smtp-in.l.google.com.
40  alt4.gmail-smtp-in.l.google.com.

Пять серверов. Основной с приоритетом 5, четыре резервных. Google использует распределённую инфраструктуру, поэтому каждый из серверов на самом деле - это балансировщик перед тысячами машин.

Mail.ru

$ dig MX mail.ru +short
10  mxs.mail.ru.

Одна запись. Резервирование реализовано на уровне DNS-балансировки: за именем mxs.mail.ru стоят несколько A-записей. Такой подход тоже работает, просто отказоустойчивость построена иначе.

Корпоративный домен на Google Workspace

$ dig MX company.com +short
1   aspmx.l.google.com.
5   alt1.aspmx.l.google.com.
5   alt2.aspmx.l.google.com.
10  alt3.aspmx.l.google.com.
10  alt4.aspmx.l.google.com.

По MX-записям сразу видно, что домен пользуется Google Workspace. Это важная информация: зная провайдера, валидатор может применить специфичные для него правила проверки.

Как проверить MX-записи: dig, nslookup, host

Три утилиты командной строки, которые решают задачу. Все предустановлены в Linux и macOS. На Windows доступен nslookup из коробки, dig можно поставить через BIND tools.

dig (рекомендуемый)

# Базовый запрос
dig MX example.com

# Только ответ, без лишнего
dig MX example.com +short

# Через конкретный DNS-сервер (например, Google Public DNS)
dig MX example.com @8.8.8.8 +short

# С трассировкой - видно всю цепочку резолвинга
dig MX example.com +trace

Флаг +short убирает всю служебную информацию и оставляет только результат. Для скриптов и быстрой проверки этого достаточно. +trace полезен для диагностики: показывает запросы от корневых серверов до конечного ответа.

nslookup

# Запрос MX-записей
nslookup -type=mx example.com

# Через конкретный DNS-сервер
nslookup -type=mx example.com 8.8.8.8

Вывод менее удобный, чем у dig, но nslookup есть на любой системе. Подходит для быстрых проверок, когда dig не установлен.

host

# Самый лаконичный вариант
host -t MX example.com

Минимум вывода. Одна строка на каждую запись. Удобно для скриптов, где нужно быстро получить список серверов.

Пример полного вывода dig

$ dig MX yandex.ru

;; QUESTION SECTION:
;yandex.ru.                  IN      MX

;; ANSWER SECTION:
yandex.ru.           7200    IN      MX      10 mx.yandex.net.

;; Query time: 12 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; MSG SIZE  rcvd: 58

Здесь видно TTL (7200 секунд = 2 часа), приоритет (10) и hostname сервера. Query time 12 мс - запрос отработал мгновенно.

Нет MX-записи - что тогда?

RFC 5321 описывает fallback-механизм. Если у домена нет MX-записи, отправляющий сервер ищет A-запись (или AAAA) для самого домена и пытается доставить почту напрямую на этот IP. На практике это работает, хотя и встречается редко.

# Нет MX
$ dig MX tinydomain.org +short
(пустой ответ)

# Но есть A-запись
$ dig A tinydomain.org +short
93.184.216.34

# Сервер попробует доставить почту на 93.184.216.34:25

Отдельный случай - null MX. Это MX-запись с приоритетом 0 и hostname «.» (точка). Определён в RFC 7505. Означает: домен явно отказывается принимать почту.

example.org.    IN  MX  0  .

Если домен возвращает null MX, любой адрес на этом домене невалиден. Никакого fallback-а, никаких попыток доставки. Для валидатора это однозначный reject.

Роль MX-записей в валидации email

Проверка MX - второй этап в конвейере валидации, сразу после синтаксического разбора адреса. И один из самых эффективных по соотношению скорость/результат.

Синтаксическая проверка отсеивает 2-3% невалидных адресов. Проверка MX добавляет ещё 8-12%. Это адреса на доменах с опечатками (gmial.com, gamil.com), несуществующих доменах, доменах с истёкшей регистрацией. Один DNS-запрос за 50-200 мс - и десятая часть мусора убрана.

Но MX-проверка не отвечает на вопрос «существует ли конкретный ящик». Домен gmail.com прекрасно принимает почту, но адрес qwerty12345zzz@gmail.com скорее всего не существует. Чтобы проверить конкретный ящик, нужен следующий этап - SMTP handshake.

Что MX-проверка даёт валидатору

• Домен принимает почту или нет. Фундаментальная проверка. Нет MX и нет A-записи = адрес мёртв.
• Какой почтовый провайдер. По MX-серверу видно, где хостится почта: Google Workspace, Microsoft 365, Yandex, собственный сервер. Это позволяет применять специфичные правила дальнейшей валидации.
• Catch-all вероятность. Корпоративные серверы на Exchange часто настроены как catch-all. Зная провайдера, валидатор корректирует оценку.
• Куда подключаться для SMTP. Для SMTP-проверки нужен IP-адрес сервера. Его получают именно из MX-записи.

MX-проверка в коде: минимальные примеры

Если вы пишете свой инструмент валидации, проверка MX - одна из первых вещей, которые стоит реализовать. Вот как это выглядит в двух языках.

Python

import dns.resolver

def check_mx(domain: str) -> bool:
    try:
        answers = dns.resolver.resolve(domain, "MX")
        return len(answers) > 0
    except (dns.resolver.NoAnswer,
            dns.resolver.NXDOMAIN,
            dns.resolver.NoNameservers):
        return False

# Использование
domain = "gmail.com"
if check_mx(domain):
    print(f"{domain}: MX найдены, домен принимает почту")
else:
    print(f"{domain}: MX отсутствуют")

Node.js

const dns = require("dns").promises;

async function checkMx(domain) {
  try {
    const records = await dns.resolveMx(domain);
    // Сортируем по приоритету
    records.sort((a, b) => a.priority - b.priority);
    return records;
  } catch (err) {
    return [];
  }
}

// Использование
const records = await checkMx("gmail.com");
if (records.length > 0) {
  console.log("Основной сервер:", records[0].exchange);
}

Оба примера намеренно упрощены. В продакшене добавьте таймауты, кэширование результатов (TTL из DNS-ответа), обработку null MX и fallback на A-запись.

Частые проблемы с MX-записями

За годы работы с DNS-валидацией мы собрали набор ситуаций, которые ломают проверку или дают ложные результаты.

• MX указывает на IP вместо hostname. По RFC 5321 MX-запись должна содержать доменное имя, не IP-адрес. Тем не менее такие записи встречаются. Большинство серверов их обработают, но технически это ошибка.
• MX указывает на CNAME. Ещё одно нарушение RFC. MX-запись должна резолвиться в A/AAAA напрямую, без промежуточных CNAME. На практике работает, но создаёт дополнительные DNS-запросы и может вызвать проблемы с некоторыми серверами.
• Высокий TTL при миграции. Компания переехала на новый почтовый сервер, но TTL старых MX-записей - 86400 секунд (сутки). Весь день часть почты идёт на старый сервер. Перед миграцией снижайте TTL до 300 секунд за сутки.
• Забыли обновить MX после смены хостинга. Домен переехал на новый DNS, а MX-записи не перенесли. Результат: почта перестаёт приходить. Проверяйте MX после любых изменений в DNS.
• Одинаковые приоритеты. Два сервера с приоритетом 10 - это валидная конфигурация. Почта распределяется между ними случайным образом. Полезно для балансировки нагрузки.

Приоритеты MX: как правильно настроить

Схема нумерации зависит от задачи. Три типичных сценария.

Один сервер, один бэкап. Классика для небольших компаний. Основной сервер обрабатывает всю почту, резервный включается только при сбое.

company.ru.   IN  MX  10  mail.company.ru.
company.ru.   IN  MX  20  backup.company.ru.

Балансировка нагрузки. Два сервера с одинаковым приоритетом. Отправляющие серверы распределяют почту между ними примерно поровну.

company.ru.   IN  MX  10  mail1.company.ru.
company.ru.   IN  MX  10  mail2.company.ru.
company.ru.   IN  MX  20  backup.company.ru.

Облачный провайдер. Если вы используете Google Workspace, Microsoft 365 или Yandex 360, провайдер сам определяет набор MX-записей. Менять приоритеты в таких конфигурациях не нужно, добавляйте записи строго по документации.

MX-записи и безопасность

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

DNSSEC защищает MX-записи от подмены на уровне DNS. Без DNSSEC атакующий в позиции man-in-the-middle может подменить ответ DNS-сервера и перенаправить почту на свой сервер. Если ваш домен поддерживает DNSSEC, убедитесь, что MX-записи подписаны.

MTA-STS (RFC 8461) - ещё один уровень защиты. Он говорит отправляющему серверу: «При подключении к моему MX используй TLS и проверяй сертификат». Без MTA-STS соединение может быть установлено без шифрования, даже если сервер поддерживает STARTTLS. Google, Yahoo, Microsoft уже поддерживают MTA-STS на своих доменах.

Связь MX-записей с SPF, DKIM, DMARC

MX, SPF, DKIM и DMARC - четыре типа DNS-записей, которые формируют почтовую инфраструктуру домена. Они решают разные задачи, но работают вместе.

MX отвечает за входящую почту: куда доставлять. SPF - за исходящую: откуда разрешено отправлять. DKIM подтверждает, что письмо не было изменено в пути. DMARC связывает SPF и DKIM в единую политику.

Для валидации email все четыре записи дают полезную информацию. MX-проверка стоит первой, потому что она самая быстрая и отсекает самый очевидный мусор. SPF и DKIM проверяются уже на стороне принимающего сервера, когда письмо отправлено.

Быстрый чеклист по MX-записям

• Проверьте MX вашего домена: dig MX yourdomain.com +short
• Убедитесь, что hostname в MX резолвится в A/AAAA-запись
• Используйте разные приоритеты для основного и резервного серверов
• Перед миграцией снижайте TTL до 300 секунд
• Не указывайте IP напрямую в MX - только hostname
• Включите DNSSEC для защиты от подмены записей
• Настройте MTA-STS для принудительного шифрования