Сканування 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) або пряме внесення до чорних списків для кожного агента, який його використовує.

Приховані витрати

  • Втрата репутації миттєво поширюється на всіх агентів, що використовують той самий домен.
  • Зниження доставляємості призводить до зростання кількості звернень у службу підтримки та підриває довіру користувачів.
  • Ризик невідповідності стандартам зростає, коли організації не можуть довести, що вони відстежують спроби спуфінгу — відсутність робочої адреси RUA означає відсутність форензичних даних.

Як це виправити

  1. Перевірте адресу звітування – виконайте DNS-запит, щоб підтвердити, що адреса RUA розпізнається та може отримувати агреговані звіти. Без видимості ви не зможете реагувати на зловживання.
  2. Використовуйте сирі звіти – завантажуйте звіти у форматах XML або JSON безпосередньо протягом принаймні двох тижнів. Панелі керування вендорів часто маскують помилки або агрегують дані так, що це приховує критичні тенденції.
  3. Очистьте SPF-включення (includes) – видаліть будь-які механізми «include», які ви не можете чітко ідентифікувати. Занадто широкий запис SPF приваблює спуферів і збільшує кількість DNS-запитів, що створює ризик повної відмови SPF.
  4. Ізолюйте агентів на піддомені – розгорніть окремий піддомен для пошти, створеної ШІ, згенеруйте для нього власний DKIM-ключ і застосуйте сувору політику DMARC (p=reject). Така ізоляція обмежить будь-яку помилку одним простором імен, а не кореневим корпоративним доменом.

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

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

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

Висновок

ШІ-агенти, які надсилають електронні листи, успадковують найслабшу ланку в ланцюжку автентифікації свого домену. Інертний запис DMARC або неробоча адреса звітування можуть паралізувати доставляємості та репутацію всього флоту. Перевірте, очистьте та ізолюйте свою поштову інфраструктуру вже зараз — інакше ви будуєте на піску, який обвалиться в ту саму мить, коли відбудеться спроба спуфінгу.