Две SPF TXT-записи у одного домена вызывают PermError

#Что произошло и как распознать неисправность

Для одного имени домена в DNS опубликованы две отдельные TXT-записи, начинающиеся с v=spf1. Почтовые получатели не могут выбрать одну политику SPF и возвращают SPF PermError; письмо может попасть в спам или быть отклонено политиками сервера. Это не та же ситуация, что одна длинная TXT-запись, разбитая DNS-провайдером на несколько строк внутри одного значения. SPF оценивает запись домена, используемого для SMTP MAIL FROM (либо HELO при соответствующем сценарии), а не автоматически видимый From. Перед слиянием нужно установить все разрешённые источники почты: сайт, CRM, почтовый сервер и внешние службы.

#Причины и отличительные признаки

#Пошаговая диагностика и исправление

1. Сначала прочитайте все TXT у авторитетного DNSНа компьютере с dig выполните dig TXT example.com +short, замените example.com доменом отправителя. Найдите отдельные TXT, начинающиеся с v=spf1. Одна логическая TXT-запись может содержать несколько строк в одном DNS-ответе; это не ошибка. Если именно две разные TXT-записи начинаются с v=spf1 у одного имени, исправление необходимо.
2. Уточните домен из реального почтового обменаОткройте исходные заголовки тестового доставленного письма и найдите Return-Path, smtp.mailfrom в Authentication-Results. Для этого домена ищите SPF; запись на основном example.com не всегда управляет почтой поддомена mail.example.com. Запишите SPF-результаты, не публикуя полный заголовок с личными данными.
3. Составьте список всех легитимных отправителейВ административных кабинетах сайта, хостинга, службы рассылок и CRM найдите их официальные требования к SPF. Запишите ip4, ip6, include для фактически отправляющих сервисов. Не копируйте целиком чужую строку v=spf1 внутрь другой: в одной политике версия указывается только один раз. Если сервис больше не используется, проверьте это по журналам перед удалением.
4. Проверьте число обращений DNSДля SPF существуют ограничения на число DNS-запрашивающих механизмов, обычно максимум 10 для include, a, mx, exists, redirect и других соответствующих конструкций. Составьте итоговую запись на бумаге и оцените вложенные include. Если их слишком много, согласуйте сокращение количества источников или выделение отправителей на поддомены; не увеличивайте лимит на принимающем сервере.
5. Сохраните обе исходные TXT перед исправлениемВ панели авторитетного DNS-провайдера откройте зону и найдите TXT у нужного имени (для вершины домена часто используется @, но формат интерфейса зависит от провайдера). Экспортируйте зону или скопируйте обе строки, TTL и имя. Не удаляйте другие TXT: они могут содержать проверку владения, DKIM, DMARC и служебные ключи.
6. Замените две SPF на одну проверенную записьУдалите только два конфликтующих TXT со значением v=spf1 и добавьте одну составленную политику для того же DNS-имени. Например, демонстрационная запись v=spf1 ip4:192.0.2.10 -all годится только если именно этот IP единственный отправитель; не копируйте адрес из документа на свой домен. Сначала выберите корректные реальные механизмы и завершающее правило на основе своей политики.
7. Проверьте TXT у всех авторитетных серверовПосле сохранения выясните делегированные NS и выполните dig @ns1.example.com example.com TXT +short для каждого. В ответе должна оставаться одна SPF-политика. Если на разных NS есть разные версии, ищите проблему синхронизации или изменения не у того DNS-провайдера. Обновление кеша у внешних получателей может занять время согласно прежнему TTL.
8. Отправьте контрольное письмо и сохраните возможность откатаОтправьте одно тестовое письмо через каждый используемый почтовый сервис и посмотрите spf=pass для нужного smtp.mailfrom; отдельно оцените DMARC-согласование. Если у законного отправителя SPF fail, восстановите недостающий механизм в единственной политике после проверки документации сервиса. Не возвращайте вторую SPF-запись: это вновь создаст PermError.
9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Без sudo в терминале с dig.

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Без sudo в терминале с dig. Замените домен, изучите число отдельных SPF TXT.

   dig TXT example.com +short

   Вариант 2Без sudo, запрос к конкретному авторитетному NS.

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Без sudo, запрос к конкретному авторитетному NS. Замените оба имени на реальные.

   dig @ns1.example.com example.com TXT +short

#Как проверить результат и что делать при неуспехе

Успех — на одном имени ровно одна SPF-политика, разрешённые отправители дают spf=pass, а получатели больше не возвращают PermError из-за выбора нескольких записей. При сохранении ошибки проверьте вложенные include и лимиты DNS-запросов.