Что лежит в TXT записи
TXT это единственный тип записи без заранее заданного смысла, поэтому в нём со временем оказалось всё, чему не нашлось другого места. У домена, которым пользуются несколько лет, там обычно лежит почтовая политика, пара ключей и горка подтверждений владения для сервисов, о которых никто уже не помнит. Каждую из них можно узнать по началу строки.
- v=spf1
- Политика отправителей: какие серверы имеют право слать почту с этим доменом в конверте. У домена такая запись может быть только одна. Проверить SPF запись.
- v=DMARC1
- Что получателю делать с почтой, не прошедшей проверку SPF и DKIM, и куда слать отчёты. Её читают на имени _dmarc под доменом и никогда на самом домене. Проверить DMARC запись.
- v=DKIM1
- Открытый ключ, которым получатели проверяют подпись письма. Ключи лежат под именем селектора, поэтому единого места, куда смотреть, нет. Проверить DKIM селектор.
- v=BIMI1
- Где лежит логотип, который почтовый ящик может показать рядом с вашим письмом, и сертификат, который за него ручается.
- v=STSv1
- Идентификатор политики MTA-STS. Сама политика не в DNS, её отдают по https, и эта запись меняется только вместе с политикой.
- v=TLSRPTv1
- Куда слать ежедневные отчёты о неудачных TLS соединениях с вашими почтовыми серверами.
- Подтверждения владения
- Строки вроде google-site-verification= или MS= доказывают одному сервису, что домен под вашим контролем. Больше они не делают ничего и обычно остаются в зоне ещё долго после того, как сервисом перестали пользоваться.
Где какая запись должна лежать
Запись не на своём месте нигде не считается ошибкой. DNS спокойно её отдаёт, ни один сервер не жалуется, а протокол, которому она предназначалась, просто туда не заглядывает. Поэтому политика DMARC на самом домене может годами лежать без дела, пока все уверены, что DMARC включён.
- SPF: на самом домене и на каждом поддомене, который шлёт почту отдельно.
- DMARC: на _dmarc.example.com.
- DKIM: на селектор._domainkey.example.com, где селектор это значение s= в заголовке DKIM-Signature отправленного письма.
- BIMI: на default._bimi.example.com или под другим селектором, если почта подписана им.
- MTA-STS: на _mta-sts.example.com, а сама политика лежит на веб сервере.
- Отчёты TLS: на _smtp._tls.example.com.
Этот инструмент спрашивает и сам домен, и перечисленные известные имена, поэтому запись, опубликованная там, где нужно, находится, а запись не на своём месте так и называется. Исключение это DKIM: списка селекторов в DNS нет, поэтому ключи нельзя перечислить, их проверяют по одному селектору. Если нужны все типы записей зоны, а не только TXT, откройте проверку DNS записей.
Ограничение в 255 байт и почему записи выглядят разрезанными
Одна строка TXT не может быть длиннее 255 байт. Это ограничение самого формата записи, а не прихоть DNS провайдера. Значение длиннее, а таким обычно и оказывается ключ DKIM на 2048 бит или длинная политика, публикуется несколькими строками внутри одной записи, и любой клиент склеивает их обратно перед чтением. Результат это то же самое значение, и инструмент показывает уже склеенную форму вместе с полной длиной в байтах.
Проблема появляется только там, где DNS панель значение длиннее 255 символов не разбивает сама, а отказывается принимать. Тогда его вводят несколькими частями в кавычках, одна за другой, внутри одной записи. Чего делать нельзя никогда, так это разносить значение по двум отдельным TXT записям: они читаются как две независимые записи, и для SPF или DKIM это запись не удлиняет, а ломает.