DNS записи: что это, какие бывают и как их настроить для сайта и почты в 2026 году

DNS-запись — это строка в DNS-зоне домена на авторитетном DNS-сервере. Она сообщает, на какой IP-адрес вести посетителей сайта, куда доставлять почту и какие текстовые данные нужны для проверки прав на домен. Для сайта, как правило, нужны записи A и AAAA (или CNAME для www), для почты — MX и TXT с SPF, DKIM и DMARC, а менять всё это нужно у того провайдера, чьи NS указаны у регистратора. В этом гайде для читателя 2026 года разобраны типы записей, порядок настройки, сроки обновления, проверка и типичные ошибки.

Ключевые выводы

• DNS-запись состоит из имени, TTL, класса, типа и значения; этот формат описан в RFC 1035.
• Сайту нужны A/AAAA или CNAME, почте — MX и TXT, подтверждению прав в Google Search Console и Яндекс Вебмастере — как правило, TXT.
• Запись применяется только в той зоне, которую обслуживают NS-серверы домена. Правка у «не того» провайдера — самая частая причина жалоб, что DNS «не работает».
• CNAME нельзя ставить на корень домена, а MX не должен указывать на IP-адрес или на CNAME.
• Прямого влияния DNS-записей на позиции в поиске в изученных материалах не найдено, но ошибка в DNS может сделать сайт и почту недоступными.

Что такое DNS-запись и как она устроена

DNS-запись, или ресурсная запись (RR), — это одна строка в зоне домена, которая связывает имя с определённым типом данных. По RFC 1035 запись состоит из пяти частей: имя, TTL, класс, тип и значение. Например, строкаexample.ru. 3600 IN A 192.0.2.10означает, что имя example.ru ведёт на IPv4-адрес 192.0.2.10, а ответ можно кэшировать 3600 секунд.

Важно не путать несколько близких понятий. Домен — это имя, которое вы регистрируете. DNS-зона — набор записей этого домена. DNS-хостинг — сервис, который хранит зону и отдаёт её данные, а авторитетный (авторитетный) сервер — конкретный сервер, который отвечает за зону. Без DNS-хостинга домен не работает, даже если сам сайт доступен на сервере по IP-адресу.

Записи с одинаковым именем и типом образуют набор — RRset, и рекурсивный резолвер получает и кэширует его целиком. Поэтому, если у домена два A-значения для балансировки, они будут жить в кэше вместе. Срок жизни этого кэша задаёт TTL: пока он не истёк, резолвер не обязан заново спрашивать авторитетный сервер.

Практический вывод: прежде чем что-то менять, определите три вещи — какое имя вы правите (корень, www или поддомен), какой тип записи нужен и в какой зоне она должна лежать. Большинство ошибок возникает из-за неверного ответа хотя бы на один из этих вопросов.

Типы DNS-записей и когда какая нужна

В IANA формально зарегистрированы десятки типов записей, но основную повседневную работу выполняют около десяти. В таблице собраны они с типичными значениями и самой частой ошибкой.

Запись CNAME указывает не на IP-адрес, а на другое доменное имя, поэтому подходит для поддоменов вроде www и для сервисов, которые сами выдают хостнейм и могут менять IP. Запись A, наоборот, фиксирует конкретный адрес, и при смене сервера её нужно обновлять вручную.

A или CNAME: как выбрать

Выбор зависит от двух вопросов: что вам дал провайдер — IP-адрес или имя, и на каком имени вы создаёте запись — на корне домена или на поддомене.

• Дали IP-адрес — создавайте запись A (или AAAA для IPv6) на нужном имени.
• Дали имя сервиса и нужен поддомен или www — создавайте CNAME.
• Дали только имя, а настроить нужно корень домена — CNAME не подойдёт, используйте A либо функцию ALIAS/ANAME, если она есть у DNS-хостинга.

Причина запрета на корне простая. По RFC 1034 CNAME на корне домена поставить нельзя: там обязательно присутствуют SOA и NS, а RFC 2181 (§10.1) требует, чтобы при наличии CNAME на узле других наборов записей не было. ALIAS и ANAME — не стандартные типы, а функция конкретных провайдеров, поэтому её наличие и поведение нужно уточнять в документации DNS-хостинга.

