TXT-запись (Text record)

Автор

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

TXT-запись (Text record) — это тип DNS-записи, предназначенный для хранения произвольной текстовой строки, которая используется внешними сервисами для верификации домена, настройки почтовых политик (SPF, DKIM, DMARC), а также для подтверждения прав собственности на домен при подключении к сторонним платформам.

Ключевой стандарт 2026 года: максимальная длина одной TXT-строки — 255 символов, но DNS-серверы поддерживают объединение нескольких строк (сцепление) для создания записей большего размера. При этом общий размер всех TXT-записей для одного домена не должен превышать 512 байт в ответе на UDP-запрос (во избежание фрагментации), а превышение этого лимита переключает запрос на TCP, что увеличивает время ответа в среднем на 20–30 мс. Индустриальный ориентир TTL для постоянных TXT-записей (SPF, DKIM) — 3600 секунд, для временных (верификация) — 300 секунд.

Как это работает?

При получении DNS-запроса типа TXT для конкретного домена авторитативный DNS-сервер возвращает одну или несколько текстовых строк, которые интерпретируются принимающей стороной (почтовым сервером, сервисом проверки, поисковиком) согласно определённому формату. Например, SPF-запись начинается с v=spf1, после чего перечисляются разрешённые IP-адреса или серверы. DKIM-запись содержит публичный ключ для проверки цифровой подписи письма. DMARC-запись задаёт политику обработки писем, не прошедших SPF/DKIM. Поскольку TXT-записи не влияют на маршрутизацию трафика (в отличие от A или MX), они не участвуют в разрешении адреса сайта, но критически важны для почтовой доставляемости и безопасности.

Метрики и стандарты

Лимит длины — одна строка не более 255 символов; при необходимости объединяются несколько строк, но общая длина не должна превышать 512 байт в UDP-ответе.
TTL — рекомендуемое значение для SPF/DKIM/DMARC: 3600 с; для временных верификаций (например, Google Search Console) — 300 с.
Время ответа — среднее время разрешения TXT-записи составляет 40–70 мс (при кэшировании) и до 150 мс при некэшированном запросе (влияет на общую задержку отправки писем).
КоличествоDNS-запросов приSPF-проверке — не более 10 механизмов (включая include и redirect), иначе почтовый сервер возвращает ошибку SPF permerror (стандарт RFC 7208).
Доля писем, отклоняемых из-за неверныхTXT-записей — индустриальный ориентир: 5–8% всей входящей почты, что критично для бизнес-коммуникаций.

Почему это важно для бизнеса?

Неправильно настроенные TXT-записи (особенно SPF, DKIM, DMARC) приводят к тому, что письма с вашего домена попадают в спам или отклоняются почтовыми серверами. Потеря доставляемости означает срыв переписки с клиентами, партнёрами и снижение конверсии в email-маркетинге. DMARC-запись с политикой p=reject защищает ваш бренд от фишинга и спуфинга, повышая доверие к домену. Кроме того, верификация домена через TXT-запись требуется для подключения к Google Search Console, Яндекс.Вебмастеру, сервисам аналитики и рекламным платформам — без неё вы не сможете получить доступ к данным о трафике и настроить таргетинг.

Пример применения

Сценарий: Компания «ЛогистикПро» использует email-рассылки через сторонний сервис SendGrid. Чтобы письма не попадали в спам, они настраивают SPF-запись: v=spf1 include:sendgrid.net ~all и DKIM-запись с публичным ключом, полученным от SendGrid. Также они создают DMARC-запись: v=DMARC1; p=quarantine; rua=mailto:dmarc@company.com. После распространения этих TXT-записей (TTL 3600 с) процент попаданий в спам снижается с 20% до 2%, а открываемость писем вырастает на 15% за месяц.

Как это реализуется в WordPress?

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

Настройка черезDNS-провайдера: в панели хостинга или регистратора создаётся запись типа TXT, указывается имя (часто @ для основного домена или default._domainkey для DKIM) и значение (текстовая строка). Для SPF и DMARC обычно используется корневой домен, для DKIM — поддомен вида key._domainkey.
Плагины WordPress для почты:
- WP Mail SMTP — помогает настроить отправку через внешние SMTP-серверы (SendGrid, Mailgun, Gmail) и часто генерирует необходимые TXT-записи (SPF, DKIM) с инструкциями по их добавлению в DNS.
- MailPoet, Newsletter — также имеют разделы с настройками доставляемости, где выводятся значения для TXT-записей.
Настройка сервера: На уровне сервера (Nginx, LiteSpeed) нет прямой привязки к TXT-записям, но если вы используете собственную почтовую систему (Postfix, Exim), нужно убедиться, что исходящие письма подписываются DKIM и соответствуют SPF, а для этого требуются соответствующие TXT-записи в DNS.
Верификация домена в поисковых системах:
- В Google Search Console при добавлении сайта предлагается создать TXT-запись с уникальным кодом; после добавления и распространения (можно проверить через dig или встроенный инструмент) сайт становится верифицированным.
- Аналогично для Яндекс.Вебмастера и Bing Webmaster Tools.
Мониторинг и проверка:
- Используйте онлайн-инструменты (например, MXToolbox, Google Admin Toolbox) для проверки SPF, DKIM, DMARC.
- В WordPress плагин Post SMTP включает функцию проверки доставляемости и диагностики ошибок TXT-записей.

Связанные понятия

SPF (Sender Policy Framework) — запись TXT, указывающая, какие серверы разрешено отправлять письма от вашего домена.
DKIM (DomainKeys Identified Mail) — запись TXT, содержащая публичный ключ для проверки цифровой подписи писем.
DMARC (Domain—based Message Authentication,Reporting &Conformance) — запись TXT, задающая политику обработки писем, не прошедших SPF/DKIM, и адрес для отчётов.
Верификация домена — процесс подтверждения прав на домен через уникальный код в TXT-записи (используется Search Console, рекламные платформы).
TTL (Time To Live) — время жизни записи в кэше, влияет на скорость распространения изменений.
MX-запись — определяет почтовые серверы домена; TXT-записи для SPF/DKIM связаны с MX, но не заменяют их.

Ошибки:

Превышение лимита в 10 механизмов в SPF (например, много include) — почтовые серверы будут возвращать ошибку Too many DNS lookups. Используйте include с минимальным количеством.
Установка слишком высокого TTL для верификационных записей (например, 86400) — после успешной верификации запись можно удалить, но она будет кэшироваться сутки, что не критично, но замедляет окончательную очистку.
Использование разных TXT-записей для SPF и DKIM на одном поддомене (кроме корневого) — это допустимо, но следите за тем, чтобы имена не конфликтовали (для DKIM используются поддомены вида selector._domainkey).
Игнорирование DMARC-отчётов — без анализа отчётов вы не узнаете о проблемах доставляемости и попытках спуфинга; настроив DMARC с rua, вы получите регулярные отчёты о прохождении аутентификации.