Основы проверки MX‑записей: null MX, повторные попытки и кэширование

Что сообщает проверка MX‑записи (и чего она не показывает)

Проверка MX отвечает на одну практическую задачу: может ли этот домен где‑то принимать почту? Она не пытается определить, реальный ли это человек, и не подтверждает существование конкретного почтового ящика. Проверка смотрит только на настройку маршрутизации почты в DNS для домена.

Когда проверка проходит, это обычно означает, что домен публикует почтовые серверы (или распознаваемый запасной вариант) и теоретически сообщения можно направить в этот домен. Это полезно при регистрации или сборе лидов, потому что фильтрует очевидный мусор вроде выдуманных доменов до того, как вы их сохраните или пошлёте письмо.

Но результат MX — не гарантия существования почтового ящика. У домена могут быть корректные MX-записи и при этом он может отказать в приёме почты по многим причинам: адрес может не существовать, сервер может блокировать незнакомых отправителей или требовать дополнительных проверок перед принятием. MX также не скажет вам, переполнен ли ящик, припаркован ли домен или имеет ли пользователь доступ к почте.

Обычно проверка рассматривается как ранний фильтр, а не окончательный вердикт. Сначала вы проверяете базовый синтаксис, затем подтверждаете, что у домена есть правдоподобный маршрут для почты (MX и связанные DNS‑сигналы), и только после этого применяете более строгие правила, например обнаружение временных провайдеров, риск попадания в спам‑ловушки и белые/чёрные списки.

Типичные исходы проверки MX (и что они обычно значат)

Результат «неуспех» важен не меньше, чем сам факт неуспеха. Большинство систем видят небольшой набор исходов:

• Нет MX‑записей: домен может не принимать почту или полагаться на запасной вариант A/AAAA (разные валидаторы трактуют это по‑разному).
• Null MX: домен явно говорит «не отправляйте сюда почту».
• NXDOMAIN: домен не существует.
• Таймаут / нет ответа: DNS может быть медленным, заблокированным, ограниченным по скорости или временно падать.
• SERVFAIL: резолвер не смог завершить запрос, часто из‑за временной проблемы в DNS.

Рассматривайте MX как сильный сигнал на уровне домена, но не как доказательство доставляемости конкретного почтового ящика.

Базовые понятия DNS, которые полезно знать перед анализом результатов MX

DNS — это телефонная книга интернета. Когда вы вводите домен, DNS возвращает записи, которые говорят компьютерам, куда подключаться и как.

При проверке MX (и любой базовой валидации домена для почты) вы часто встретите несколько типов записей:

• MX: какие почтовые серверы принимают почту для домена (часто с приоритетами).
• A / AAAA: IP‑адрес для имени хоста (A для IPv4, AAAA для IPv6). Цели MX обычно должны иметь такие записи.
• CNAME: алиас, указывающий одно имя на другое. Он не может существовать на том же имени с другими типами записей.
• TXT: текст для политик и проверок почты (SPF, DKIM, DMARC и т. п.).
• TTL (time to live): сколько времени ответ DNS можно кэшировать перед повторным запросом.

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

Резолвер — это DNS‑сервис, который выполняет запросы от вашего имени. Выбор резолвера важен: у разных резолверов разные состояния кеша, сетевые пути и поведение по таймаутам. Один резолвер может моментально вернуть чистый ответ, а другой — выдать временную ошибку, потому что сейчас не может достучаться до авторитетного сервера.

Вот почему домен может выглядеть «хорошо» в офисном Wi‑Fi, но «плохо» с мобильной сети. Например, хост MX может разрешаться в одном месте, а в другом резолвер таймаутит при попытке получить A/AAAA, так что домен кажется сломанным, хотя на деле это краткосрочная проблема DNS.

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

Пошагово: как безопасно проводить проверку MX

Начните с того, что относитесь к домену как к пользовательскому вводу, а не как к уже чистому значению. Уберите пробелы, удалите завершающие точки и приведите к нижнему регистру. Если пользователь ввёл международные символы (например, ü или 例), конвертируйте домен в IDN‑форму (часто называют punycode) перед запросом в DNS, чтобы проверять то, что реально хранится в DNS.

Далее выполните поиск MX для нормализованного домена. Если есть несколько записей, сортируйте их по приоритету (меньшие числа пробуются первыми). Порядок важен, если вы делаете более глубокие проверки, потому что у «хорошего» домена может быть одна нерабочая MX и одна рабочая.

