Анализатор отчётов DMARC

Перетащите сюда файлы агрегированных отчётов, которые присылают вам получатели, — .xml, .xml.gz или .zip с несколькими сразу — и получите обратно то, что прячет XML: какие источники отправляют от имени вашего домена, какая часть проходит выравнивание SPF и DKIM, что провалилось по обоим и что исправлять первым, простым языком. Всё распаковывается и разбирается в вашем браузере; файлы никогда не покидают ваш браузер, потому что отчёт DMARC — это карта того, кто отправляет вашу почту, — и кто притворяется.

Или перетащите файлы в любое место этого поля. Отчёты от разных получателей и за разные дни объединяются в одну таблицу, сгруппированную по источникам.

Пример вымышлен: один здоровый отправитель, один пересыльщик, одна несогласованная маркетинговая платформа, один неизвестный источник, проваливающий всё.

Что такое агрегированный отчёт на самом деле

У DMARC две половины. Первая — это запись, которую вы публикуете: политика, режимы выравнивания, адрес для отчётов, — и это та половина, которую может прочитать любой проверяющий инструмент, включая проверку доставляемости почты на этом сайте. Вторая половина — петля обратной связи: каждый крупный получатель, видящий почту, которая утверждает, что она от вашего домена, суммирует увиденное и отправляет сводку на ваш адрес rua, обычно раз в день, в виде XML. Этот файл — единственное свидетельство того, кто ещё отправляет от вашего имени. Кампании спуфинга, маркетинговая платформа, которую коллега подключил два года назад, сервис мониторинга, всё ещё использующий выведенный из эксплуатации сервер, — всё это появляется в агрегированных отчётах за недели до того, как появится где-либо ещё, если кто-нибудь их читает. Почти никто их не читает, потому что сырой XML с вложенными элементами policy_evaluated почти нечитаем, а файлы скапливаются в сжатом виде в почтовом ящике. Именно этот разрыв и закрывает анализатор: тот же файл, превращённый в таблицу источников и вердиктов, где каждая неудача переведена в нужное ей исправление. Сопутствующее руководство как читать ваши отчёты DMARC объясняет словарь формата — диспозицию, выравнивание, разницу между результатом аутентификации и выровненным результатом — на полностью разобранном примере.

Две привычки делают отчёты ценнее. Во-первых, читайте их до принуждения: политика p=none с отчётами — это система наблюдения, и те недели, что она работает, учат вас каждому легитимному отправителю, так что переход к карантину и отклонению не ломает ничего настоящего. Во-вторых, относитесь к каждому неизвестному источнику как к тикету, а не как к курьёзу: опознайте его, выровняйте его или посмотрите, как принуждение его убьёт, но никогда не оставляйте неопознанный поток в куче «наверное, всё в порядке», потому что именно в этой куче прячется спуфинг. Обратите внимание, чего агрегированные отчёты намеренно не содержат: ни тел сообщений, ни тем, ни адресов получателей. Это подсчёты и вердикты по источникам, и поэтому ими можно делиться с командой поддержки провайдера — как файлом, который вы сознательно передаёте, а не как загрузкой в какой-то инструмент. Эта страница сохраняет это свойство: анализ происходит там, где файл уже находится, на вашей машине.

Часто задаваемые вопросы

Что такое агрегированный отчёт DMARC?

Это ежедневный файл обратной связи, который получатели (Google, Microsoft, Yahoo и остальные) отправляют на адрес из тега rua вашей записи DMARC. Для каждого источника, отправившего почту, утверждающую, что она от вашего домена, отчёт перечисляет IP источника, число сообщений, применённую получателем диспозицию и то, выровнялись ли SPF и DKIM с вашим доменом From. Это единственное место, где спуфинг вашего домена становится видимым как данные, а не как жалоба растерянного клиента. Руководство как читать ваши отчёты DMARC проходит настоящий отчёт строка за строкой.

Как получать эти отчёты для моего собственного домена?

Опубликуйте запись DMARC с адресом для отчётов — v=DMARC1; p=none; rua=mailto:[email protected] — и получатели начнут присылать примерно через день. Если записи у вас ещё нет или вы хотите проверить имеющуюся, сначала запустите проверку доставляемости почты: она читает запись, политику и то, опубликован ли адрес для отчётов. Отчёты приходят небольшими XML-файлами, обычно сжатыми gzip или собранными в zip, — именно их этот анализатор и открывает.

Безопасно ли открывать отчёт здесь? Куда уходит файл?

Никуда. Файл распаковывается и разбирается в вашем браузере, на этой странице; ничего не загружается, не передаётся и не сохраняется. Это намеренный дизайн, потому что агрегированные отчёты — это карта вашей почтовой инфраструктуры: каждый сервис отправки, которым вы пользуетесь, каждый IP и любой спуфинг, направленный на вас. Загрузить эту карту на сервер незнакомца или вставить её в ИИ-чат, который ведёт журналы, — значит отдать карту людям, которым она никогда не предназначалась.

Источник, которого я не узнаю, проваливает и SPF, и DKIM. Это спуфинг?

Это либо спуфинг, либо отправитель, о котором вам никто не рассказал, — и один отчёт не может разделить эти два случая, поэтому анализатор формулирует это как вопрос для расследования, а не как вердикт. Разбирайте по порядку: принадлежит ли IP провайдеру, которому ваша организация платит (CRM, служба поддержки, старый маркетинговый инструмент, забытый сервис мониторинга)? Объём стабильный и малый (неправильно настроенная внутренняя система) или всплесками и большой (кампания)? Пока ваша политика p=none, эта почта всё равно доставляется; как только каждый легитимный источник выровняется и вы примените карантин или отклонение, неопознанный поток будет отвергнут, чем бы из двух он ни был.

Моя собственная легитимная почта не проходит. Что исправлять первым?

Выравнивание, почти всегда у провайдера. SPF не выравнивается, когда провайдер отправляет со своего собственного домена возвратов, — исправьте это собственным поддоменом обратного пути, чтобы домен конверта был вашим. DKIM не выравнивается, когда провайдер подписывает своим доменом или не подписывает вовсе, — исправьте это, включив в настройках провайдера подпись DKIM вашим доменом. Одного выровненного механизма достаточно, чтобы пройти DMARC, но DKIM — более прочный из двух, потому что переживает пересылку. Исправляйте отправителей в порядке объёма, смотрите, как следующие отчёты становятся чистыми, и только тогда повышайте политику.