Перейти до вмісту
Блог DDMARC

Як читати зведені звіти DMARC

Зведені звіти показують, хто надсилає пошту від імені вашого домену. Розбираємо XML: що означає кожне поле і як відрізнити спробу підробки від зламаного пересилання.

PlatOps Security TeamДоставлюваність3 хвилини читання

Тільки починаєте з DMARC? Почніть з основ →

Що це взагалі за звіти

Щойно ви публікуєте DMARC-запис з адресою rua=, приймальні сервери — Google, Microsoft, Yahoo і ще тисячі інших — починають щодня надсилати вам XML-зведення про кожен лист, який вони побачили нібито від вашого домену. Один звіт — це один звітний період від одного отримувача, і він відповідає на три питання:

  1. Хто надсилає пошту від вашого імені? (IP-адреса та обсяг)
  2. Чи пройшли ці листи SPF і DKIM?
  3. Чи узгоджені ці результати з доменом у полі From:?

У сирому вигляді XML читати важко. Але щойно ви розберетеся зі структурою, він стає найкориснішим документом у всій автентифікації пошти: саме звідси ви дізнаєтеся і про сервіси, про які всі забули, і про зловмисників, про яких ніхто не знав.

Анатомія звіту

Кожен звіт починається з метаданих і політики, яку застосував отримувач:

<report_metadata>
  <org_name>google.com</org_name>
  <date_range><begin>...</begin><end>...</end></date_range>
</report_metadata>
<policy_published>
  <domain>yourdomain.com</domain>
  <p>reject</p>
  <sp>reject</sp>
  <pct>100</pct>
</policy_published>

Далі йде найцікавіше — по одному блоку <record> на кожне джерело:

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>yourdomain.com</domain><result>pass</result></dkim>
    <spf><domain>yourdomain.com</domain><result>pass</result></spf>
  </auth_results>
</record>

Читається це так: 42 листи з адреси 203.0.113.10 прийшли нібито від yourdomain.com і пройшли DKIM та SPF з узгодженням. Здорове, легітимне джерело.

Поля, які справді важать

  • source_ip — хто насправді надіслав пошту. Перевірте зворотний запис. Або ви впізнаєте це джерело (ваш ESP, ваш поштовий сервер), або ні.
  • count — скільки листів. Великий обсяг з незнайомої адреси — перший сигнал підробки.
  • policy_evaluatedузгоджений результат. Саме за ним DMARC ухвалює рішення.
  • auth_resultsсирий результат SPF і DKIM до перевірки узгодження. Розрив між ним і policy_evaluated майже завжди означає проблему з узгодженням.
  • disposition — що зробив отримувач: none, quarantine або reject.

Ключова різниця: auth_results може показувати SPF pass, тоді як policy_evaluated показує SPF fail. Це означає, що лист автентифікувався щодо якогось домену — просто не вашого. Класичне неузгодження, і саме на ньому будується підробка.

Чотири типові картини

Пройшло й узгоджено. Обидві перевірки пройшли й узгодилися. Легітимна авторизована пошта, робити нічого не треба.

Сире pass, узгоджене fail. SPF або DKIM проходить, але щодо чужого домену. Зазвичай це сторонній сервіс, який підписує листи власним доменом. Полагодьте узгодження, а не ігноруйте.

Провал через пересилання. SPF не проходить, а DKIM проходить. Типова ситуація для розсилок і серверів пересилання, які переписали шлях листа. DKIM переживає пересилання — тому саме на узгодження за DKIM і варто спиратися.

Провал з невідомого джерела. Обидві перевірки провалено, IP-адреса незнайома, обсяг помітний. Ось це треба розслідувати: доки не доведено протилежне, вважайте це підробкою.

Як побачити підробку

Звіти роблять спроби видати себе за вас видимими. Дивіться на:

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

Поки ви на p=none, ці листи вже потрапили до скриньок — і звіт стає доказом, який виправдовує перехід до примусового застосування політики. Коли ви дійдете до p=reject, ті самі записи показуватимуть, як отримувач відхиляє підробку. Це і є система в дії: ви бачите атаку і бачите, що її зупинено.

Від XML до розуміння

Читати сирий XML у масштабі не має сенсу: кілька отримувачів на день на кількох доменах — це тисячі рядків. Робота полягає в зведенні: згрупувати за джерелом, зіставити IP-адреси з організаціями, відділити узгоджені успіхи від усього іншого й підсвітити невідоме. Саме це й робить DDMARC — перетворює щоденний потік звітів на зрозумілу картину того, хто надсилає пошту від вашого імені і що саме не проходить.

Розібратися з окремим звітом, не піднімаючи всю інфраструктуру, можна в аналізаторі звітів — завантажте XML і подивіться на нього людською мовою.

ShareX / TwitterLinkedIn
Безкоштовний старт · 14 днів пробного періоду · скасуєте будь-коли

Від підробки — до блокування.

p=none
5 хвилин
p=quarantine
2-й тиждень
p=reject
4–6-й тиждень

Оплата — після завершення 14-денного пробного періоду · скасуйте раніше, і кошти не спишуться