Проверка MX-записи при валидации email

Проверка MX-записи - этап валидации, на котором система запрашивает DNS домена и выясняет, есть ли у него почтовые серверы. Если MX-запись отсутствует, домен не может принимать почту, а адрес на нём бесполезен для рассылки.

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

MX (Mail Exchange) - тип DNS-записи, который указывает, какой сервер принимает почту для домена. Запись содержит два параметра: приоритет (числовое значение) и имя хоста почтового сервера.

У домена может быть несколько MX-записей с разными приоритетами. Почтовый сервер отправителя сначала пробует подключиться к хосту с наименьшим числом приоритета. Если тот не отвечает, очередь переходит к следующему. Это обеспечивает резервирование.

Как именно работает проверка

Валидатор извлекает домен из email-адреса (часть после @) и отправляет DNS-запрос типа MX. Ответ может быть одним из нескольких:

• Есть MX-записи - домен настроен на приём почты. Валидация продолжается.
• MX отсутствует, но есть A-запись - по RFC 5321, если MX-записей нет, отправитель может попробовать доставить почту напрямую по A-записи. Некоторые валидаторы считают это допустимым, но с пониженной уверенностью.
• Ни MX, ни A-записи - домен не принимает почту. Адрес невалиден.
• NXDOMAIN - домен не зарегистрирован или не существует в DNS. Однозначный отказ.

Почему MX-проверка нужна

Синтаксическая валидация пропускает адреса вроде user@fakefakedomain.com - формат корректный, но домена не существует. MX-проверка ловит именно такие случаи. Она быстрая (DNS-запрос занимает миллисекунды) и не требует подключения к почтовому серверу.

По опыту, от 5% до 15% невалидных адресов в типичной базе приходятся на несуществующие домены. MX-проверка убирает их раньше, чем система потратит время на SMTP-подключения.

Нюансы и подводные камни

MX-запись может указывать на «нулевой» хост: MX 0 .. Это явный сигнал: домен существует, но почту принимать отказывается (RFC 7505). Такой адрес невалиден.

Иногда MX-запись указывает на хост, который не отвечает на порту 25. Формально домен имеет почтовый сервер, фактически - нет. MX-проверка этого не увидит, нужен SMTP-запрос.

Результаты DNS кэшируются в соответствии с TTL. Если домен только что создан или его DNS-записи изменились, кэш может содержать устаревшие данные. Профессиональные валидаторы учитывают TTL и при необходимости делают повторный запрос.

Место MX-проверки в цепочке валидации

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

Последовательность выглядит так: синтаксис → DNS/MX → SMTP → дополнительные проверки (catch-all, одноразовые почты, ролевые адреса). Каждый этап отсеивает часть невалидных адресов, экономя ресурсы для следующего.

Примеры из практики

Gmail использует несколько MX-записей с разными приоритетами: gmail-smtp-in.l.google.com (приоритет 5), alt1.gmail-smtp-in.l.google.com (приоритет 10) и ещё три резервных. Яндекс.Почта и Mail.ru устроены аналогично.

Корпоративные домены на Google Workspace или Microsoft 365 имеют MX-записи, указывающие на серверы провайдера. Если компания переехала с одного провайдера на другой и забыла обновить DNS, MX-записи могут указывать на нерабочий сервер. MX-проверка покажет, что записи есть, но SMTP-запрос выявит проблему.