MX и TXT записи в DNS

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

MX-запись связывает домен с одним или несколькими почтовыми обменниками, каждый с целочисленным приоритетом. Отправители пробуют сначала наименьший номер; равные приоритеты могут балансироваться. Пример: `10 mail.example.com` и `20 mail-backup.example.com`.

Цель MX должна быть hostname с A или AAAA — не «голый» IP. После смены MX проверьте результат в DNS Checker и дождитесь истечения TTL на старых кэшах. Если входящая почта внезапно попадает в спам, дополните проверку Blacklist Checker.

Production-домены должны публиковать минимум два MX-хоста в разных сетях. Если основной обменник недоступен, RFC 5321 требует от отправителей пробовать следующий приоритет. Зафиксируйте оба приоритета в тикетах и перезапускайте DNS Checker после каждого редактирования MX, чтобы в support были live приоритеты, а не скриншоты панели.

Что такое TXT-записи?

TXT-записи хранят произвольные текстовые строки. Операторы публикуют SPF на apex (или legacy-поддомене) как `v=spf1 ...`, DKIM — с селекторами вроде `default._domainkey.example.com`, DMARC — на `_dmarc.example.com`. Верификация сайтов использует короткие токены (`google-site-verification=...`, `MS=ms...`).

Несколько строк в одном TXT-ответе — норма. Некоторые панели делят длинные DKIM-ключи на части. При диагностике копируйте точное склеенное значение из DNS Checker, а не перепечатывайте из PDF.

TXT также используют для BIMI, MTA-STS и TLS-RPT в продвинутых почтовых setup — всё ещё как текст на предсказуемых именах. Если провайдер ротирует DKIM-селекторы, старый и новый селекторы могут кратко сосуществовать; после каждой ротации запрашивайте TXT и фиксируйте TTL перед удалением retired keys.

SPF, DKIM и DMARC в TXT

SPF перечисляет, какие хосты могут отправлять почту для домена (`v=spf1 include:... ~all`). На одном owner name допустима только одна SPF TXT — дубликаты полностью инвалидируют политику. Объединяйте include вместо второй записи на apex. Проверяйте, что механизм `-all` или `~all` в конце соответствует политике вашей организации.

DKIM публикует публичный ключ на `selector._domainkey.example.com`. Для pass/fail DMARC важно alignment с доменом From. После onboarding relay подтвердите selector TXT в DNS Checker по dashboard провайдера до массовых кампаний. При ротации ключей временно держите оба селектора, пока старые письма не перестанут проходить через прежний relay.

DMARC на `_dmarc.example.com` задаёт политику (`p=none`, `quarantine`, `reject`) и адреса отчётов (`rua=`, `ruf=`). Начните с `p=none` для aggregate reports, затем ужесточайте, когда SPF и DKIM стабильно align. После любой mail migration перепроверьте все три семейства через DNS Checker — одна MX никогда не доказывает корректность SPF.

Как проверить MX и TXT онлайн

Шаг 1 — откройте DNS Checker и введите домен (apex или поддомен). Шаг 2 — выполните полный lookup или сфокусируйтесь на секциях MX и TXT. Шаг 3 — сравните приоритет, цели и TXT-строки с инструкцией почтового провайдера. Шаг 4 — если значения устарели, зафиксируйте TTL и повторите запрос после его истечения.

Для точечного MX-запроса откройте DIG, выберите тип MX и изучите секцию answer. Тот же домен проверьте в WHOIS — NS должны совпадать с DNS-панелью, которую вы редактировали.

Архивируйте вывод checker в тикетах: приоритеты, hostname обменников, полные строки SPF/DKIM/DMARC и TTL. Если Authentication-Results всё ещё показывают сбои после fix, подождите полный TTL-интервал и снова запустите DNS Checker — рекурсивные кэши часто переживают момент Save в панели. Для массовых рассылок сохраняйте также заголовки тестовых писем рядом с DNS-снимком.

Verification TXT и сторонние токены

Search Console, Microsoft 365, Stripe и CA каждый просит уникальный TXT proof на apex или метках `_dnsauth`. Эти токены сосуществуют со SPF как отдельные TXT на том же имени — в отличие от SPF, несколько несвязанных TXT-строк на одном owner допустимы. Не удаляйте verification TXT сразу после успеха — некоторые сервисы периодически перепроверяют домен.

Перед удалением «старых» TXT при cleanup убедитесь, что среди них нет активной verification или DKIM keys. DNS Checker перечисляет каждый TXT-ответ на имени — сравнивайте с docs провайдера, а не угадывайте по памяти. Для Stripe и CA часто нужны отдельные `_dnsauth` или `_acme-challenge` labels — проверяйте точное имя из документации vendor.

После добавления verification TXT сразу запросите через DNS Checker, затем снова после TTL, если vendor всё ещё сообщает failure. Некоторые регистраторы batch publish зоны раз в несколько минут — два одинаковых прохода checker с интервалом пять минут дают уверенность быстрее, чем только refresh UI vendor. При статусе «pending» сохраните оба прохода checker в тикете как доказательство публикации.