После получения MX‑записей проверяйте цели, а не только факт их наличия. Каждая MX‑запись указывает на имя хоста, и это имя должно разрешаться как минимум в одну A/AAAA запись. Если нет — почтовые серверы не смогут достучаться до него, даже если MX присутствует.

Когда MX отсутствует, проверьте, есть ли у базового домена A/AAAA. Многие системы рассматривают это как запасной вариант, поскольку некоторые серверы доставляют на A/AAAA, если MX нет. Но лимит остаётся: это по‑прежнему не доказывает, что домен принимает почту, и не защищает от доменов, которые намеренно не принимают почту.

Безопасный поток выглядит так:

• Нормализуйте домен (уберите пробелы, приведите к нижнему регистру, обработайте IDN).
• Запросите MX и отсортируйте по приоритету.
• Если MX пустой, запросите A/AAAA для базового домена (только как запасной сигнал).
• Для каждой MX‑цели подтвердите, что она разрешается в A/AAAA.
• Сохраните и результат, и причину, по которой можно принять решение.

Не храните только «пройдено/не пройдено». Держите статус, код причины (например: MX_FOUND, NO_MX_BUT_A, MX_TARGET_NO_IP, DNS_TIMEOUT) и отметку времени checked_at, чтобы знать, когда перепроверить.

Null MX: явный сигнал «не отправлять почту сюда»

Null MX — это когда владелец домена ясно говорит: «Этот домен не принимает почту». Это не сломанная настройка и не временный сбой. Это намеренная политика.

В DNS это обычно представлено как MX‑запись с особой целью в виде одной точки (.). Эта точка означает «никуда». Так что MX‑поиск может завершиться успешно и при этом сообщить, что доставлять почту для этого домена нельзя.

Null MX отличается от двух исходов, которые на первый взгляд могут выглядеть похоже:

• Нет MX: домен не имеет MX‑записей. Некоторые почтовые системы переходят на A/AAAA, поэтому это неоднозначно.
• Временный сбой: домен может принимать почту, но ваш DNS‑запрос в момент проверки не удался (таймауты, SERVFAIL, проблемы резолвера).

С null MX нет двусмысленности. Если проверка возвращает null MX, самое безопасное — считать домен непригодным для приёма почты и блокировать его при регистрации (или требовать другой адрес). Пропуск таких доменов приведёт к предсказуемым возвратам и повредит доставляемости.

То, как вы объясняете это пользователям, важно. Избегайте DNS‑терминов и говорите простым языком:

• “Этот домен не может принимать сообщения. Пожалуйста, используйте другой адрес электронной почты.”
• “Мы не можем отправлять письма на этот адрес. Попробуйте другой домен (например рабочий или личный).”

Также разделяйте null MX и ситуацию «не удалось проверить сейчас». Null MX — уверенный отказ. Временные ошибки должны запускать путь повторных попыток, а не жёсткую блокировку.

Неправильно настроенные домены: распространённые паттерны и как их обрабатывать

Многие почтовые домены не дают однозначного «да» или «нет». Они существуют, но их DNS настолько запутан, что проверка MX даёт смешанные результаты. Цель — не отвергать реальных людей и при этом блокировать домены, которые действительно не могут принимать почту.

Распространённые ошибки конфигурации включают MX, указывающие на несуществующий хост, часто из‑за смены провайдера с оставшимися старыми записями. Ещё одна проблема — когда MX указывает непосредственно на IP‑адрес (что недопустимо: MX должен указывать на hostname). Также встречаются CNAME‑цепочки, которые никуда не ведут, зацикливаются или дают разные ответы в разных резолверах.

Некоторые домены вовсе не имеют рабочего пути доставки: нет MX и нет рабочих A/AAAA. Другие возвращают непоследовательные ответы (MX виден в одном запросе и исчезает в другом), обычно из‑за проблем с распространением записей или ошибочной настройкой DNS‑хостинга.

Жёсткий отказ против мягкого

Классифицируйте на основе уверенности.

Считайте результат жёстким отказом, когда домен явно не может принимать почту — например, некорректная цель MX (IP вместо имени) или MX‑хосты последовательно возвращают NXDOMAIN при повторных проверках.

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

Используйте корзину неизвестно для доменов, которые странные, но не явно сломаны, и комбинируйте результат MX с другими сигналами, а не делайте одноразовое решение.

Временные сбои DNS: почему они происходят и что с этим делать

Не каждый неудачный MX‑запрос значит, что домен не принимает почту. Иногда у вашего резолвера (или у провайдера DNS домена) просто короткий перерыв. Если считать каждую ошибку окончательной, вы будете отвергать реальных пользователей во время кратких инцидентов.

