Как читать отчёт DMARC и не утонуть в XML

Что такое отчёт DMARC на самом деле

Опубликуйте запись DMARC с адресом в rua=, и почтовые провайдеры начнут присылать вам сводные отчёты: по одному XML-файлу от провайдера в сутки, где перечислен каждый IP, отправлявший почту от имени вашего домена, сколько сообщений отправил каждый и прошли ли SPF и DKIM с выравниванием.

Две вещи стоит знать до того, как открыть первый:

• В сводных отчётах нет содержимого писем. Ни тем, ни получателей, ни текстов. Это счётчики, сгруппированные по отправляющему IP. Поэтому их безопасно собирать и поэтому они не могут сказать, какое именно письмо не прошло.
• Это не то же самое, что форензик-отчёты. Адрес в ruf= запрашивает образцы сбоев по каждому письму, где есть заголовки, а иногда и больше. Большинство провайдеров их уже не шлёт из соображений приватности, так что на практике видимость DMARC — это сводные отчёты.

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

Как начать их получать

Минимальная запись, которая только собирает данные и ничего не меняет в доставке:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Она ставится на _dmarc.example.com как TXT-запись. p=none значит «не применяй никакой политики, просто рассказывай» — это правильная точка старта, и навредить доставке она не может. Убедитесь, что запись действительно опубликована и читается, инструментом DNS-запросов, прежде чем ждать отчётов, которые не придут.

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

Чтение XML: три блока

У каждого сводного отчёта одинаковая форма. Увидев её один раз, перестаёшь пугаться.

Блок 1: кто прислал отчёт

<report_metadata> называет отчитывающуюся организацию и даёт идентификатор отчёта и диапазон дат. Обратить внимание стоит на диапазон: отчёты обычно покрывают сутки и приходят с задержкой в день-два, так что IP, который вы смотрите, отправлял в прошлом.

Блок 2: политика, которую они увидели

<policy_published> — это ваша собственная запись DMARC в том виде, в каком её прочитал этот провайдер: p (ваша политика), sp (для поддоменов), pct (процент, который вы просили применять) и режимы выравнивания. Блок полезен как проверка: если он не совпадает с тем, что вы думаете, что опубликовали, в записи синтаксическая ошибка или она ещё не разошлась.

Блок 3: строки, ради которых всё

Дальше идут элементы <record>. Каждый — это группа сообщений с одного IP с одним исходом, а не отдельное письмо. В каждом есть <row> с исходным IP и счётчиком, <policy_evaluated> с результатом DMARC и тем, что провайдер фактически сделал, и <auth_results> с лежащими в основе результатами SPF и DKIM.

Как читать строку на практике

Идите в таком порядке, и строка ответит сама:

1. Чей это IP? Посмотрите. Имя известной почтовой платформы значит, что это ваш сервис; незнакомая сеть — то, что нужно разбирать.
2. Сколько сообщений? Два — шум. Двадцать тысяч — система.
3. Что в <policy_evaluated><disposition>? none, quarantine или reject — что провайдер с этим сделал.
4. Прошли ли SPF и DKIM и были ли они выровнены? Эта пара — весь диагноз, и ей посвящён следующий раздел.

Четыре комбинации и что каждая значит

DMARC проходит, если хотя бы один из SPF и DKIM прошёл и выровнен с видимым доменом From:. Отсюда четыре случая:

• SPF прошёл + DKIM прошёл. Ваш правильно настроенный отправитель. Делать нечего.
• SPF прошёл, DKIM нет. Обычно сервис, который шлёт с авторизованного IP, не подписывая. Включите подпись DKIM: один SPF хрупок, потому что ломается при первой же пересылке.
• SPF не прошёл, DKIM прошёл. Чаще всего законная пересланная почта: IP пересылающего сервера нет в вашей SPF-записи, но подпись уцелела. DMARC проходит за счёт одного DKIM — ровно так и задумано.
• Оба не прошли. Либо ваш отправитель, которого никогда не настраивали, либо кто-то вас подделывает. Как их различить — следующий раздел.

Обратите внимание на ловушку в XML: результат может показывать pass в <auth_results> и всё равно валить DMARC, потому что аутентифицированный домен не был выровнен с доменом From:. Платформа, подписывающая своим доменом, даёт именно это. Если это путает, почему пройденный SPF — это не пройденный DMARC подробно разбирает выравнивание.

