TXT-запись DNS: что хранит и зачем нужна для email
TXT-запись (Text record) - тип DNS-записи для хранения произвольного текста. Изначально TXT проектировалась для информационных пометок к домену. Со временем она превратилась в универсальный контейнер: сегодня TXT-записи хранят SPF-политики, DKIM-ключи, DMARC-правила, коды верификации и десятки других видов данных, которым не нашлось собственного типа записи в DNS.
Формат и ограничения
TXT-запись содержит одну или несколько текстовых строк в кавычках. DNS накладывает ограничение: длина одной строки не может превышать 255 символов. Если значение длиннее, оно разбивается на несколько строк, которые DNS-клиент склеивает при чтении:
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
Для длинных значений (типичный случай - DKIM-ключ RSA 2048 бит):
selector._domainkey.example.com. IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAA..."
"...OCAQ8AMIIBCgKCAQEA2nT+hOv..." )
Общий размер DNS-ответа через UDP ограничен 512 байтами без EDNS. С EDNS0 (расширение, которое поддерживают все современные резолверы) буфер вырастает до 4096 байт. Если ответ не помещается, происходит fallback на TCP. На практике это работает прозрачно, но слишком длинные TXT-записи увеличивают задержку разрешения.
SPF в TXT-записи
SPF (Sender Policy Framework) определяет, каким серверам разрешено отправлять почту от имени домена. SPF-запись всегда начинается с v=spf1:
v=spf1 ip4:198.51.100.0/24 include:sendgrid.net -all
Эта запись разрешает отправку с IP-диапазона 198.51.100.0/24 и серверов SendGrid, а остальных отклоняет (-all). Принимающий MTA извлекает SPF из TXT-записи домена отправителя и сравнивает IP, с которого пришло соединение, со списком разрешённых.
Раньше существовал отдельный DNS-тип «SPF» (тип 99), но он был упразднён в RFC 7208. Сегодня SPF хранится исключительно в TXT.
DKIM в TXT-записи
DKIM (DomainKeys Identified Mail) публикует открытый ключ в TXT-записи на поддомене selector._domainkey.domain.com. Отправляющий сервер подписывает заголовки письма закрытым ключом. Принимающий сервер извлекает selector из заголовка DKIM-Signature, запрашивает TXT-запись и проверяет подпись.
Длина DKIM-ключа напрямую влияет на размер TXT-записи. Ключ RSA 1024 бит помещается в одну строку (около 180 символов Base64). Ключ 2048 бит требует разбиения на две строки. При использовании Ed25519 (RFC 8463) ключ значительно короче, но поддержка Ed25519 среди принимающих серверов пока неполная.
DMARC в TXT-записи
DMARC-политика публикуется в TXT-записи на поддомене _dmarc.domain.com:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
Параметр p указывает, что делать с письмами, не прошедшими проверку SPF и DKIM: пропустить (none), поместить в спам (quarantine) или отклонить (reject). Параметр rua задаёт адрес для агрегированных отчётов о результатах проверок.
Верификация домена и другие применения
- Верификация владения. Google Workspace, Microsoft 365, почтовые сервисы, CDN-провайдеры просят добавить TXT-запись с уникальным кодом (google-site-verification=..., MS=ms12345678) для подтверждения, что вы контролируете домен.
- BIMI. Brand Indicators for Message Identification хранит ссылку на SVG-логотип бренда в TXT-записи на поддомене _bimi. Логотип отображается рядом с письмом в поддерживающих MUA (Gmail, Apple Mail).
- MTA-STS. Механизм принудительного TLS для входящей почты использует TXT-запись на _mta-sts для указания версии политики. Сама политика хранится на веб-сервере, но TXT-запись сигнализирует о её наличии и актуальности.
- TLSA/DANE. Привязка TLS-сертификатов к DNS для SMTP-соединений. Технически использует собственный тип записи (TLSA), но логика хранения данных аутентификации в DNS та же.
Типичные ошибки при работе с TXT
- Два SPF на одном домене. RFC 7208 разрешает только одну SPF-запись. Если вы подключаете новый сервис и создаёте вторую TXT-запись с v=spf1, обе становятся невалидными (PermError). Нужно объединить всё в одну запись через include.
- Превышение лимита DNS lookups. SPF допускает максимум 10 DNS-запросов (include, a, mx, redirect). Каждый include добавляет минимум один lookup, а вложенные include - ещё больше. При превышении лимита проверка возвращает PermError.
- Битый DKIM-ключ. При копировании длинного ключа из панели управления легко потерять символы или добавить лишний пробел. Результат - DKIM-подпись не проходит проверку, и DMARC может отклонить письмо.
- Забытые записи. После отключения сервиса (например, старого ESP) его include в SPF остаётся. Это не создаёт немедленных проблем, но увеличивает количество DNS lookups и потенциально авторизует серверы, которые вы больше не контролируете.
TXT-записи и валидация email
При валидации отдельного email-адреса TXT-записи не проверяются напрямую - они относятся к аутентификации отправителя, а не к существованию ящика. Но при аудите домена перед рассылкой анализ TXT обязателен: наличие SPF, корректность DKIM-ключа, настройка DMARC определяют, будут ли ваши письма проходить аутентификацию у получателя или окажутся в спаме.
uChecker анализирует DNS-записи доменов из вашей базы: MX, A, TXT. Если у домена нет почтовой инфраструктуры, это видно до отправки, а не после bounces.