Вот распространённые исходы DNS и как они обычно интерпретируются:

• Таймаут: нет ответа вовремя. Часто потеря пакетов, медленные авторитетные серверы или перегрузка резолвера.
• SERVFAIL: резолвер не смог выполнить запрос (проблемы DNSSEC, upstream‑сбои, сломанные авторитетные серверы).
• REFUSED: сервер отказался отвечать (ограничения по скорости, неправильная настройка, закрытые конфигурации).
• Усечение ответа (TC=1): ответ слишком большой для UDP и требует повторного запроса по TCP.
• NXDOMAIN (для самого домена): домен не существует — обычно это безопасно считать постоянным.

Практический подход — разделять ошибки на подлежащие повтору и окончательные. Таймауты, SERVFAIL, REFUSED и усечение обычно стоит «попробовать снова», с небольшим бэкоффом и лимитом (2–3 попытки). Только после повторных неудач имеет смысл отнести домен в категорию «неизвестно», а не «недействительный».

Для отладки логируйте достаточно данных, чтобы видеть паттерны, но без хранения лишней персональной информации. Как правило, достаточно домена (не полного email), кода ошибки и используемого резолвера, количества попыток и временных меток, статуса TCP‑повтора и информации о том, был ли ответ взят из кеша.

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

DNS обычно быстрый, но не безупречный. Если считать один таймаут окончательным «нет», вы будете отвергать реальных пользователей во время кратковременных сбоев. Хорошая проверка MX балансирует скорость и небольшой запас прочности.

Политика повторных попыток для страницы регистрации

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

• Делайте максимум 2–3 попытки.
• Разносите попытки на 200–500 мс с небольшой случайностью.
• Выделяйте на DNS‑шаг в целом 1–2 секунды.
• Повторяйте таймауты и ошибки типа «сервер не ответил», но не повторяйте явный «домена не существует».
• Если первая попытка идёт медленно, пропустите дополнительные повторы и используйте мягкое решение (например, разрешить регистрацию, но пометить адрес для последующей проверки).

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

Правила кеширования, которые предотвращают повторные проблемы

Кеширование предотвращает повторные одинаковые запросы. Кешируйте положительные результаты согласно TTL из DNS, но с ограничением (например, не более 24 часов), чтобы не доверять устаревшим данным бесконечно.

Для отрицательных или ошибочных исходов кешируйте недолго (обычно 1–5 минут). Это предотвращает избыточную нагрузку на DNS во время краткого инцидента и помогает вашей системе оставаться устойчивой.

Принудительно перепроверяйте, когда это важно: пользователь редактирует адрес, после долгого простоя активности, или когда время последней проверки превышает ваш максимальный лимит кеширования.

Распрострённые ошибки команд при реализации проверки MX

Проверка MX полезна, но легко начать воспринимать её как окончательный вердикт.

Одна ошибка — считать, что «MX есть» значит адрес доставляем. MX лишь говорит, что домен заявляет о приёме почты где‑то. Он не говорит, существует ли ящик, принимает ли сервер незнакомых отправителей или безопасен ли домен для отправки.

Ещё одна ошибка — жёстко отказывать уже при первом таймауте, SERVFAIL или шатающемся ответе DNS. DNS неидеален. Если вы блокируете регистрацию из‑за одного неудачного запроса, вы отвергнете реальных пользователей во время кратковых инцидентов.

Null MX тоже часто неправильно понимают. Null MX — явный сигнал, что домен не принимает почту. Если игнорировать его и всё равно принимать домен, вы получите гарантированные отказы позже.

Многие реализации останавливаются слишком рано после чтения имён MX: они не разрешают MX‑цели в A/AAAA, и из‑за этого пропускают распространённую проблему — когда MX ведут на имена, которые не разрешаются или разрешаются только в неподдерживаемую адресную семью.

Кеширование тоже может навредить, если нет плана по истечению. Хранение результатов «навсегда» значит, что вы будете продолжать отвергать домены, которые временно были сломаны, или принимать домены, у которых почта потом отключилась.

Основные проблемные паттерны в продакшене такие:

• Принимать любую MX‑запись как «доставляемо» без дополнительных проверок.
• Считать первый таймаут или SERVFAIL окончательным провалом.
• Игнорировать null MX и пропускать домен.
• Не разрешать MX‑цели в A/AAAA перед пометкой домена как «хороший».
• Хранить старые вердикты бессрочно вместо регулярных перепроверок.

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