Отличить своих отправителей от подмены

Первые отчёты почти у всех выглядят тревожно, и почти ничего из этого не атака. Разложите падающие IP на три стопки:

• Ваши, настроенные неправильно. CRM, система счетов, тикет-система, маркетинговая платформа, сервер приложения. Признаки: IP разрешается в узнаваемого провайдера, объём стабилен день за днём, письма доставляются. Решение: авторизовать как следует, лучше через DKIM.
• Пересылающие серверы. Небольшой объём, разрозненные IP, университеты и мелкие почтовые хостинги, SPF падает, а DKIM проходит. Это не проблема и с вашей стороны не чинится.
• Настоящая подмена. Незнакомые сети, часто всплесками, нередко не связанные с вашим бизнесом, обе проверки падают. Успокаивающая часть: при включённой политике такая почта уже отклоняется, в этом и смысл.

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

Почему пересылка выглядит как атака

Это один раз сбивает с толку каждого. Рассылка или алиас ретранслируют ваше письмо со своего сервера, поэтому ваша SPF-запись проверяется против IP, который вы никогда не авторизовали, и не проходит — правильно. В отчёте видно незнакомый IP, который шлёт от вашего имени и валит SPF, — читается ровно как злоупотребление.

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

Как с помощью отчётов дойти до принудительной политики

Отчёты существуют, чтобы этот переход был безопасным. Рабочая последовательность:

• Оставайтесь на p=none, пока отчёты не станут скучными — обычно несколько недель. Вы ждёте, пока каждый найденный законный отправитель будет авторизован и ничего нового не появится.
• Чините отправителей по мере обнаружения, предпочитая DKIM. Отправитель с DKIM переживает пересылку, с одним SPF — нет.
• Переходите на p=quarantine, при желании с pct= для постепенности. Не прошедшая почта уходит в спам, а не исчезает, так что ошибка поправима.
• Затем p=reject, когда карантин долго был спокойным. С этого момента поддельная почта с вашим доменом действительно отклоняется.
• Продолжайте читать отчёты и после. Новый подрядчик, подключённый через полгода, появится как падающий IP, и вы хотите увидеть это раньше, чем вам скажут, что его счета возвращаются.

Не ставьте p=reject в первый день. Единственное, что делает принуждение безопасным, — инвентаризация из отчётов, а она становится полной за недели. Руководство по SPF, DKIM и DMARC разбирает сами записи.

Частые ошибки

• Прыгнуть на p=reject, не читая отчётов. Забытая система обычно та, что выставляет счета вашим клиентам.
• Читать каждую строку как одно письмо. Строка — это группа сообщений с одного IP с одним исходом.
• Считать каждый падающий IP атакующим. Большинство ранних сбоев — ваши собственные сервисы и обычная пересылка.
• Считать, что pass в auth_results означает прохождение DMARC. Без выравнивания с доменом From: не означает.
• Слать отчёты в человеческий ящик. Они приходят ежедневно от десятков провайдеров. Заведите отдельный адрес.
• Забыть о политике для поддоменов. Без sp= поддомены наследуют p, что во время внедрения может быть нежелательно.
• Чинить только SPF. SPF ломается на пересылке; через неё DMARC проносит именно DKIM.
• Выключить отчёты, дойдя до reject. Именно тогда они и становятся системой раннего предупреждения.

Коротко

Сводный отчёт DMARC — это ежедневный XML-список всех IP, отправляющих от имени вашего домена, со счётчиками и результатами SPF и DKIM, без содержимого писем. Читайте строку в четыре шага: определите IP, посмотрите объём, прочитайте disposition, затем проверьте, прошёл ли SPF или DKIM и был ли он выровнен. Рассчитывайте, что большинство ранних сбоев — ваши же ненастроенные сервисы и обычная пересылка, а не подмена; чините отправителей через DKIM, где можете; и переходите с p=none на карантин, а затем на reject только когда отчёты успокоятся. Проверьте, что запись _dmarc опубликована и читается, бесплатным инструментом DNS-поиска, а если результат SPF в отчёте выглядит противоречиво, руководство по разбору SPF объясняет почему.

Связанные инструменты и руководства:

• Поиск DNS — Запрашивайте записи A, AAAA, MX, TXT, NS и другие со значениями и TTL, а также обратный DNS.
• Почему SPF-запись не проходит проверку — и как это исправить — Как читать свою SPF-запись

Частые вопросы