Вы включили DMARC. Вы добавили тег rua= в запись, потому что так сказал какой-то гайд. И теперь каждый день ваш почтовый ящик получает небольшую кучу писем от Google, Microsoft, Yahoo и постоянно меняющегося набора почтовых провайдеров, о которых вы никогда не слышали, каждое с заархивированным XML-вложением с именем вроде google.com!yourdomain.com!1736899200!1736985600!17482910384.xml.gz.
Никто их не открывает. Это честная правда о внедрении DMARC — огромное количество доменов годами сидят на p=none, исправно получая отчёты, которые никто никогда не читал, а значит получают ровно ноль пользы и весь шум целиком.
На самом деле отчёты не так сложно читать. Просто на них неприятно смотреть. Вот что внутри, что на самом деле имеет значение, и как получить реальный ответ из одного отчёта примерно за десять минут.
Что такое отчёт DMARC, и чем он не является
Агрегированный отчёт DMARC — это принимающий почтовый провайдер, сообщающий вам: «вот каждое сообщение, которое я видел сегодня и которое утверждало, что оно от вашего домена, сгруппированное по IP, который его отправил, и вот, прошло ли каждое из них аутентификацию».
Вот и всё. Это ежедневная перепись того, кто отправляет почту от вашего имени, с точки зрения одного получателя.
Некоторые вещи, которыми он намеренно не является:
- Он не по-сообщенчный. Сообщения группируются и подсчитываются. Вы получаете «42 сообщения с этого IP, все прошли» — а не 42 отдельные записи.
- Он не содержит содержимого сообщений. Никаких тем, никаких тел, никаких получателей. Это сделано намеренно, ради приватности. (Есть отдельный механизм, форензик-отчёты через тег
ruf=, которые действительно включают детали сообщений — но почти никто больше их не отправляет, опять же по причинам приватности. Если вы установилиruf=и ничего не получаете — вот почему. Не ждите этого.) - Это не отчёт о доставляемости. Он не скажет вам, попала ли почта во входящие или в спам. Он сообщает только об аутентификации.
- Это взгляд одного получателя. Отчёт Google охватывает почту, отправленную на адреса Gmail. Отчёт Microsoft охватывает Outlook. Вам нужно читать несколько, чтобы увидеть полную картину, и объём сильно варьируется между ними.
Отчёты приходят ежедневно по умолчанию — интервал контролируется тегом ri= в вашей записи DMARC, и 86400 секунд (один день) одновременно и значение по умолчанию, и, реалистично, единственное значение, которое кто-либо соблюдает.
Анатомия XML
Разархивируйте один и найдёте три содержательных раздела. Остальное можно пропустить.
<report_metadata> — кто отправил отчёт и какой временной период он покрывает. Полезно только для ориентации. Обратите внимание на org_name, чтобы знать, чью перспективу вы читаете.
<policy_published> — это ваша собственная запись DMARC, как её понял получатель. Стоит взглянуть, потому что это подтверждает, что на самом деле действует:
<policy_published>
<domain>yourdomain.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>p — это ваша политика (none, quarantine или reject). sp — политика для поддоменов. pct — какой процент проваливающейся почты действительно попадает под политику — полезно для поэтапного развёртывания, и частый источник вопросов «почему в карантин попала только часть».
adkim и aspf — режимы выравнивания, и они важнее, чем кажется. r означает relaxed (мягкий): поддомен считается выровненным с организационным доменом, поэтому bounce.yourdomain.com выравнивается с yourdomain.com. s означает strict (строгий): должно совпадать точно, и тот же поддомен теперь провалится. Если кто-то установил строгое выравнивание, не понимая этого, это часто и есть вся причина, по которой почта начала отваливаться.
<record> — фактические данные, один блок на источник отправки. Вот ради чего вы здесь.
Самая важная вещь во всём отчёте
Каждый <record> содержит два разных вердикта об одном и том же сообщении, и их путаница — причина номер один неправильного прочтения этих отчётов.
<record>
<row>
<source_ip>203.0.113.5</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>yourdomain.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>mailservice.example</domain>
<selector>s1</selector>
<r>pass</r>
</dkim>
<spf>
<domain>bounce.mailservice.example</domain>
<r>pass</r>
</spf>
</auth_results>
</record>Прочитайте внимательно. auth_results говорит, что SPF прошёл и DKIM прошёл. policy_evaluated говорит, что оба провалились.
Оба верны. Они отвечают на разные вопросы.
auth_results — это сырой результат — прошла ли проверка SPF, проверилась ли подпись DKIM. В данном случае да, оба прошли, потому что отправляющий сервис правильно настроен на своём собственном домене.
policy_evaluated — это результат после выравнивания — совпал ли домен, прошедший проверку, с доменом в видимом заголовке From. Здесь не совпал: DKIM подписал как mailservice.example, SPF авторизовал bounce.mailservice.example, но сообщение утверждало, что оно от yourdomain.com. Всё прошло аутентификацию идеально — для не того домена.
Это классическая проблема стороннего отправителя. Ваша маркетинговая платформа, служба поддержки или инструмент выставления счетов отправляет почту «от вашего имени», подписывает её своим собственным доменом, и DMARC правильно говорит: ничто здесь не доказывает, что yourdomain.com авторизовал это.
policy_evaluated — это то, что решает судьбу вашей почты. Когда вы просматриваете отчёты, это поле для чтения. auth_results — это контекст для почему.
Исправление для этого конкретного паттерна почти всегда — кастомная подпись DKIM — настройка стороннего сервиса на подпись ключом, опубликованным под вашим доменом, с использованием селектора, который вы добавили в собственный DNS, вместо его общего по умолчанию. Большинство серьёзных провайдеров это поддерживают; обычно это спрятано в настройках как «аутентификация DKIM» или «подпись собственного домена». После того как вы это сделали, проверка опубликованных записей для вашего домена подтвердит, что селектор действительно активен в DNS — это шаг, который чаще всего пропускают: сервис говорит «настроено», DNS говорит иначе, и отчёты продолжают проваливаться.
Десятиминутный рабочий процесс, который реально работает
Забудьте о чтении XML от начала до конца. Сделайте вот что:
1. Сгруппируйте каждую запись по source_ip. По всем отчётам от всех получателей. Обычно получается где-то от пяти до тридцати уникальных IP.
2. Для каждого IP задайте один вопрос: узнаю ли я это? Ваш почтовый сервер, Google Workspace, ваша CRM, ваша биллинговая система. Проверьте всё незнакомое — WHOIS или ASN-поиск по IP обычно сразу называет сервис, и большинство «загадочных» IP оказываются SaaS-продуктом, на который кто-то в компании подписался.
3. Сопоставьте с policy_evaluated. Четыре возможные комбинации, и каждая означает что-то совершенно другое:
- Узнанный IP, выровненный успех — этот источник настроен правильно. Ничего делать не нужно.
- Узнанный IP, провал — легитимный сервис, который не выровнен. Это ваш список задач. Каждое такое письмо будет отклоняться в момент перехода на
p=reject. - Неизвестный IP, провал — почти всегда спуфинг. Это DMARC делает свою работу. Никаких действий не требуется — это причина, по которой вы его включили.
- Неизвестный IP, выровненный успех — интересный случай. Что-то, что вы не узнаёте, успешно проходит аутентификацию как ваш домен. Значит, оно легитимно авторизовано где-то в вашем DNS, и вы об этом забыли. Обычно это теневой ИТ: отдел подписался на инструмент, кто-то добавил SPF include два года назад, и он всё ещё там. Стоит расследовать, потому что это же выглядит и как скомпрометированный, но авторизованный отправитель.
4. Исправляйте только вторую категорию. Узнанный, но проваливающийся. Это список, который стоит между вами и принудительным применением.
Два провала, в которых вы не виноваты
Два паттерна будут появляться в ваших отчётах и выглядеть как проблемы, но не являются исправимыми в обычном смысле, и знание о них экономит много потраченных впустую усилий.
Пересылка ломает SPF. Когда кто-то автоматически пересылает ваше сообщение с одного адреса на другой, пересылающий сервер становится отправителем. Ваша SPF-запись его не перечисляет, поэтому SPF проваливается в конечном пункте назначения. Ничего не настроено неправильно — так просто взаимодействуют пересылка и SPF. DKIM обычно переживает пересылку невредимым, и именно поэтому так важно, чтобы DKIM работал: это то, что удерживает пересланную почту аутентифицированной, когда SPF неизбежно проваливается.
Списки рассылки ломают DKIM. Списки часто модифицируют сообщения — добавляют подвал, переписывают тему с тегом [Название списка]. Любая модификация тела или подписанного заголовка делает подпись DKIM недействительной. В сочетании с проблемой пересылки выше, трафик списков рассылки часто проваливает обе проверки.
Есть механизм, разработанный для этого (ARC — Authenticated Received Chain), где посредники ручаются за результаты аутентификации, которые они наблюдали до модификации сообщения. Поддержка реальна, но неравномерна. На практике: ожидайте базовый уровень отказов, связанных с пересылкой, в ваших отчётах, распознавайте их по паттерну и не гоняйтесь за ними как за багами конфигурации.
Когда прекратить читать их вручную
Ручное чтение прекрасно подходит для первоначальной уборки — найти ваши источники отправки, исправить выравнивание, дойти до чистой базовой линии. Это конечная работа, обычно на пару недель.
После этого ценность смещается в сторону мониторинга: обнаружение новоиспортившегося источника или разворачивающейся кампании спуфинга. Это непрерывная задача с низким сигналом, с которой люди справляются плохо, а инструменты — хорошо. Любое количество агрегаторов отчётов DMARC разберёт XML, сгруппирует по источнику и оповестит вас об изменениях.
Но сначала сделайте ручной проход. Чтение горстки сырых отчётов вручную — самый быстрый способ реально понять поток вашей почты — и вы найдёте источники отправки, о которых забыли, что они существуют, что само по себе стоит десяти минут.
Если вы настраиваете или корректируете саму политику, генератор записи DMARC справится с синтаксисом тегов и позволит вам сосредоточиться на решении, которое действительно имеет значение: показывают ли ваши отчёты, что каждый легитимный источник выравнивается чисто, прежде чем вы уйдёте дальше p=none.