TXT-запись: текст в DNS и правила его использования

В RFC 1035, разделе 3.3.14 данные TXT состоят из одной или нескольких текстовых строк. Требования к содержимому нужно брать у той системы, для которой создается запись. Произвольная строка не превращается в рабочую настройку почты.

Имя записи и значение нельзя менять местами

Запросите полное имя, точное содержимое и назначение. Поле имени определяет, где сервис будет искать текст; поле значения содержит сам текст. Проверьте, дополняет ли панель короткое имя текущим доменом и как показывает кавычки после сохранения.

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

Несколько TXT и несколько строк SPF

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

Ограничение SPF не означает «удалить все остальные TXT». Запись для иной задачи может быть нужна другому сервису. Сначала классифицируйте найденное и согласуйте правку политики с ответственным за почту. Здесь нет готовой SPF-строки, которую можно безопасно вставить любому домену.

Как проверить результат без разрушительной очистки

Сравните точное имя и полученное значение с ожидаемыми данными сервиса. Отдельно выясните, завершена ли проверка на его стороне: наличие TXT в ответе еще не подтверждает принятие аккаунта. Если изменение видно не везде, разберите DNS TTL и точку запроса, а не создавайте дубликаты наугад.

Для входящей почты нужен свой MX-маршрут; TXT его не заменяет. Источники прочитаны 7 октября 2026 года, зоны и политики не менялись, токены не создавались и письма не отправлялись. Общее устройство объясняется в DNS, связанные понятия собраны в словаре.