Где менять DNS-записи: NS, регистратор или хостинг

Редактировать DNS-записи нужно в зоне того провайдера, чьи NS указаны у регистратора, потому что правки в любом другом месте на работу сайта не повлияют. Регистратор хранит данные о делегировании: какие NS-серверы отвечают за домен. Именно эти серверы отдают записи остальному интернету.

Чтобы понять, где сейчас лежит зона, выполните порядок действий:

1. Узнайте NS домена командойdig NS example.ru +shortили через whois-сервис регистратора. Результат — список имён серверов, например ns1.provider.ru.
2. Определите, кому принадлежат эти серверы: регистратору, хостингу, CDN или конструктору сайтов.
3. Откройте панель именно этого провайдера и найдите раздел управления DNS-зоной.
4. Если NS принадлежат не тому сервису, куда вы собирались вносить записи, либо перенесите записи туда, где зона лежит, либо смените NS у регистратора.

Два сценария: делегирование или правка A-записей

Первый сценарий — делегирование: вы меняете NS у регистратора на серверы хостинга или конструктора, и дальше все записи ведёт новый провайдер. Это удобно, когда сервис требует управлять зоной целиком, но при переезде нужно заранее перенести в новую зону все записи, включая MX и TXT, иначе почта и подтверждения пропадут.

Второй сценарий — NS остаются у регистратора или текущего DNS-хостинга, а вы только меняете A-запись или добавляете CNAME. Он безопаснее для домена с работающей почтой, потому что остальные записи не затрагиваются. Выбор зависит от требований сервиса, к которому вы подключаете сайт, и от того, кто в компании отвечает за домен.

Отдельное предупреждение касается DNSSEC. Если для домена включена подпись зоны, при смене NS нужно учесть DS-запись у регистратора и подпись на стороне нового провайдера, иначе резолверы с проверкой DNSSEC могут перестать отдавать ответы по домену. Подробности зависят от регистратора, поэтому сверяйтесь с его инструкцией.

Какие записи нужны сайту, почте и подтверждению прав

Минимальный набор зависит от задачи, и его удобно собрать в виде чек-листа. Значения всегда берите из инструкции того сервиса, который вы подключаете: универсальных адресов и серверов не существует.

• Минимальный сайт:запись A на корне домена, запись CNAME или A для www, при поддержке IPv6 — AAAA.
• Сайт с доменной почтой:всё перечисленное выше плюс MX-записи почтового сервиса, TXT с SPF, TXT с DKIM и TXT для DMARC.
• Подтверждение прав:TXT-запись с кодом, который выдаёт Google Search Console или Яндекс Вебмастер; она не влияет на работу сайта и почты.
• Дополнительно:CAA, если вы хотите ограничить выпуск сертификатов, и SRV для служб, которым это требуется по инструкции.

Для SEO-специалиста важна последняя строка про подтверждение: TXT-запись на верификацию стоит оставлять в зоне и после успешной проверки. Поисковые сервисы могут повторно проверять права, а удалённая запись способна привести к потере доступа к данным в Search Console или Вебмастере, особенно после смены подрядчика или хостинга.

Вывод для практики: перед любой правкой выпишите существующие записи зоны в отдельный файл. Старые TXT и MX легко потерять при переносе, а вспоминают о них, когда перестаёт работать почта или пропадает верификация.

Как прописать DNS-запись: пошаговая инструкция

Порядок ниже подходит для типовой задачи — привязать домен к хостингу или конструктору сайтов и не сломать остальное. Конкретные названия полей отличаются у регистраторов и хостеров, но логика одинакова.

1. Определите зону.Проверьте NS домена, как описано выше. Ожидаемый результат — понимание, в какой панели править записи.
2. Сохраните текущее состояние.Сделайте скриншот или выгрузку всех записей. Ожидаемый результат — возможность быстро откатиться.
3. Снизьте TTL заранее.Если планируется переезд, уменьшите TTL изменяемых записей за сутки или более до работы, ориентируясь на старое значение TTL. Ожидаемый результат — быстрее обновление кэшей в момент переключения.
4. Создайте или измените запись.Укажите имя (корень обозначается как @ или пустым полем, в зависимости от панели), тип и значение из инструкции сервиса. Ожидаемый результат — запись появилась в зоне.
5. Удалите конфликтующие записи.Старая A на том же имени, где нужен CNAME, или лишний AAAA со старым IPv6 могут вести на прежний сервер. Ожидаемый результат — единственный нужный набор на каждом имени.
6. Проверьте ответ.Выполните запрос к авторитетному серверу и к публичному резолверу, затем откройте сайт. Ожидаемый результат — оба ответа совпадают с тем, что вы внесли.

