DNS ресурсная запись типа TXT

TXT означает text, то есть текст. В DNS-зоне такая запись состоит из имени, типа, значения и времени жизни TTL. Имя определяет, к какому поддомену относится правило. Для корня домена обычно указывают символ @ или оставляют поле имени пустым — конкретный вариант зависит от панели управления DNS. Значение содержит текстовую инструкцию, токен или набор параметров.

Например, TXT-запись может хранить строку подтверждения, выданную сервисом: verification=код_проверки. После публикации сервис запрашивает DNS и сравнивает найденное значение с ожидаемым. Если строки совпадают, домен считается подтвержденным.

Одна и та же зона может содержать несколько TXT-записей. Это нормальная ситуация, если они предназначены для разных задач. Нельзя заменять существующую запись новой без проверки: удаление SPF, ключей DKIM или записи верификации может нарушить почтовую инфраструктуру и доступ к сторонним сервисам.

Самая распространенная область применения — настройка электронной почты. В TXT-записи публикуется политика SPF, которая перечисляет серверы и механизмы, имеющие право отправлять письма от имени домена. Получающий сервер сопоставляет источник отправки с опубликованным правилом и использует результат при оценке сообщения.

Также TXT применяется для DKIM. Открытый ключ подписи размещается по специальному имени, включающему селектор. Почтовый сервер получателя извлекает ключ из DNS и проверяет криптографическую подпись письма. Для политики DMARC тоже используется TXT-запись: она задает порядок обработки писем, не прошедших проверку, и параметры отчетности.

Кроме почты, текстовые записи нужны для подтверждения домена в сервисах поиска, рекламных кабинетах, облачных платформах, системах связи и инструментах безопасности. Их применяют при выпуске сертификатов через DNS-проверку, подключении корпоративных приложений и настройке отдельных видов защиты от несанкционированного использования домена.

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

Создайте новую запись, выберите тип TXT, затем заполните имя хоста и значение. В поле имени для корневого домена используйте формат, принятый в интерфейсе. Для DKIM, DMARC и ряда проверок требуется конкретный поддомен, поэтому имя нужно переносить без самовольных сокращений. Значение вставляйте целиком, сохраняя знаки, пробелы и разделители параметров.

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

Если панель автоматически ставит кавычки вокруг значения, обычно вручную добавлять их не требуется. Длинные строки некоторые интерфейсы разбивают на части; DNS способен представить их как единое значение. Главное — не менять последовательность символов и не добавлять лишние пробелы.

Для SPF действует важное правило: на одном имени домена должна быть одна действующая SPF-политика. Если создать несколько независимых TXT-строк, начинающихся с v=spf1, принимающие серверы могут получить ошибку множественных записей. Когда нужно разрешить несколько отправителей, их механизмы объединяют в одном значении SPF.

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

DMARC размещают на имени _dmarc. Начинать внедрение обычно безопаснее с наблюдения: политика позволяет собирать результаты проверок, не вводя строгую обработку. После анализа легитимных источников отправки можно постепенно усиливать требования. Неправильно настроенные SPF и DKIM при жесткой DMARC-политике способны привести к отклонению даже законных писем.

После сохранения записи необходимо дождаться обновления DNS. Фактическое время зависит от TTL, кэшей рекурсивных серверов и особенностей провайдера. Даже если панель показывает новую запись сразу, внешние резолверы могут некоторое время возвращать прежний ответ. Поэтому проверять результат нужно после периода распространения изменений.

При диагностике убедитесь, что запрос выполняется к правильному полному имени. Частая ошибка — дублирование домена: пользователь вводит имя вместе с доменом в панели, которая автоматически дописывает его второй раз. Другая проблема — размещение записи не в той DNS-зоне или у неактуального поставщика DNS.

Не объединяйте несвязанные TXT-записи в одну строку. Запись верификации, SPF и DMARC должны оставаться отдельными значениями и располагаться на требуемых именах. Перед удалением старой записи выясните ее назначение: она может использоваться почтовым сервисом, сертификатом или системой подтверждения владения доменом.

Если проверка не проходит, сравните опубликованное значение с исходной строкой посимвольно. Проверьте имя хоста, отсутствие лишних кавычек, правильность селектора, актуальность NS-серверов и наличие конфликтующих политик. При работе с почтой дополнительно убедитесь, что отправляющие серверы действительно соответствуют правилам SPF и подписывают сообщения ожидаемым ключом DKIM.