Сканирование 671 693 доменов показало, что более чем у половины отсутствуют принудительные настройки DMARC, что подвергает почтовых агентов на базе ИИ риску повреждения репутации и сбоев доставки. Один неправильно настроенный домен может испортить общую репутацию рассылки целого флота автономных агентов.

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

Набор данных демонстрирует три различных состояния DMARC:

  • Принудительное исполнение (p=quarantine или reject) — 49,31 % доменов
  • Мониторинг (p=none с отчетами) — 25,61 %
  • Инертное состояние (p=none без отчетов) — 25,04 %

Инертные записи (их более 117 000) являются лишь заглушками: это двадцатисимвольная строка, которая формально удовлетворяет требованиям комплаенса, но не обеспечивает реальной защиты. Хуже того, 166 442 домена публикуют политику DMARC, но указывают нерабочий адрес для отчетов (RUA), что фактически означает «полет вслепую».

За месяц до сканирования наблюдался рост общего количества записей DMARC, однако доля тех, что действительно применяют политику, снизилась. Примерно три четверти новых записей — это теги «p=none», которые не делают ничего, кроме ведения логов.

Почему это важно для ИИ-агентов

Агенты наследуют ту репутацию, которой обладает домен отправителя. Если добавить агента к домену со слабой записью SPF или инертной политикой DMARC, каждое исходящее сообщение от всего флота будет вносить вклад в общий «котел» репутации. Один плохо настроенный домен может вызвать возвраты писем (bounce-backs), ограничение скорости (throttling) или полное попадание в черные списки для каждого использующего его агента.

Скрытые издержки

  • Потеря репутации мгновенно распространяется на всех агентов, использующих один и тот же домен.
  • Снижение доставляемости приводит к росту числа обращений в службу поддержки и подрывает доверие пользователей.
  • Риск несоблюдения требований (compliance risk) возрастает, когда организации не могут доказать, что отслеживают попытки спуфинга — отсутствие рабочего RUA-адреса означает отсутствие форензик-данных.

Как это исправить

  1. Проверьте адрес для отчетов — выполните DNS-запрос, чтобы убедиться, что RUA-адрес разрешается и может принимать агрегированные отчеты. Без видимости вы не сможете реагировать на злоупотребления.
  2. Используйте необработанные отчеты — собирайте отчеты в форматах XML или JSON напрямую в течение как минимум двух недель. Панели управления вендоров часто скрывают ошибки или агрегируют данные так, что критические тенденции становятся незаметными.
  3. Оптимизируйте SPF include — удалите все механизмы «include», которые вы не можете четко идентифицировать. Слишком широкая запись SPF привлекает спуферов и увеличивает количество DNS-запросов, что создает риск полного отказа SPF.
  4. Изолируйте агентов на поддомене — разверните выделенный поддомен для почты, генерируемой ИИ, создайте для него собственный DKIM-ключ и примените строгую политику DMARC (p=reject). Такая изоляция ограничит последствия любой ошибки одним пространством имен, а не всем корпоративным доменом.

Быстрая команда dig для вашего домена перед следующим совещанием по развертыванию может выявить отсутствующие записи MX, SPF или DMARC, которые иначе могли бы проскочить мимо код-ревью.

Контраргумент

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

Итог

ИИ-агенты, отправляющие электронные письма, наследуют самое слабое звено в цепочке аутентификации своего домена. Инертная запись DMARC или нерабочий адрес для отчетов могут парализовать доставляемость и репутацию всего флота. Проверьте, очистите и изолируйте свою почтовую инфраструктуру прямо сейчас — иначе вы строите на песке, который обрушится в тот же миг, когда произойдет первая попытка спуфинга.