Для подтверждения прав на сайт действует тот же принцип, только значение приходит из сервиса. В Google Search Console и Яндекс Вебмастере при выборе подтверждения через DNS вам показывают TXT-значение: вы добавляете его на указанное имя, дожидаетесь обновления и нажимаете проверку. Если проверка не проходит сразу, сначала убедитесь, что запись видна из публичного резолвера, и только потом повторяйте попытку.

Для Яндекс 360 для бизнеса и Google Workspace логика также общая: сервис выдаёт MX-значения и TXT для подтверждения домена, а вы вносите их в зону. Если в зоне уже есть MX старого почтового провайдера, не удаляйте их, пока не убедитесь, что новая почта работает и старые письма перенесены.

SPF, DKIM и DMARC: почтовые записи для доменной почты

SPF, DKIM и DMARC — это три TXT-механизма, с помощью которых получатель проверяет, что письмо с вашего домена отправлено разрешённым источником. SPF перечисляет разрешённые серверы отправки, DKIM подписывает письмо криптографически, а DMARC задаёт политику, как поступать с письмами, не прошедшими проверку.

Требования получателей меняются, поэтому точные условия для массовых отправителей, например правила Gmail, нужно сверять по актуальной документации Google для отправителей. Общая рекомендация такова: для домена, с которого идут рассылки, настройте все три механизма и проверьте отчёты через инструменты постмастера.

Две частые проблемы связаны именно с SPF. Во-первых, на домене должна быть одна SPF-запись: если сервисов рассылки несколько, их include объединяют в одну строку TXT, а не создают вторую. Во-вторых, по RFC 7208 при проверке SPF допускается не более десяти DNS-запросов (lookup), и превышение приводит к ошибке проверки. Поэтому каждый новый include стоит добавлять осознанно и убирать неиспользуемые сервисы.

Политику DMARC разумно вводить постепенно: начинают с none, чтобы собирать отчёты и увидеть легитимные источники, затем переходят к quarantine и reject. Резкий переход сразу к reject без анализа может привести к потере писем от сервисов, о которых вы забыли.

Сколько ждать после изменения и что выставлять в TTL

Изменение в зоне появляется на авторитетном сервере сразу или в течение нескольких минут, но пользователи увидят его после того, как истечёт TTL в кэшах резолверов. Именно это называют «обновлением DNS» (в англоязычных материалах — propagation): это не рассылка данных по миру, а естественное устаревание кэшей.

Точное время зависит от значения TTL старой записи и от того, как кэширует конкретный резолвер, поэтому единого срока для всех случаев назвать нельзя. Если старая запись имела TTL 3600 секунд, то часть пользователей может видеть прежнее значение до часа после правки. При значительно большем TTL ожидание вырастет пропорционально.

Практическая рекомендация для переезда: за сутки и более до переключения уменьшите TTL изменяемых записей до небольшого значения, например нескольких минут, затем выполните переключение, а после стабилизации верните TTL к обычному. Сначала нужно подождать, пока истечёт старый TTL, иначе кэши продолжат хранить долгие значения. Конкретные границы TTL у разных DNS-хостингов отличаются, и их стоит смотреть в настройках провайдера.

Если вы только что добавили новую запись, которой раньше не было, ожидание может зависеть и от кэширования отрицательных ответов. Поэтому тест лучше начинать не сразу после первой неудачной проверки, а после небольшой паузы.

Как проверить DNS-записи и найти ошибку

Проверять нужно двумя способами: запросом к авторитетному серверу и запросом к публичному резолверу, потому что расхождение между ними показывает, что кэш ещё не обновился. Если оба ответа неверны, ошибка в самой зоне или в делегировании.

