Перевірка 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-записи домену онлайн

1. Відкрийте перевірку DNS і введіть домен: example.com. Протокол і шлях можна не прибирати — інструмент сам виділить ім'я хоста з адреси.
2. Для піддомену вводьте його повністю: www.example.com, shop.example.com. Записи в кожного імені свої, і CNAME зазвичай стоїть саме на піддомені.
3. Звірте результат із тим, що видав хостинг або поштовий сервіс: IP в A-записі, імена в MX, рядки в TXT.
4. Зверніть увагу на стовпець 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.com

dig 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-записів і що в них перевіряти

Перевірка CNAME-запису

CNAME каже: «це ім'я — псевдонім іншого імені, питайте там». Його ставлять на піддомени, що вказують на зовнішній сервіс: конструктор сайтів, CDN, магазин на платформі. Перевірити CNAME-запис домену можна онлайн, вказавши піддомен у перевірці DNS, або командою dig www.example.com CNAME +short.

• CNAME не може співіснувати з іншими записами на тому самому імені. Тому на корені домену (example.com, де обов'язково є NS і SOA) звичайний CNAME ставити не можна. Деякі DNS-провайдери пропонують заміну — ALIAS, ANAME або «вирівнювання» CNAME (flattening): ззовні такий запис виглядає як звичайний A.
• Ланцюжки CNAME → CNAME → CNAME працюють, але сповільнюють розв'язання імені й ускладнюють пошук помилок.
• CNAME на неіснуюче ім'я — часта причина того, що піддомен «не відкривається» після відключення зовнішнього сервісу.
• Крапка в кінці. У деяких панелях значення треба писати із завершальною крапкою, інакше до нього допишеться ваш домен і вийде shop.example.net.example.com.

Як перевірити TXT-запис домену

1. Визначте, на якому імені має лежати запис. SPF і підтвердження Search Console — на самому домені (у панелі DNS це зазвичай «@»), DMARC — на _dmarc.example.com, DKIM — на селектор._domainkey.example.com. Підтвердження інших сервісів — там, де вказав сервіс.
2. Перевірте онлайн. Для самого домену — перевірка DNS: на вкладці TXT будуть усі TXT-записи з TTL. Імена з підкресленням загальна перевірка не приймає — для них є перевірка SPF, перевірка DKIM і перевірка DMARC.
3. Або з командного рядка:

   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

   Остання команда питає авторитативний сервер напряму — так запис видно одразу після додавання, без очікування кешів.
4. Звірте значення посимвольно з тим, що видав сервіс: зайвий пробіл, обрізаний ключ або лапки всередині значення ламають перевірку.

Запис підтвердження 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 однаковий пріоритет, відправники розподіляють пошту між ними — це звичайне балансування.

1. Введіть домен у перевірку MX-записів: вона покаже поштові сервери за пріоритетом, їхні IPv4 та IPv6, зворотні записи PTR і розпізнає поштового провайдера.
2. Або виконайте nslookup -type=mx example.com чи dig MX example.com +short — відповідь виглядає як 10 mx1.example.net.
3. Переконайтеся, що кожне ім'я з MX саме розв'язується в адресу: dig A mx1.example.net +short.
4. Звірте список з інструкцією поштового сервісу: зазвичай він вимагає видалити всі старі MX, а не додати свої поруч.

Якщо MX-записів немає, відправники за RFC 5321 спробують доставити пошту на A/AAAA-адресу самого домену — це називають неявним MX. Домену, який пошту не приймає взагалі, правильно опублікувати null MX — запис 0 . (RFC 7505): відправник одразу поверне лист, не намагаючись доставити. Немає ні MX, ні A — пошта на домен не доставляється.

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 залишили попередній.

Чек-лист переїзду на інший хостинг

1. За добу знизьте час життя записів — тоді перемикання підхопиться швидко.
2. Зафіксуйте поточні записи: A, MX, TXT і NS мають бути виписані до змін.
3. Запустіть сайт на новому сервері й перевірте його за IP, не чіпаючи домен.
4. Перемкніть A-запис і стежте за відповіддю різних резолверів.
5. Переконайтеся, що пошта не відпала: MX і SPF під час переїзду забувають найчастіше.
6. Поверніть попередній час життя записів і перевірте SSL-сертифікат на новій адресі.