Как исправить SPF PermError: объединение двух TXT-политик корпоративной почты

Почему две SPF-политики TXT вызывают ошибку?

Если после подключения нового сервиса часть писем не доставляется, проверьте, нет ли двух значений v=spf1 у одного имени DNS. RFC 7208 требует возвращать permerror при выборе нескольких SPF-политик. Это не запрет на TXT-записи другого назначения. Не каждый получатель обязательно отклонит каждое письмо, поэтому проверьте фактическую доставку.

Найдите проверяемый домен и его DNS-провайдера

В уведомлении о недоставке или заголовке аутентификации найдите домен MAIL FROM, для которого проверялся SPF: он может отличаться от видимого From. У действующего DNS-провайдера запросите TXT точного имени. Разделите корневой домен и поддомен, подсчитайте записи v=spf1 и сохраните прежние значения и результаты тестов до правки.

Проверьте отправителей до удаления записей

Помимо почтового ящика домен могут использовать сервис счетов, уведомления о заказах и рассылка. Удаление одной политики без проверки может нарушить работающий сервис. Для каждого канала запишите ответственного, дату последнего использования, домен отправки и актуальные указания поставщика по SPF, затем сверьте с журналом отправок.

Объедините разрешенных отправителей в одной политике

Не склеивайте две готовые строки SPF. Оставьте один v=spf1 в начале, проверьте нужные include или ip4 и один завершающий механизм ~all либо -all в конце. Строка v=spf1 include:_spf.google.com include:sender.example ~all лишь показывает форму: sender.example не является значением реального поставщика. Используйте его точные инструкции и не смешивайте политику выделенного поддомена с корневой.

Проверьте лимит DNS-запросов

Даже одна запись может дать PermError, если include, a, mx и другие элементы вызывают слишком много запросов. RFC 7208 ограничивает их десятью при проверке. Сначала уберите неиспользуемые сервисы, а оставшиеся обоснуйте документацией поставщиков и реальной активностью. Слепая фиксация IP или уплощение может пропустить будущую смену серверов.

Отдельно проверьте публичный DNS и отправку

Успешное сохранение в панели DNS еще не означает завершения. Проверьте у авторитетного DNS, что для точного имени осталась одна SPF-политика. После обновления отправьте тесты из каждого канала, включая обычный ящик и транзакционные уведомления, на внешний адрес и изучите SPF. Успешный SPF не гарантирует согласование From, DKIM или DMARC. Руководство по ошибке Gmail 550 и диагностика домена помогут далее, но реальные значения сверяйте с актуальными документами поставщика.

Главное — учет отправителей, а не просто одна строка

Завершайте исправление после проверки одной политики у точного имени, включения всех действующих отправителей и успешных тестов из каждого канала. При смене сервиса обновляйте существующую политику и список ответственных, а не добавляйте еще одну строку SPF. Полезные источники: руководство по Gmail 550, диагностика почтового домена и правила выбора записей RFC 7208.