1. Проверьте NS.Командаdig NS example.ru +shortпокажет серверы, которые обслуживают домен. Если там не те серверы, правки в панели не подействуют.
2. Запросите нужный тип.Например,dig example.ru A +short,dig example.ru MX +shortилиdig example.ru TXT +short. В Windows аналог —nslookup -type=MX example.ru.
3. Спросите авторитетный сервер напрямую.Командаdig @ns1.provider.ru example.ru A +shortпокажет, что записано в зоне, без влияния кэша.
4. Сравните с публичным резолвером.Запрос через другой DNS-сервер покажет, что видят пользователи. Расхождение при верном ответе авторитетного сервера — это кэш и TTL.
5. Проверьте доступность сайта и почты.Откройте сайт в окне без кэша и отправьте тестовое письмо, оценив заголовки с результатами SPF, DKIM и DMARC.

Онлайн-сервисы проверки DNS и whois удобны для быстрого взгляда и для ситуаций, когда нет доступа к терминалу. Выбирать среди них «лучший» без собственного тестирования нельзя; достаточно, чтобы сервис показывал тип записи, значение, TTL и ответы нескольких серверов. Для спорных случаев опирайтесь на dig, потому что он показывает необработанный ответ.

Типичные ошибки в DNS и что с ними делать

Большинство сбоев повторяется из проекта в проект и диагностируется за несколько минут. В таблице собраны самые частые ситуации в формате «симптом — причина — действие».

Важно помнить про правило CNAME: если на имени есть CNAME, остальные записи на нём игнорируются, в том числе MX. Это утверждение встречается в старом материале freeCodeCamp, поэтому надёжнее опираться на RFC 2181 (§10.1). Цепочки CNAME нежелательны, хотя сами по себе ошибкой не считаются, а RFC 2181 запрещает использовать псевдоним как значение NS или как часть MX.

Если ни одна строка таблицы не подходит, откатите последнее изменение и повторите его по одному действию, проверяя результат после каждого шага. Такой подход медленнее, но он быстро локализует проблему.

Как DNS-записи связаны с SEO и бизнес-рисками

В изученных источниках нет данных о том, что сами DNS-записи влияют на ранжирование, поэтому утверждать, что запись «повышает позиции», нельзя. Риск другой: ошибка в DNS делает сайт недоступным для посетителей и поисковых роботов, а почту — непригодной для получения заказов и рассылок.

Для SEO-специалиста DNS важен в трёх ситуациях. При смене хостинга он определяет, когда пользователи и роботы начнут обращаться к новому серверу. При подтверждении прав в Google Search Console и Яндекс Вебмастере TXT-запись даёт доступ к данным сайта. При настройке доменной почты записи SPF, DKIM и DMARC влияют на то, дойдут ли письма до получателей.

Поэтому изменения DNS лучше планировать как обычное техническое изменение: с владельцем домена, ответственным за почту, резервной копией зоны и проверкой после правок. Ответственность стоит закрепить заранее, иначе в компании может оказаться, что регистратором владеет один подрядчик, хостингом другой, а почтой третий.

Чек-лист перед следующим изменением DNS-записей

Перед любым изменением зоны полезно пройти короткий список. Он сводит основные риски к проверяемым действиям и подходит как для владельца сайта, так и для подрядчика.

1. Выясните, чьи NS указаны у регистратора, и откройте именно эту зону.
2. Сохраните все текущие записи, включая MX и TXT.
3. Возьмите значения только из инструкции подключаемого сервиса.
4. Заранее уменьшите TTL, если переключение должно пройти быстро.
5. Убедитесь, что на имени нет конфликтов: CNAME рядом с другими записями, второй SPF, лишний AAAA.
6. Проверьте результат через dig или nslookup у авторитетного сервера и у публичного резолвера.
7. Протестируйте сайт, отправку и получение почты и подтверждения прав.

Опирайтесь на первоисточники: RFC 1034 и RFC 1035 описывают базовую модель DNS, RFC 2181 уточняет правила CNAME, RFC 3596 вводит AAAA, RFC 7208 описывает SPF. Требования почтовых сервисов, регистраторов и поисковых систем меняются, поэтому критичные значения перед внедрением сверяйте с их актуальной документацией.