TXT-запись: SPF, DKIM и подтверждение владения

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

Значение TXT состоит из строк в кавычках, каждая до 255 символов; более длинный текст делится на несколько частей, которые читающая сторона склеивает.

SPF (Sender Policy Framework) записывается в TXT и начинается с версии v=spf1. Далее идут механизмы, перечисляющие разрешённые источники: ip4 и ip6 для адресов, mx для серверов из MX-записей, include для подключения политики другого сервиса. В конце стоит правило по умолчанию, например -all (отклонять остальные) или ~all (мягкое несоответствие). Принимающий сервер сравнивает адрес отправителя со списком.

У домена должна быть только одна SPF-запись; две записи приводят к ошибке проверки. Ещё существует лимит на число обращений к DNS при вычислении политики: слишком много include ломают SPF.

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

DKIM добавляет к письму цифровую подпись, а открытый ключ для её проверки публикуется в TXT по имени вида селектор._domainkey.домен. Получатель берёт ключ и проверяет подпись; идею открытых ключей вы найдёте на странице otkrytyy-i-zakrytyy-klyuch. DMARC хранится в TXT по имени _dmarc и сообщает получателям, как поступать с письмами, не прошедшими проверки, и куда отправлять отчёты.

Связка из трёх записей не обеспечивает доставку, но существенно затрудняет подделку отправителя и повышает доверие к домену у почтовых систем.

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

Со временем в зоне копится много таких строк. Полезно периодически чистить те, что относятся к давно неиспользуемым сервисам: они раскрывают, чем пользовалась организация.

Команда dig example.com TXT выведет все текстовые записи корня, а dig _dmarc.example.com TXT и запрос по имени селектора покажут остальные. Типичные ошибки: лишние пробелы или разрыв строки при копировании, кавычки, превращённые редактором в типографские, две SPF-записи, забытый пробел перед механизмом. Некоторые панели сами добавляют кавычки и разбивают длинные значения, поэтому лишние кавычки вручную ставить не нужно.

Одна строка TXT ограничена 255 символами, а весь ответ по классическому UDP исторически рассчитан на небольшой размер. Длинные ключи DKIM поэтому записывают несколькими строками, а разбиение делает сама панель DNS. Если ответ не помещается в пакет, резолвер повторяет запрос по TCP или использует расширение EDNS, позволяющее передавать более крупные ответы.

Чтобы не запутаться, ведите список назначения каждой записи. Хорошо, если в самой записи виден смысл: у сервисов подтверждения обычно узнаваемый префикс. Удаляйте устаревшие записи, особенно SPF-механизмы include для сервисов, которыми вы больше не пользуетесь: они расширяют круг тех, кто вправе отправлять письма от вашего имени. После любых правок проверяйте результат командой dig и почтовой проверкой заголовков письма: по заголовкам видно, прошли ли SPF, DKIM и DMARC на стороне получателя.

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