Типичные проблемы

Отсутствие SPF — быстрый путь в спам. Неверный приоритет MX отправляет почту на выведенный из эксплуатации хост. Опечатка в verification TXT ломает Search Console или настройку Microsoft 365. Устаревший кэш после смены без предварительного снижения TTL выглядит как «DNS сломан», хотя распространение ещё идёт.

Две SPF-записи на одном имени полностью инвалидируют SPF — объедините в одну TXT. DMARC без согласованных DKIM/SPF фиксирует сбои, но не исправляет их; относитесь к DMARC как к политике поверх работающей аутентификации.

MX на метке только с CNAME ломает resolution на strict resolvers. MX на hostname без рабочих A/AAAA создаёт тихую потерю почты — после каждой смены target обменника подтверждайте цели в DNS Checker.

MX и TXT при миграциях

Mail migrations тихо проваливаются, когда MX обновлён до готовности SPF/DKIM/DMARC у нового провайдера или когда старые MX остаются с более низким приоритетом, чем задумано. Опубликуйте baseline через DNS Checker до cutover, затем diff секций MX и TXT каждый час в migration window. Включите в baseline не только apex, но и поддомены вроде mail или smtp, если они участвуют в маршрутизации.

Снизьте TTL на MX и критичных TXT за 24–48 часов до switch, если DNS-хост позволяет. Подтвердите меньший TTL публично через DNS Checker — некоторые панели показывают 300 секунд, пока live зона ещё отдаёт 3600 до следующего publish cycle. Зафиксируйте в тикете, кто отвечает за publish у регистратора и у DNS-хоста, если это разные команды.

Держите MX старого провайдера с более высоким приоритетом (большим числом), пока не проверите inbound на новом stack, затем удалите retired exchangers. Исходящая почта может ещё использовать старые SPF include, пока не обновите apex TXT — проверьте оба направления через DNS Checker перед закрытием тикета. Зафиксируйте дату удаления старых MX, чтобы через месяц не искать, зачем остался резервный exchanger.

Задокументируйте владельца каждой TXT-строки (marketing verification, IT mail, finance DMARC reports), чтобы будущий cleanup не удалил production authentication records по ошибке.

Частые вопросы

Сколько времени нужно, чтобы изменения DNS стали видны?

Большинство резолверов учитывают TTL (time to live). При TTL 3600 секунд закэшированный ответ может обновиться в течение часа. Перед миграцией снизьте TTL, внесите изменения и проверьте новые значения через DNS Checker, дожидаясь истечения старого кэша.

Можно ли проверить MX и TXT без установки dig?

Да. Откройте DNS Checker, введите домен и отфильтруйте или прокрутите до секций MX и TXT. Для одного типа записи можно использовать DIG с типом MX или TXT.

Почему почта работает, а SPF всё равно не проходит?

SPF авторизует только IP-адреса отправки и цепочки include. Рабочая MX-запись не означает корректный SPF. Сравните исходящие SMTP-IP с цепочкой include в SPF и проверьте TXT-запросом, что опубликованная строка совпадает с документацией почтового провайдера.

Нужно ли публиковать несколько MX-записей?

Да, для production-почты. Опубликуйте минимум два MX-хоста с разными приоритетами (меньшее число — выше предпочтение). Если основной сервер недоступен, отправители пробуют следующий приоритет согласно RFC 5321.

Какой RFC описывает SPF?

SPF определён в RFC 7208 (ранее RFC 4408). DKIM — RFC 6376, DMARC — RFC 7489. Все три публикуются как TXT-записи по предсказуемым именам.

Можно ли публиковать MX и SPF на одной метке hostname?

MX и SPF обычно живут на разных именах — MX на apex или mail-поддомене, SPF как TXT на apex. Никогда не ставьте CNAME на метку, где также нужны MX или SPF. Используйте DNS Checker, чтобы убедиться, что конфликтующие типы не делят один owner name. Если провайдер просит «одну запись для всего», это почти всегда означает разные имена, а не один label с MX и SPF одновременно.

Как часто перепроверять MX и TXT в production?

После каждого изменения DNS или почтового провайдера, плюс ежеквартальные аудиты для доменов с массовой рассылкой. Автоматический мониторинг через DN01 API может предупреждать, когда приоритеты MX или строки SPF расходятся с ожидаемыми значениями. Для критичных доменов полезно сравнивать live TXT с эталоном в runbook после каждого изменения у регистратора или CDN. Раз в квартал достаточно для большинства корпоративных доменов без bulk-рассылок.

Сохраняет ли DNS Checker мои запросы?

Успешные проверки могут попадать в локальную историю недавних запросов в сессии браузера для удобства. Для повторяемого мониторинга без веб-интерфейса используйте документированный API со своим токеном.