Проверка TXT-записи, MX-записи и других DNS-записей домена
Проверка TXT-записи и проверка MX-записи — самые частые задачи с DNS: в TXT хранятся SPF, DKIM, DMARC и подтверждения владения доменом, а MX указывает, куда доставлять почту. Быстрее всего проверить DNS-записи домена онлайн — ввести домен в проверку DNS: инструмент бесплатно и без регистрации покажет записи A, AAAA, CNAME, MX, NS, TXT, SOA и SRV вместе с их значениями и TTL. Почтовые серверы с приоритетами подробнее разберёт проверка MX, а из командной строки то же покажут nslookup -type=txt example.com и nslookup -type=mx example.com. Ниже — как читать результат и что делать, если записи «не обновляются».
Как проверить DNS-записи домена онлайн
- Откройте проверку DNS и введите домен:
example.com. Протокол и путь можно не убирать — инструмент сам выделит имя хоста из адреса. - Для поддомена вводите его полностью:
www.example.com,shop.example.com. Записи у каждого имени свои, и CNAME обычно стоит именно на поддомене. - Сверьте результат с тем, что выдал хостинг или почтовый сервис: IP в A-записи, имена в MX, строки в TXT.
- Обратите внимание на колонку TTL — она подскажет, через сколько секунд кэш обновится, если вы только что что-то поменяли.
Инструмент запрашивает записи через резолвер нашего сервера, то есть показывает, что видит одна точка в сети прямо сейчас. Чтобы проверить распространение изменений, сравните ответ с публичными резолверами командами из следующего раздела.
Имена с подчёркиванием, вроде _dmarc.example.com, в общую проверку не вводятся — для почтовых записей есть отдельные инструменты: проверка MX-записей покажет почтовые серверы с приоритетами и IP, проверка SPF разберёт механизмы и include-цепочки, проверка DMARC — политику и адреса отчётов.
Проверка DNS через nslookup и dig
nslookup есть в Windows, macOS и Linux, dig — в macOS и большинстве дистрибутивов Linux. Последний параметр nslookup или аргумент @ у dig задаёт, какой DNS-сервер спрашивать.
nslookup -type=A example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com 8.8.8.8
nslookup -type=CNAME www.example.comdig example.com A +short
dig www.example.com CNAME +short
dig example.com MX +short
dig example.com NS +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short
dig selector1._domainkey.example.com TXT +short
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com AВ PowerShell то же самое делает Resolve-DnsName example.com -Type MX. Чтобы увидеть, что реально записано в зоне, без кэшей по дороге, спросите авторитативный сервер напрямую: сначала dig example.com NS +short, затем dig @ns1.ваш-провайдер.net example.com A. Команда dig +trace example.com пройдёт всю цепочку от корневых серверов и покажет, на каком шаге ответ расходится с ожидаемым.
Типы DNS-записей и что в них проверять
| Запись | За что отвечает | Пример значения | На что смотреть |
|---|---|---|---|
| A / AAAA | IPv4 / IPv6-адрес сайта | 203.0.113.10 | Совпадает ли с вашим сервером; нет ли лишних адресов |
| CNAME | Псевдоним на другое имя | shop.example.net. | Нет ли цепочек и конфликтов с другими записями |
| MX | Почтовые серверы и приоритет | 10 mx1.example.net. | Есть ли вообще и те ли, что нужно |
| TXT | Подтверждения и политики почты | v=spf1 ... ~all | SPF в единственном экземпляре, наличие DMARC |
| NS | Кто обслуживает зону | ns1.example.net. | Совпадают ли с провайдером, где вы правите записи |
| SOA | Параметры зоны | серийный номер, таймауты | Растёт ли серийный номер после изменений |
| SRV | Адреса сервисов | _sip._tcp | Нужна только для отдельных сервисов |
Проверка CNAME-записи
CNAME говорит: «это имя — псевдоним другого имени, спрашивайте там». Его ставят на поддомены, которые указывают на внешний сервис: конструктор сайтов, CDN, магазин на платформе. Проверить CNAME-запись домена можно онлайн, указав поддомен в проверке DNS, или командой dig www.example.com CNAME +short.
- CNAME не может соседствовать с другими записями на том же имени. Поэтому на корне домена (
example.com, где обязательно есть NS и SOA) обычный CNAME ставить нельзя. Некоторые DNS-провайдеры предлагают замену — ALIAS, ANAME или «выравнивание» CNAME: снаружи такая запись выглядит как обычная A. - Цепочки CNAME → CNAME → CNAME работают, но замедляют разрешение имени и усложняют поиск ошибок.
- CNAME на несуществующее имя — частая причина того, что поддомен «не открывается» после отключения внешнего сервиса.
- Точка в конце. В некоторых панелях значение нужно писать с завершающей точкой, иначе к нему допишется ваш домен и получится
shop.example.net.example.com.
Как проверить TXT-запись домена
- Определите, на каком имени должна лежать запись. SPF и подтверждение Search Console — на самом домене (в панели DNS это обычно «@»), DMARC — на
_dmarc.example.com, DKIM — населектор._domainkey.example.com. Подтверждения других сервисов — там, где указал сервис. - Проверьте онлайн. Для самого домена — проверка DNS: на вкладке TXT будут все TXT-записи с TTL. Имена с подчёркиванием общая проверка не принимает — для них есть проверка SPF, проверка DKIM и проверка DMARC.
- Или из командной строки:
Последняя команда спрашивает авторитативный сервер напрямую — так запись видна сразу после добавления, без ожидания кэшей.nslookup -type=txt example.com nslookup -type=txt _dmarc.example.com 8.8.8.8 dig TXT example.com +short dig TXT _dmarc.example.com +short dig @ns1.ваш-провайдер.net TXT example.com +short - Сверьте значение посимвольно с тем, что выдал сервис: лишний пробел, обрезанный ключ или кавычки внутри значения ломают проверку.
| TXT-запись | Имя | Начинается с |
|---|---|---|
| SPF | домен | v=spf1 |
| DKIM | селектор._domainkey.домен | v=DKIM1 |
| DMARC | _dmarc.домен | v=DMARC1 |
| Подтверждение Google Search Console | домен | google-site-verification= |
| Подтверждение Microsoft 365 | домен | MS=ms |
Запись подтверждения Google не удаляйте после того, как ресурс подтверждён: без неё подтверждение может слететь.
Частые ошибки в TXT-записях
- Две записи
v=spf1. По стандарту SPF это ошибка, и проверка перестаёт работать целиком. Механизмы второго сервиса нужно добавить в существующую запись. Учтите: наша проверка SPF разбирает первую найденную записьv=spf1, поэтому дубли ищите в списке TXT проверки DNS или командойdig TXT example.com +short. - Кавычки внутри значения. В большинстве панелей значение вводят без кавычек — панель добавит их сама. Если вставить его в кавычках, они иногда становятся частью текста, и в выводе dig видно
"\"v=spf1 ...\"". - Строка длиннее 255 символов. Одна строка внутри TXT ограничена 255 символами, поэтому длинное значение — обычно DKIM-ключ на 2048 бит — хранится как несколько строк в кавычках в одной записи:
"v=DKIM1; k=rsa; p=MIIB..." "...продолжение". Получатель склеивает их без пробелов. Многие панели делят строку сами; ошибка — создать вместо этого две отдельные TXT-записи. - Неверное имя. В поле «Имя» вписали полный домен, и панель дописала его ещё раз: получилось
_dmarc.example.com.example.com.
Как устроены сами записи и как их настроить — в статьях SPF, DKIM и DMARC и DKIM: запись и селектор.
TXT-записи: SPF, DKIM и DMARC
Если письма с домена уходят в спам, смотрите три TXT-записи:
example.com. TXT "v=spf1 include:_spf.google.com ~all"
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"- SPF — список серверов, которым разрешено отправлять почту от домена. Запись
v=spf1должна быть одна: две SPF-записи делают проверку недействительной. Число DNS-запросов при проверке SPF ограничено десятью, и длинные цепочки include легко его превышают. - DKIM — публичный ключ подписи, лежит по адресу
селектор._domainkey.домен. Селектор задаёт почтовый сервис, без него запись не найти. - DMARC — политика для писем, не прошедших SPF и DKIM:
none(только отчёты),quarantine(в спам),reject(отклонить).
В TXT же хранятся подтверждения владения: например, доменный ресурс в Search Console подтверждается TXT-записью — см. статью о подключении ресурса.
Как проверить MX-записи
MX-запись говорит отправителям, какой сервер принимает почту домена. В ней два поля: приоритет и имя сервера. Чем меньше число, тем выше приоритет: сначала пробуют сервер с 10, при его недоступности — с 20. Если у нескольких MX одинаковый приоритет, отправители распределяют почту между ними — это обычная балансировка.
- Введите домен в проверку MX-записей: она покажет почтовые серверы по приоритету, их IPv4 и IPv6, обратные записи PTR и распознает почтового провайдера.
- Или выполните
nslookup -type=mx example.comлибоdig MX example.com +short— ответ выглядит как10 mx1.example.net. - Убедитесь, что каждое имя из MX само разрешается в адрес:
dig A mx1.example.net +short. - Сверьте список с инструкцией почтового сервиса: обычно он требует удалить все старые MX, а не добавить свои рядом.
Если MX-записей нет, отправители по RFC 5321 попробуют доставить почту на A/AAAA-адрес самого домена — это называется неявным MX. Домену, который почту не принимает вовсе, правильно опубликовать null MX — запись 0 . (RFC 7505): отправитель сразу вернёт письмо, не пытаясь доставить. Нет ни MX, ни A — почта на домен не доставляется.
| Ошибка в MX | Чем грозит |
|---|---|
| MX указывает на IP-адрес | В MX должно быть имя хоста; многие отправители такую запись не примут |
| MX указывает на CNAME | Стандарты это запрещают; большинство серверов терпит, но не все |
| У имени из MX нет A/AAAA | Почта на этот сервер не доставляется |
| MX ведёт на частный IP | Сервер недоступен из интернета |
| Старые MX рядом с новыми | Часть писем уходит к прежнему провайдеру |
| Null MX вместе с другими MX | Противоречивая настройка: удалите либо ., либо остальные записи |
MX отвечает только за приём. Чтобы ваши письма не попадали в спам у получателей, нужны SPF, DKIM и DMARC, а путь конкретного письма покажут его заголовки — см. как прочитать заголовки письма.
TTL и распространение DNS
TTL — время в секундах, на которое резолверы кэшируют ответ. При TTL 3600 провайдер, однажды спросивший вашу A-запись, будет час отдавать старое значение, даже если вы его уже поменяли. Так называемое «распространение DNS» — это и есть постепенное истечение кэшей по всему миру. Смена NS-серверов у регистратора обычно занимает больше времени: у записей в зоне домена верхнего уровня свой, как правило длинный, TTL.
- Перед плановыми изменениями снизьте TTL до 300 секунд — за срок, не меньший старого TTL.
- Если вы проверяли имя до того, как запись создали, отрицательный ответ тоже кэшируется — на время из SOA-записи зоны.
- Локальный кэш тоже мешает: в Windows его сбрасывает
ipconfig /flushdns, в macOS —sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. - Если авторитативный сервер отвечает правильно, а публичные резолверы — нет, ошибки нет: нужно дождаться TTL.
Когда это нужно проверять
- Сайт открывается не у всех. Частая причина — записи изменили недавно, и у части провайдеров ещё старые данные.
- Письма уходят в спам. Смотрите SPF, DKIM и DMARC в TXT-записях.
- Переезд на другой хостинг. Перед переключением полезно зафиксировать текущие записи.
- Подключение внешнего сервиса: почты, CDN, конструктора — почти всегда это CNAME или TXT.
Типичные ошибки
- Записи правят не там. Если NS домена указывают на одного провайдера, изменения в панели другого (например, регистратора) ни на что не влияют. Сначала проверьте NS.
- Две SPF-записи после подключения второго почтового сервиса вместо объединения в одну.
- CNAME на корне домена, ломающий MX и TXT.
- Забытые MX при переезде: сайт работает, а почта перестала приходить.
- Старый IP у www: A-запись корня обновили, а для www оставили прежнюю.
Чек-лист переезда на другой хостинг
- За сутки снизьте время жизни записей — тогда переключение подхватится быстро.
- Зафиксируйте текущие записи: A, MX, TXT и NS должны быть выписаны до изменений.
- Поднимите сайт на новом сервере и проверьте его по IP, не трогая домен.
- Переключите A-запись и следите за ответом с разных резолверов.
- Убедитесь, что почта не отвалилась: MX и SPF при переезде забывают чаще всего.
- Верните прежнее время жизни записей и проверьте SSL-сертификат на новом адресе.