Быстрая чек‑листа перед тем, как пометить домен годным или нет

Используйте этот набор после получения результатов проверки MX:

• Сначала нормализуйте домен (приведите к нижнему регистру, удалите завершающие точки и переведите международные домены в безопасную ASCII‑форму). Убедитесь, что часть домена структурно валидна (нет пробелов, двойных точек или запрещённых символов).
• Считайте маршрутизацию почты «подтверждённой» только если есть пригодные MX‑записи и имена MX разрешаются в IP, либо если у домена есть рабочий A/AAAA‑fallback, на который можно доставлять почту.
• Если обнаружен null MX — остановитесь. Это явный «не отправляйте сюда почту».
• Следите за временными ошибками DNS. При таймаутах или SERVFAIL не помечайте домен как окончательно плохой, пока не сделали повторные попытки в небольшом временном бюджете.
• Записывайте, что произошло: исход, тип ответа и временную метку, чтобы перепроверять, а не гадать.

Конкретный пример: пользователь регистрируется с [email protected] во время краткого сбоя DNS у вашего резолвера. Первый запрос таймаутит и приложение отвергает регистрацию. Если вы повторите 1–2 раза в течение секунды или двух, часто получите корректный ответ без ощутимой задержки формы. Если всё ещё не возвращается ответ, сохраните регистрацию, но пометьте email как «требует последующей проверки» и перепроверьте фоновой задачей.

Храните результаты недолго. Кеширование недавних успехов и неудач сокращает повторные запросы и помогает отличать «домен не принимает почту» от «DNS минуту был шатающимся».

Пример сценария: валидация при регистрации во время нестабильного DNS

Пользователь пытается зарегистрироваться с рабочим адресом, например [email protected]. Ваше приложение выполняет MX‑проверку в момент регистрации, а в это время у DNS‑провайдера домена короткий сбой.

При первом запросе система не получает однозначного ответа: запрос таймаутит или возвращает SERVFAIL. Это не значит, что домен фейковый — это значит, что резолвер не смог получить ответ в этот момент.

Если вы посчитаете это «недействительным» и заблокируете регистрацию, вы получите ложный отказ. Пользователь повторит попытку через минуту — и всё сработает, что создаст ощущение случайности в валидации.

Более безопасный поток разделяет «определённо плохо» и «временно неизвестно»:

• Если домен не существует (NXDOMAIN) — отклоняйте.
• Если домен публикует null MX — отклоняйте.
• При таймаутах или SERVFAIL делайте небольшие повторы (2–3 попытки с короткой паузой).
• Если всё ещё не удаётся, разрешите регистрацию, но пометьте email как «непроверенный» и перепроверьте в фоне.
• Если домен вернул нормальные MX — продолжайте как обычно.

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

Когда в службу поддержки приходит вопрос «почему мой email отклонили?», не обвиняйте пользователя. Лучше сказать: «Мы не смогли подтвердить, что ваш домен мог принимать почту в тот момент из‑за временной ошибки DNS. Попробуйте ещё раз или используйте другой адрес».

Следующие шаги: как превратить проверки MX в надёжную валидацию почты

Проверка MX — сильный сигнал, но не единственный барьер. Следующий шаг — превратить сырые DNS‑результаты в понятную политику, которую продукт применяет стабильно.

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

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

• Блокировать: null MX, явно недействительный домен или известный временный провайдер.
• Предупреждать: таймаут DNS или SERVFAIL — подозрительно, но не доказано как плохое.
• Разрешить, но проверить позже: домен существует, но MX выглядит неправильно или непоследовательно.
• Разрешить: домен и MX выглядят нормально, нет тревожных флагов.

Затем объединяйте результаты MX с другими проверками, чтобы не чрезмерно полагаться на DNS. Хорошее покрытие обычно включает проверку RFC‑совместимого синтаксиса, базовую проверку домена, MX‑lookup и обнаружение временных почтовых провайдеров.

Стабильность важнее чистоты. Используйте устойчивые коды причин и сопоставление их с поведением продукта. Если поддержка видит «dns_temporary_failure», а аналитика логирует «invalid_domain», вы не сможете корректно измерять происходящее.

Если не хотите сами поддерживать все пограничные случаи, многоступенчатый валидатор может возвращать единый структурированный ответ вместо того, чтобы вам приходилось собирать отдельные DNS‑и‑блоклист‑вызовы. Например, Verimail (verimail.co) объединяет проверку синтаксиса по RFC, верификацию домена и MX и сопоставление с известными временными провайдерами в одном API‑вызове.

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