Узнайте, почему необычные MX‑записи часто встречаются в компаниях, как шлюзы меняют DNS‑карты и как проверять почту, не отклоняя реальные корпоративные домены.
Большинство правил валидации почты строятся вокруг того, что выглядит как «норма»: один домен, пара MX‑записей и знакомый почтовый провайдер. Проблема в том, что многие реальные компании в DNS выглядят не по‑нормальному. Их настройки формируются требованиями безопасности, соответствия, слияниями и старой инфраструктурой, которая должна продолжать работать.
Именно на этом многие команды сгорают из‑за необычных MX‑записей. Совершенно валидный домен может указывать на третьесторонний шлюз, публиковать MX‑хосты, которые не похожи на имя компании, или маршрутизировать почту через цепочку провайдеров и регионов. Если ваши правила ожидают аккуратных шаблонов, вы начнёте отклонять реальных клиентов.
Чрезмерные отказы обычно быстро дают о себе знать: падение конверсии регистрации (особенно для крупных аккаунтов), обращения «я не получил письмо подтверждения», жалобы от отдела продаж, что известная компания была заблокирована, и пользователи переходят на личные адреса, что усложняет сопоставление аккаунтов.
Исправление — не в «принимать всё подряд». Нужно воспринимать проверку доменов как сигнал риска, а не как окончательный вердикт.
Проверка на уровне домена отвечает на вопросы вроде «настроен ли этот домен на приём почты?» и «соответствует ли он известным шаблонам временных адресов?». Она не может гарантировать, что конкретный почтовый ящик существует или примет ваше сообщение. Многие предприятия блокируют SMTP‑прох probes, catch‑all адреса распространены, а некоторые шлюзы отвечают так, что это выглядит подозрительно.
Более безопасный подход — пропускать вероятно корректные домены, даже если они выглядят странно, и применять жёсткие блокировки только в ясных случаях (неправильный синтаксис, несуществующий домен или известные временные провайдеры).
MX‑записи — это записи в DNS, которые говорят отправителю, куда доставлять почту для домена. Если вы отправляете письмо на [email protected], отправитель смотрит MX‑записи company.com, чтобы найти серверы, обрабатывающие входящую почту.
У каждой MX‑записи есть приоритет (иногда называют preference). Сначала пробуют более низкие числа. Часто видно несколько MX‑хостов для резерва, балансировки нагрузки или региональной маршрутизации.
Один важный момент, который многие валидаторы пропускают: DNS говорит, куда пробовать, но не говорит, будет ли принято именно ваше сообщение.
Домен может иметь аккуратные MX‑записи и всё равно отклонить конкретный адрес, потому что почтового ящика не существует, отправитель заблокирован или сработали строгие антиспам‑правила. И наоборот: домен может выглядеть странно в DNS и при этом нормально принимать почту.
Иногда у домена вообще нет MX‑записей. Стандарты электронной почты допускают fallback, когда отправитель пробует A или AAAA запись домена (его основной IP). Многие современные системы этим не пользуются, но старые или кастомные настройки всё ещё работают так.
Многие большие компании не отправляют входящую почту напрямую в почтового провайдера. Они ставят перед собой шлюз, чтобы письма фильтровались и проверялись до попадания в ящики.
Этот слой шлюза — причина того, что необычные MX‑записи так распространены у корпоративных доменов. MX‑имя, которое вы видите в DNS, часто принадлежит вендору по безопасности, общей команде обслуживания или наследованной системе, никак не связанной с публичным брендом.
В типичной конфигурации фильтрация входящей почты и финальное хранение ящиков разделены. Шлюз обрабатывает спам и проверяет на вредоносное ПО, затем ретранслирует чистую почту в систему хранения ящиков (в облаке или на месте).
Поскольку шлюз — отдельная система, цель MX может выглядеть как общий кластер фильтрации (например, "mx1.mailfilter.someprovider.net"), а не как "mail.company.com". Это нормально и не значит, что домен фальшивый.
Часто встречаются региональная избыточность, хосты для отдельных арендаторов без имени компании в домене, смешанная маршрутизация для разных бизнес‑единиц или старые MX, оставленные на время миграции. Поглощения и группы с несколькими брендами добавляют ещё больше «шума», особенно когда почтовые системы объединяются постепенно.
Практический вывод: оценивайте, может ли домен принимать почту, а не выглядит ли имя хоста знакомым.
Некоторые домены выглядят странно при проверке MX, даже если почта работает без проблем. Если ваши правила предполагают «один домен, один почтовый сервер, один провайдер», вы получите ложные отказы.
Многие компании аутсорсят хранение ящиков. MX‑хосты могут указывать на домены провайдера, а не на домен компании. Это выглядит подозрительно только если вы предполагаете, что MX‑хост должен разделять корневой домен с адресом электронной почты.
Сервисы безопасности и фильтрации добавляют ещё один слой. Компания может сначала направлять всю входящую почту через шлюз, а затем передавать её провайдеру хранения. В DNS вы увидите только шлюз.
Несколько MX‑записей сами по себе не тревожный знак. Их часто используют для отказоустойчивости и региональной маршрутизации. Временные миграции тоже могут делать DNS «грязным», когда старые и новые MX‑записи сосуществуют во время тестирования cutover.
Хорошее практическое правило: «странно выглядящая» настройка требует более умной проверки, а не автоматического отказа.
Извне DNS кажется простым: вы запрашиваете MX и получаете ответ. На практике многие легитимные компании могут выглядеть «сломавшимися» в течение короткого времени.
Крупные домены могут публиковать несколько MX‑имён, и эти имена могут изменяться по мере перераспределения трафика или замены узлов провайдерами. Если ваша валидация ожидает стабильный набор имён, нормальные изменения будут помечаться как подозрительные.
Низкие значения TTL тоже создают впечатление нестабильности. TTL — это срок хранения ответа в кэше резолвера. Некоторые предприятия держат TTL короткими, чтобы быстро перенаправлять почту. Два запроса, сделанные с разницей в секунды, могут дать разные ответы, если разные резолверы имеют разные кэши.
Вы также столкнётесь с «серой» категорией ошибок, которые не означают «домен недействителен»: SERVFAIL от перегруженного резолвера, таймауты из‑за сетевых проблем, частичные ответы, временные NXDOMAIN во время распространения или усечённые ответы, требующие повторного запроса по TCP.
Ключевой момент: один запрос редко достаточен для уверенного решения. Рассматривайте временные ошибки DNS как «неизвестно», а не «недействительно», и повторяйте запрос перед блокировкой регистрации.
Когда вы сталкиваетесь с необычными MX‑записями, главный риск — отклонить реальную компанию, потому что её почтовая настройка не похожа на типичный малый бизнес. Валидируйте по слоям и держите «неопределённые» случаи отдельно от «плохих».
Начните с того, что можно проверить без сети. Строгая проверка синтаксиса с учётом RFC отсекает очевидные опечатки и сломанные форматы до обращения к DNS.
Далее подтвердите существование домена. Если DNS возвращает NXDOMAIN, это жёсткий отказ. Для интернационализированных доменов обрабатывайте IDN корректно (часто через punycode), чтобы вы запросили реальное DNS‑имя.
Затем смотрите MX, но не рассматривайте «отсутствие MX» как автоматический отказ. Некоторые легитимные домены специально не публикуют MX. Если вы решаете поддерживать fallback, проверьте A/AAAA и считайте результат менее надёжным.
Практическая последовательность, которая избегает большинства ложных отказов:
Ложные отказы обычно возникают, когда правила предполагают, что каждый домен выглядит «нормально». Корпоративная почта часто проходит через шлюзы и аутсорсинговую инфраструктуру, поэтому необычные MX‑записи не всегда являются тревожным знаком.
Распространённая ошибка — автоматически фейлить, когда имена MX не включают тот же домен. Многие компании используют MX‑хосты, которые не имеют визуальной связи с брендом. Ещё одна — отклонять домены, потому что MX указывает на третьестороннего провайдера. Это блокирует много легитимных организаций.
Таймауты тоже неправильно интерпретируются. Рассматривать единичный таймаут как постоянный отказ — быстрый путь потерять валидные регистрации. Повторяйте с экспоненциальной задержкой и, если возможно, используйте более одного резолвера.
Будьте осторожны с логикой «проверить SMTP и отклонить». Жёсткая блокировка всех catch‑all доменов или всех «неизвестных» результатов причиняет вред, потому что многие предприятия намеренно отключают SMTP‑проверку получателя или используют шлюзы, делающие такую проверку ненадёжной.
Пример: покупатель пытается зарегистрироваться как [email protected]. MX указывает на шлюз безопасности, DNS один раз тайм‑аутится, и ваша система отклоняет адрес. На самом деле домен рабочий, а таймаут был временным.
Корпоративные почтовые настройки часто скрыты за шлюзами и слоями маршрутизации. Это может заставить реальный корпоративный домен выглядеть подозрительно, если ваши правила ожидают простую потребительскую MX‑структуру. Цель — ловить мусор без блокирования реальных клиентов.
Избегайте универсальных allowlist. Они полезны для одного важного клиента, домен которого вы подтвердили другими каналами, но не должны быть стандартом. К тому же они создают тихой обход, на который могут целиться злоумышленники.
Когда вы видите необычные MX‑записи, рассматривайте неопределённость как продуктовую, а не только техническую проблему. Постройте путь мягкого отказа, чтобы пользователь мог продолжить, а вы проверили позже. Например, разрешите создание аккаунта, но отложите приглашения до подтверждения почты или ограничьте рискованные действия до получения более чистого сигнала.
Также полезно настраивать строгость по потоку. Регистрация должна оптимизировать низкое трение с подтверждением позже. Приглашения в команду могут быть строже, потому что их проще злоупотреблять. Формы лидов часто требуют более высокой пропускной способности и лучшей маркировки риска. Сброс пароля должен ориентироваться на подтверждённые аккаунты и доставляемость.
Логирование важно больше, чем многие думают. Сохраняйте причину принятого решения (ошибка синтаксиса, NXDOMAIN, таймаут DNS, отсутствие MX, совпадение с временным провайдером), чтобы поддержка могла объяснить ситуацию, а вы — улучшать правила без догадок.
Потенциальный клиент из крупной компании регистрируется с рабочим адресом: [email protected]. Ваш валидатор проверяет DNS и видит MX‑записи, указывающие на третьесторонний шлюз. Это типично для корпоративных доменов, но ваше правило «MX должен совпадать с доменом» пометило его как подозрительный. Затем один DNS‑запрос тайм‑аутится. Система комбинирует «третьесторонний MX» и «таймаут» и отклоняет регистрацию.
Исправление — безопасно обрабатывать неопределённость:
Необычные MX‑записи чаще сигнализируют о зрелой ИТ‑инфраструктуре, а не о мошенничестве.
Если ваши правила считают что‑то «странным» равным «плохим», вы будете блокировать реальных клиентов. Используйте эти проверки, чтобы оставаться строгими там, где это важно, и гибкими там, где нужно.
Вторичный проход может включать повторный DNS‑запрос, повторную проверку списков временных провайдеров или более глубокую валидацию в отдельном потоке.
Начните с ваших собственных данных. Вытяните выборку недавно отклонённых регистраций и сгруппируйте их по домену. Ищите шаблоны: крупные корпоративные домены, повторяющиеся таймауты DNS и одни и те же хосты шлюзов, которые появляются снова и снова.
Добавьте видимость прежде, чем вводить жёсткие блоки. Если ваша система хранит только «пройдено/не пройдено», вы не сможете учиться на ошибках. Фиксируйте коды причин (syntax_fail, nxdomain, no_mx_found, dns_timeout, disposable_detected) и введите третью исходную категорию для пограничных случаев: unknown или review. Это пропустит реальных корпоративных пользователей с минимальными трениями вместо жёсткой остановки.
Если вы не хотите поддерживать эти правила самостоятельно, Verimail (verimail.co) — один из вариантов, который команды используют для валидации корпоративной почты. Он объединяет RFC‑совместимую проверку синтаксиса, проверку домена и MX, а также сопоставление в реальном времени с известными провайдерами временной почты в одном API‑вызове — это помогает быть точнее, не наказывая нормальные настройки шлюзов.
