Тільки починаєте з DMARC? Почніть з основ →
Що це взагалі за звіти
Щойно ви публікуєте DMARC-запис з адресою rua=, приймальні сервери — Google, Microsoft, Yahoo і ще тисячі інших — починають щодня надсилати вам XML-зведення про кожен лист, який вони побачили нібито від вашого домену. Один звіт — це один звітний період від одного отримувача, і він відповідає на три питання:
- Хто надсилає пошту від вашого імені? (IP-адреса та обсяг)
- Чи пройшли ці листи SPF і DKIM?
- Чи узгоджені ці результати з доменом у полі
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може показувати SPFpass, тоді якpolicy_evaluatedпоказує SPFfail. Це означає, що лист автентифікувався щодо якогось домену — просто не вашого. Класичне неузгодження, і саме на ньому будується підробка.
Чотири типові картини
Пройшло й узгоджено. Обидві перевірки пройшли й узгодилися. Легітимна авторизована пошта, робити нічого не треба.
Сире pass, узгоджене fail. SPF або DKIM проходить, але щодо чужого домену. Зазвичай це сторонній сервіс, який підписує листи власним доменом. Полагодьте узгодження, а не ігноруйте.
Провал через пересилання. SPF не проходить, а DKIM проходить. Типова ситуація для розсилок і серверів пересилання, які переписали шлях листа. DKIM переживає пересилання — тому саме на узгодження за DKIM і варто спиратися.
Провал з невідомого джерела. Обидві перевірки провалено, IP-адреса незнайома, обсяг помітний. Ось це треба розслідувати: доки не доведено протилежне, вважайте це підробкою.
Як побачити підробку
Звіти роблять спроби видати себе за вас видимими. Дивіться на:
- незнайомі IP-адреси, що шлють обсяг з провалом обох перевірок;
- географічні аномалії — сплески з мереж, де у вас немає жодної інфраструктури;
- стрибки невдалої пошти навколо фішингових кампаній проти вашого бренду чи ваших клієнтів.
Поки ви на p=none, ці листи вже потрапили до скриньок — і звіт стає доказом, який виправдовує перехід до примусового застосування політики. Коли ви дійдете до p=reject, ті самі записи показуватимуть, як отримувач відхиляє підробку. Це і є система в дії: ви бачите атаку і бачите, що її зупинено.
Від XML до розуміння
Читати сирий XML у масштабі не має сенсу: кілька отримувачів на день на кількох доменах — це тисячі рядків. Робота полягає в зведенні: згрупувати за джерелом, зіставити IP-адреси з організаціями, відділити узгоджені успіхи від усього іншого й підсвітити невідоме. Саме це й робить DDMARC — перетворює щоденний потік звітів на зрозумілу картину того, хто надсилає пошту від вашого імені і що саме не проходить.
Розібратися з окремим звітом, не піднімаючи всю інфраструктуру, можна в аналізаторі звітів — завантажте XML і подивіться на нього людською мовою.