Узнайте, что подтверждает проверка MX‑записи, как обрабатывать null MX, неправильно настроенные домены и временные сбои DNS, а также почему повторные попытки и кэширование уменьшают ложные отказы.
Проверка MX-записи показывает, публикует ли домен маршруты для электронной почты в DNS и, следовательно, можно ли теоретически направлять почту в этот домен. Она не подтверждает существование конкретного почтового ящика или то, что сервер примет ваше сообщение.
Нет. Домeн может иметь корректные MX-записи, но всё равно отвергать почту: адрес может не существовать, сервер может блокировать незнакомых отправителей или требовать дополнительных проверок. Рассматривайте MX как сигнал на уровне домена, а не как доказательство доставляемости конкретного ящика.
Null MX — это явная политика «не присылайте сюда почту», заданная владельцем домена. Обычно это выглядит как MX-запись с целью в виде одной точки (.), что означает, что доставлять письма некуда намеренно.
«Нет MX» неоднозначно: некоторые почтовые системы пытаются доставлять по A/AAAA, если MX отсутствует, поэтому домен в некоторых случаях может принимать почту. Null MX однозначен: домен явно говорит, что он не принимает почту, и обычно его безопасно отвергнуть при регистрации.
Потому что MX указывает на имя хоста, а хост может не разрешаться в IP. Проверка A/AAAA для каждой MX-цели выявляет ситуацию, когда маршрутизация вроде бы есть, но до серверов доставить почту нельзя.
Таймаут обычно означает, что ваш резолвер не получил ответ вовремя: потеря пакетов, медленные авторитетные серверы, лимиты запросов или временные сетевые проблемы. Как правило, это ошибка, которую стоит повторить, а не уверенный признак недействительности домена.
SERVFAIL означает, что резолвер не смог завершить запрос—часто из‑за временных проблем с DNS, проблем DNSSEC или с upstream-провайдером. Обычно стоит сделать небольшую повторную попытку и, если проблема сохраняется, считать результат «неизвестным», а не окончательно недействительным.
Практический дефолт — 2–3 попытки в пределах небольшого временного бюджета (примерно 1–2 секунды на DNS-шаг), повторяя только те ошибки, которые можно попробовать снова (таймауты, SERVFAIL). Если после этого всё ещё не удаётся, избегайте жёсткого отказа и переведите адрес в путь «проверить позже».
Кешируйте успешные результаты на основе TTL из DNS, но ограничивайте максимальное время (например, не дольше 24 часов), чтобы не полагаться на устаревшие данные. Для негативных или ошибочных ответов кешируйте недолго (обычно 1–5 минут), чтобы не бомбардировать DNS во время инцидента, и принудительно перепроверяйте при редактировании адреса или если срок кеша истёк.
Храните итог проверки и код причины (например: домен не существует, null MX, временный сбой DNS, у MX-цели нет IP) и метку времени, когда вы проверяли. Если не хотите самим собирать и объединять множество проверок и краёв, Verimail может вернуть структурированный результат, объединяющий проверку синтаксиса, домена/MX и обнаружение временных провайдеров в одном API-вызове.
Проверка MX отвечает на одну практическую задачу: может ли этот домен где‑то принимать почту? Она не пытается определить, реальный ли это человек, и не подтверждает существование конкретного почтового ящика. Проверка смотрит только на настройку маршрутизации почты в DNS для домена.
Когда проверка проходит, это обычно означает, что домен публикует почтовые серверы (или распознаваемый запасной вариант) и теоретически сообщения можно направить в этот домен. Это полезно при регистрации или сборе лидов, потому что фильтрует очевидный мусор вроде выдуманных доменов до того, как вы их сохраните или пошлёте письмо.
Но результат MX — не гарантия существования почтового ящика. У домена могут быть корректные MX-записи и при этом он может отказать в приёме почты по многим причинам: адрес может не существовать, сервер может блокировать незнакомых отправителей или требовать дополнительных проверок перед принятием. MX также не скажет вам, переполнен ли ящик, припаркован ли домен или имеет ли пользователь доступ к почте.
Обычно проверка рассматривается как ранний фильтр, а не окончательный вердикт. Сначала вы проверяете базовый синтаксис, затем подтверждаете, что у домена есть правдоподобный маршрут для почты (MX и связанные DNS‑сигналы), и только после этого применяете более строгие правила, например обнаружение временных провайдеров, риск попадания в спам‑ловушки и белые/чёрные списки.
Результат «неуспех» важен не меньше, чем сам факт неуспеха. Большинство систем видят небольшой набор исходов:
Рассматривайте MX как сильный сигнал на уровне домена, но не как доказательство доставляемости конкретного почтового ящика.
DNS — это телефонная книга интернета. Когда вы вводите домен, DNS возвращает записи, которые говорят компьютерам, куда подключаться и как.
При проверке MX (и любой базовой валидации домена для почты) вы часто встретите несколько типов записей:
DNS‑ответы могут меняться со временем, даже для одного и того же домена. Кеширование — самая распространённая причина: ваше устройство, роутер, провайдер и публичные резолверы могут хранить ответы до истечения TTL. Если владелец домена только что исправил настройку почты, кто‑то увидит новые MX быстро, а кто‑то будет некоторое время получать старые записи.
Резолвер — это DNS‑сервис, который выполняет запросы от вашего имени. Выбор резолвера важен: у разных резолверов разные состояния кеша, сетевые пути и поведение по таймаутам. Один резолвер может моментально вернуть чистый ответ, а другой — выдать временную ошибку, потому что сейчас не может достучаться до авторитетного сервера.
Вот почему домен может выглядеть «хорошо» в офисном Wi‑Fi, но «плохо» с мобильной сети. Например, хост MX может разрешаться в одном месте, а в другом резолвер таймаутит при попытке получить A/AAAA, так что домен кажется сломанным, хотя на деле это краткосрочная проблема DNS.
Эти основы помогают воспринимать результаты DNS как сигналы, а не как абсолютную истину. Они также объясняют крайние случаи вроде null MX, ошибок конфигурации и временных сбоев.
Начните с того, что относитесь к домену как к пользовательскому вводу, а не как к уже чистому значению. Уберите пробелы, удалите завершающие точки и приведите к нижнему регистру. Если пользователь ввёл международные символы (например, ü или 例), конвертируйте домен в IDN‑форму (часто называют punycode) перед запросом в DNS, чтобы проверять то, что реально хранится в DNS.
Далее выполните поиск MX для нормализованного домена. Если есть несколько записей, сортируйте их по приоритету (меньшие числа пробуются первыми). Порядок важен, если вы делаете более глубокие проверки, потому что у «хорошего» домена может быть одна нерабочая MX и одна рабочая.
После получения MX‑записей проверяйте цели, а не только факт их наличия. Каждая MX‑запись указывает на имя хоста, и это имя должно разрешаться как минимум в одну A/AAAA запись. Если нет — почтовые серверы не смогут достучаться до него, даже если MX присутствует.
Когда MX отсутствует, проверьте, есть ли у базового домена A/AAAA. Многие системы рассматривают это как запасной вариант, поскольку некоторые серверы доставляют на A/AAAA, если MX нет. Но лимит остаётся: это по‑прежнему не доказывает, что домен принимает почту, и не защищает от доменов, которые намеренно не принимают почту.
Безопасный поток выглядит так:
Не храните только «пройдено/не пройдено». Держите статус, код причины (например: MX_FOUND, NO_MX_BUT_A, MX_TARGET_NO_IP, DNS_TIMEOUT) и отметку времени checked_at, чтобы знать, когда перепроверить.
Null MX — это когда владелец домена ясно говорит: «Этот домен не принимает почту». Это не сломанная настройка и не временный сбой. Это намеренная политика.
В DNS это обычно представлено как MX‑запись с особой целью в виде одной точки (.). Эта точка означает «никуда». Так что MX‑поиск может завершиться успешно и при этом сообщить, что доставлять почту для этого домена нельзя.
Null MX отличается от двух исходов, которые на первый взгляд могут выглядеть похоже:
С 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 с другими сигналами, а не делайте одноразовое решение.
Не каждый неудачный MX‑запрос значит, что домен не принимает почту. Иногда у вашего резолвера (или у провайдера DNS домена) просто короткий перерыв. Если считать каждую ошибку окончательной, вы будете отвергать реальных пользователей во время кратких инцидентов.
Вот распространённые исходы DNS и как они обычно интерпретируются:
Практический подход — разделять ошибки на подлежащие повтору и окончательные. Таймауты, SERVFAIL, REFUSED и усечение обычно стоит «попробовать снова», с небольшим бэкоффом и лимитом (2–3 попытки). Только после повторных неудач имеет смысл отнести домен в категорию «неизвестно», а не «недействительный».
Для отладки логируйте достаточно данных, чтобы видеть паттерны, но без хранения лишней персональной информации. Как правило, достаточно домена (не полного email), кода ошибки и используемого резолвера, количества попыток и временных меток, статуса TCP‑повтора и информации о том, был ли ответ взят из кеша.
DNS обычно быстрый, но не безупречный. Если считать один таймаут окончательным «нет», вы будете отвергать реальных пользователей во время кратковременных сбоев. Хорошая проверка MX балансирует скорость и небольшой запас прочности.
Ограничьте и предсказуемо выполняйте повторы, чтобы пользователь не застрял на форме:
Бэкофф и джиттер означают просто увеличивать интервал между попытками и добавлять небольшую случайность, чтобы избежать синхронных запросов от множества пользователей и пиковой нагрузки на DNS.
Кеширование предотвращает повторные одинаковые запросы. Кешируйте положительные результаты согласно TTL из DNS, но с ограничением (например, не более 24 часов), чтобы не доверять устаревшим данным бесконечно.
Для отрицательных или ошибочных исходов кешируйте недолго (обычно 1–5 минут). Это предотвращает избыточную нагрузку на DNS во время краткого инцидента и помогает вашей системе оставаться устойчивой.
Принудительно перепроверяйте, когда это важно: пользователь редактирует адрес, после долгого простоя активности, или когда время последней проверки превышает ваш максимальный лимит кеширования.
Проверка MX полезна, но легко начать воспринимать её как окончательный вердикт.
Одна ошибка — считать, что «MX есть» значит адрес доставляем. MX лишь говорит, что домен заявляет о приёме почты где‑то. Он не говорит, существует ли ящик, принимает ли сервер незнакомых отправителей или безопасен ли домен для отправки.
Ещё одна ошибка — жёстко отказывать уже при первом таймауте, SERVFAIL или шатающемся ответе DNS. DNS неидеален. Если вы блокируете регистрацию из‑за одного неудачного запроса, вы отвергнете реальных пользователей во время кратковых инцидентов.
Null MX тоже часто неправильно понимают. Null MX — явный сигнал, что домен не принимает почту. Если игнорировать его и всё равно принимать домен, вы получите гарантированные отказы позже.
Многие реализации останавливаются слишком рано после чтения имён MX: они не разрешают MX‑цели в A/AAAA, и из‑за этого пропускают распространённую проблему — когда MX ведут на имена, которые не разрешаются или разрешаются только в неподдерживаемую адресную семью.
Кеширование тоже может навредить, если нет плана по истечению. Хранение результатов «навсегда» значит, что вы будете продолжать отвергать домены, которые временно были сломаны, или принимать домены, у которых почта потом отключилась.
Основные проблемные паттерны в продакшене такие:
Если вы валидируете на регистрации, думайте в терминах уверенности, а не абсолютной достоверности. Повторяйте при временных ошибках, кешируйте результаты ненадолго и комбинируйте проверку MX с другими сигналами.
Используйте этот набор после получения результатов проверки MX:
Конкретный пример: пользователь регистрируется с [email protected] во время краткого сбоя DNS у вашего резолвера. Первый запрос таймаутит и приложение отвергает регистрацию. Если вы повторите 1–2 раза в течение секунды или двух, часто получите корректный ответ без ощутимой задержки формы. Если всё ещё не возвращается ответ, сохраните регистрацию, но пометьте email как «требует последующей проверки» и перепроверьте фоновой задачей.
Храните результаты недолго. Кеширование недавних успехов и неудач сокращает повторные запросы и помогает отличать «домен не принимает почту» от «DNS минуту был шатающимся».
Пользователь пытается зарегистрироваться с рабочим адресом, например [email protected]. Ваше приложение выполняет MX‑проверку в момент регистрации, а в это время у DNS‑провайдера домена короткий сбой.
При первом запросе система не получает однозначного ответа: запрос таймаутит или возвращает SERVFAIL. Это не значит, что домен фейковый — это значит, что резолвер не смог получить ответ в этот момент.
Если вы посчитаете это «недействительным» и заблокируете регистрацию, вы получите ложный отказ. Пользователь повторит попытку через минуту — и всё сработает, что создаст ощущение случайности в валидации.
Более безопасный поток разделяет «определённо плохо» и «временно неизвестно»:
Повторы помогают, потому что многие DNS‑сбои кратковременны. Короткое кеширование помогает, потому что несколько регистраций с одного и того же предприятия могут идти рядом во времени. Если первая попытка не удалась из‑за временного сбоя, слишком долгое кеширование этой ошибки может надолго отрубить реальных пользователей.
Когда в службу поддержки приходит вопрос «почему мой email отклонили?», не обвиняйте пользователя. Лучше сказать: «Мы не смогли подтвердить, что ваш домен мог принимать почту в тот момент из‑за временной ошибки DNS. Попробуйте ещё раз или используйте другой адрес».
Проверка MX — сильный сигнал, но не единственный барьер. Следующий шаг — превратить сырые DNS‑результаты в понятную политику, которую продукт применяет стабильно.
Решите заранее, что делать с каждым исходом. Null MX обычно — жёсткая блокировка, потому что домен явно не принимает почту. Временный сбой DNS редко должен быть постоянным отказом. Неправильные настройки — промежуточная зона: можно разрешить регистрацию, но потребовать подтверждение почты перед важными действиями.
Простая рамка, которую используют многие команды:
Затем объединяйте результаты MX с другими проверками, чтобы не чрезмерно полагаться на DNS. Хорошее покрытие обычно включает проверку RFC‑совместимого синтаксиса, базовую проверку домена, MX‑lookup и обнаружение временных почтовых провайдеров.
Стабильность важнее чистоты. Используйте устойчивые коды причин и сопоставление их с поведением продукта. Если поддержка видит «dns_temporary_failure», а аналитика логирует «invalid_domain», вы не сможете корректно измерять происходящее.
Если не хотите сами поддерживать все пограничные случаи, многоступенчатый валидатор может возвращать единый структурированный ответ вместо того, чтобы вам приходилось собирать отдельные DNS‑и‑блоклист‑вызовы. Например, Verimail (verimail.co) объединяет проверку синтаксиса по RFC, верификацию домена и MX и сопоставление с известными временными провайдерами в одном API‑вызове.
Наконец, заведите цикл обратной связи. Отслеживайте, как часто предупреждения позднее подтверждаются удачей, как часто заблокированные пользователи обращаются в поддержку и совпадают ли всплески с инцидентами резолвера. На основе этого настраивайте повторы и кеширование, чтобы краткие сбои не превращались в потерянные регистрации.
