Четене на DMARC отчети

Модул 4: Доставимост: SPF, DKIM и DMARC на практика · Време за четене: 12 минути

Учебна цел: След този урок ще можете да отворите и прочетете DMARC обобщен отчет (aggregate report), да определите за всеки ред от кой източник е той и защо успява или не, и да решите какво да поправите, какво можете да пренебрегнете и кога можете да затегнете политиката си.

Основни понятия: обобщен отчет (aggregate report, RFC 9990), rua, XML, gzip или zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selector, отчет за грешки (ruf, RFC 9991), услуга за отчети, поверителност (privacy)

Какво получавате

Ако сте поставили адрес за rua във Вашия DMARC запис (урок 4.4), големите получатели като Google, Microsoft и Yahoo Ви изпращат приблизително всеки ден обобщен отчет. Това е имейл с прикачен файл, обикновено компресиран XML файл с име като:

receiver.example!example.com!1793923200!1794009599.xml.gz

Това означава: от получател receiver.example, относно Вашия домейн example.com, за периода между двете времеви марки (секунди от 1970 г.; тук 6 ноември 2026 г., целият ден в UTC).

Отчетът не съдържа съдържанието на писмата, нито теми, а обикновено и не съдържа адресите на получателите. Той съдържа за всеки изпращащ сървър броя на съобщенията и резултата от SPF, DKIM и DMARC. Така той е надежден преглед на това кой изпраща поща от името на Вашия домейн, включително източници, които сами сте забравили, и измамници.

Структура на отчета

Отчетът има три части. По-долу са най-важните откъси от примерния файл към този урок (dmarc-rapport-1.xml).

1. Кой отчита, за какъв период

<report_metadata>
  <org_name>receiver.example</org_name>
  <email>noreply-dmarc@receiver.example</email>
  <report_id>receiver.example-20261106-7f3c2a91</report_id>
  <date_range>
    <begin>1793923200</begin>
    <end>1794009599</end>
  </date_range>
</report_metadata>

2. Коя политика е открил получателят при Вас

<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <sp>none</sp>
  <np>none</np>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

Винаги проверявайте това: ако тук не пише това, което мислите, че е във Вашия DNS, значи получателят е прочел различен (или остарял) запис.

3. За всеки източник: по един запис (record)

Всеки record се отнася за един изпращащ IP адрес с една комбинация от резултати:

<record>
  <row>
    <source_ip>198.51.100.40</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounce.mailer.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example</domain>
      <selector>k1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Най-важната разлика: auth_results спрямо policy_evaluated

Тук се крие същността на четенето. В примера по-горе в auth_results стои два пъти pass: DKIM е преминал успешно за mailer.example и SPF е преминал успешно за bounce.mailer.example. Въпреки това в policy_evaluated стои два пъти fail. Това не е противоречие: policy_evaluated отчита само успешна проверка, която е подравнена с header_from. Нито един от двата домейна не принадлежи на example.com, затова DMARC не успява.

Ето как да прочетете всеки ред:

1. Погледнете policy_evaluated. Има ли pass при dkim или spf? Тогава DMARC успява и този източник е наред.
2. Всичко не успява? Погледнете домейните в auth_results. Дали е услуга от Вашите, която все пак успява, но за собствения си домейн? Тогава трябва при тази услуга да включите DKIM с Вашия собствен домейн (урок 4.3).
3. Не успява и в auth_results, или DKIM напълно липсва? Проверете чий е IP адресът (обратен DNS, урок 5.1, или whois справка). Ако е една от Вашите системи: поправете. Ако е непознат и става въпрос за подозрителни количества: вероятно е фалшификация.

Модели, които виждате постоянно

Обърнете внимание и на IPv6: собствен сървър, който понякога изпраща през IPv6, докато Вашият SPF посочва само IPv4 адреса, дава softfail на тези редове. С DKIM подпис DMARC все пак успява, но това е знак, че Вашият SPF е непълен.

От отчет към решение

Готови сте да затегнете политиката си (от none към quarantine, после към reject), когато:

• всеки източник, който е Ваш, има в policy_evaluated поне един pass;
• това е така вече няколко седмици, при всички големи получатели;
• това, което все още не успява, е само пренасочена поща с валиден DKIM подпис (която все пак успява) или явна фалшификация.

Ако не успява голям собствен източник, както в примера услугата за бюлетини с 1250 съобщения, значи е твърде рано. При p=reject получателят би отхвърлил тези 1250 бюлетина.

Превръщане на отчетите в четими

Един отчет в текстов редактор е поносимо. Двайсет на ден не. Има три начина:

• Услуга за отчети (има много, включително с безплатен вариант). Поставяте техния адрес в rua и те изготвят графики и списъци от него. Внимавайте: по този начин давате на тази услуга информация кои сървъри изпращат поща от Ваше име, а адресът за отчети е на техния домейн (вижте разрешението чрез _report._dmarc в урок 4.4). Изберете услуга, на която се доверявате и която спазва GDPR.
• Собствен инструмент: съществуват програми с отворен код, които извличат отчети от пощенска кутия и ги подреждат в общ преглед.
• Четене сами с XML визуализатор или браузър, за по изключение.

Отчетите за грешки (ruf, RFC 9991) са различни: по едно за всяко неуспешно писмо, понякога с части от писмото в тях. Почти никой голям получател не ги изпраща, именно заради поверителността. Не са Ви нужни, за да въведете DMARC правилно.

На практика: ето как изглежда

При WebOké можете да въведете адреса за отчети в помощника за DMARC в DirectAdmin или Моят WebOké (вижте урок 4.4), като сами избирате пощенска кутия, в която да пристигат отчетите; отделен адрес като dmarc@ с own папка предотвратява затрупването на обичайната Ви поща. Четенето се извършва с избрана от Вас услуга за отчети или програма. Това работи еднакво при всеки доставчик: отчетът е в стандартен формат.

Обобщение

• Обобщеният отчет е ежедневен XML файл (често компресиран) за всеки получател, с брой съобщения и резултати за всеки изпращащ IP.
• auth_results дава суровия резултат на SPF и DKIM; policy_evaluated дава само това, което е успяло подравнено. Pass в auth_results може да е fail в DMARC.
• Пренасочената поща се разпознава по DKIM pass със SPF fail; фалшификацията по всичко fail от непознат IP.
• Затягайте политиката си едва когато всичките Ви собствени източници успяват вече няколко седмици.
• Отчетите за грешки (ruf) са рядкост и не са необходими.

Тест

Задача

Задача Z4.5: Четене на DMARC отчет. Отворете примерния файл dmarc-rapport-1.xml (обобщен отчет за example.com, с измислени данни). Отговорете на въпросите: коя политика е открил получателят, колко съобщения общо стоят в отчета, колко от тях не са преминали DMARC, кой ред е услугата за бюлетини и какво трябва да се направи там, кой ред е пренасочена поща, кой ред вероятно е фалшификация, какво трябва да се промени в SPF записа според ред 6, кой ред успява само благодарение на DKIM при услуга със собствен Return-Path, и може ли домейнът сега да премине към p=quarantine? Програмата проверява Вашите отговори спрямо фиксиран ключ и обяснява за всеки въпрос кой ред от отчета дава отговора.

Прочетете още

Стъпките в тези статии важат за панелите на WebOké; при други доставчици работи по подобен начин.

• Какво е DMARC? Обяснение на разбираем език
• Ръководство за DirectAdmin 5.9: DMARC инсталиране
• Безплатен курс по DNS 4.5: DMARC: какво трябва да правят получателите с фалшива поща
• RFC 9990 (DMARC Aggregate Reporting), с примерния отчет в приложение Б; RFC 9991 (Failure Reporting)