Čítanie DMARC reportov

Modul 4: Doručiteľnosť: SPF, DKIM a DMARC v praxi · Čas čítania: 12 minút

Cieľ lekcie: Po tejto lekcii dokážete otvoriť a prečítať DMARC súhrnný report (aggregate report), pri každom riadku určiť, o aký zdroj ide a prečo uspel alebo zlyhal, a rozhodnúť sa, čo opravíte, čo môžete ignorovať a kedy môžete sprísniť svoju politiku.

Kľúčové pojmy: súhrnný report (aggregate report, RFC 9990), rua, XML, gzip alebo zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selektor, chybový report (ruf, RFC 9991), reportovacia služba, súkromie

Čo dostanete

Ak ste vo svojom DMARC zázname nastavili adresu rua (lekcia 4.4), veľkí príjemcovia ako Google, Microsoft a Yahoo vám budú posielať približne každý deň súhrnný report. Je to e-mail s prílohou, zvyčajne zazipovaný XML súbor s názvom, napríklad:

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

To znamená: od príjemcu receiver.example, o vašej doméne example.com, za obdobie medzi dvoma časovými pečiatkami (sekundy od roku 1970; v tomto prípade 6. novembra 2026, celý deň v UTC).

Report neobsahuje obsah pošty, žiadne predmety a väčšinou ani adresy príjemcov. Obsahuje pre každý odosielajúci server počet správ a výsledok SPF, DKIM a DMARC. Vďaka tomu je to spoľahlivý prehľad o tom, kto rozosiela poštu v mene vašej domény, vrátane zdrojov, na ktoré ste sami zabudli, aj podvodníkov.

Štruktúra reportu

Report má tri časti. Nižšie sú najdôležitejšie časti z ukážkového súboru k tejto lekcii (dmarc-rapport-1.xml).

1. Kto reportuje, za aké obdobie

<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. Akú politiku príjemca u vás zistil

<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>

Toto si vždy skontrolujte: ak tu nie je to, čo si myslíte, že máte vo svojom DNS, znamená to, že príjemca čítal iný (alebo starý) záznam.

3. Pre každý zdroj: jeden záznam

Každý record sa týka jednej odosielajúcej IP adresy s jednou kombináciou výsledkov:

<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>

Najdôležitejší rozdiel: auth_results oproti policy_evaluated

Tu je jadro čítania reportu. Vo vyššie uvedenom príklade sa v auth_results dvakrát objavuje pass: DKIM uspel pre mailer.example a SPF uspel pre bounce.mailer.example. Napriek tomu je v policy_evaluated dvakrát fail. Nie je to rozpor: policy_evaluated počíta len úspešnú kontrolu, ktorá je zarovnaná s header_from. Ani jedna z týchto domén nepatrí k example.com, preto DMARC zlyháva.

Takto čítate každý riadok:

1. Pozrite sa na policy_evaluated. Je pri dkim alebo spf uvedené pass? Potom DMARC uspelo a tento zdroj je v poriadku.
2. Zlyháva všetko? Pozrite sa v auth_results na domény. Je to vaša služba, ktorá síce uspeje, ale pre svoju vlastnú doménu? Potom musíte pri tejto službe zapnúť DKIM s vašou vlastnou doménou (lekcia 4.3).
3. Zlyháva to aj v auth_results, alebo DKIM úplne chýba? Zistite, komu patrí IP adresa (reverzné DNS, lekcia 5.1, alebo vyhľadanie cez whois). Ak ide o jeden z vašich systémov: opravte ho. Ak je neznáma a ide o podozrivé počty: pravdepodobne ide o falšovanie.

Vzory, ktoré uvidíte stále

Dajte si pozor aj na IPv6: vlastný server, ktorý niekedy odosiela cez IPv6, zatiaľ čo vaše SPF uvádza len IPv4 adresu, dáva pri týchto riadkoch softfail. S DKIM podpisom DMARC aj tak uspeje, ale je to znak, že vaše SPF je neúplné.

Od reportu k rozhodnutiu

Ste pripravení sprísniť svoju politiku (z none na quarantine, potom na reject), ak:

• každý zdroj, ktorý je váš, má v policy_evaluated aspoň jedno pass;
• je to tak už niekoľko týždňov, u všetkých veľkých príjemcov;
• to, čo stále zlyháva, je len presmerovaná pošta s platným DKIM podpisom (tá aj tak uspeje) alebo jasné falšovanie.

Ak zlyháva veľký vlastný zdroj, ako v príklade newsletterová služba s 1250 správami, je ešte priskoro. S p=reject by príjemca tých 1250 newsletterov odmietol.

Ako urobiť reporty čitateľnými

Jeden report v textovom editore sa dá prečítať. Dvadsať denne nie. Existujú tri spôsoby:

• Reportovacia služba (je ich veľa, aj s bezplatnou variantou). Ich adresu zadáte do rua a oni z toho vytvoria grafy a zoznamy. Pozor: tým danej službe poskytnete prehľad o tom, ktoré servery v mene vás odosielajú poštu, a reportovacia adresa je na ich doméne (pozrite si súhlas cez _report._dmarc v lekcii 4.4). Vyberte si službu, ktorej dôverujete a ktorá dodržiava GDPR.
• Vlastný nástroj: existujú open source programy, ktoré sťahujú reporty zo schránky a vytvárajú z nich prehľad.
• Čítanie manuálne pomocou XML prehliadača alebo webového prehliadača, príležitostne.

Chybové reporty (ruf, RFC 9991) sú iné: po jednej za každú neúspešnú správu, niekedy s časťami pošty v nich. Takmer žiadny veľký príjemca ich neposiela, práve kvôli súkromiu. Na správne zavedenie DMARC ich nepotrebujete.

V praxi: takto to vyzerá

Vo WebOké môžete vyplniť reportovaciu adresu v DMARC pomocníkovi v DirectAdmin alebo Môj WebOké (pozrite si lekciu 4.4), a sami si vyberiete schránku, kam budú reporty prichádzať; samostatná adresa ako dmarc@ s vlastným priečinkom zabráni tomu, aby sa vám bežná pošta strácala. Čítanie prebieha pomocou reportovacej služby alebo programu podľa výberu. To funguje u každého poskytovateľa rovnako: report má štandardný formát.

Zhrnutie

• Súhrnný report je denný XML súbor (často zazipovaný) od každého príjemcu, s počtom správ a výsledkami za každú odosielajúcu IP adresu.
• auth_results udáva surový výsledok SPF a DKIM; policy_evaluated len to, čo uspelo so zarovnaním. Pass v auth_results môže byť fail v DMARC.
• Presmerovanú poštu rozpoznáte podľa DKIM pass pri SPF fail; falšovanie podľa toho, že všetko zlyhá z neznámej IP adresy.
• Politiku sprísnite až vtedy, keď všetky vaše vlastné zdroje uspievajú už niekoľko týždňov.
• Chybové reporty (ruf) sú zriedkavé a nie sú potrebné.

Kvíz

Úloha

Úloha Z4.5: Čítanie DMARC reportu. Otvorte ukážkový súbor dmarc-rapport-1.xml (súhrnný report o doméne example.com, s vymyslenými údajmi). Odpovedzte na otázky: akú politiku príjemca zistil, koľko správ je v reporte spolu, koľko z nich zlyhalo na DMARC, ktorý riadok patrí newsletterovej službe a čo sa tam musí urobiť, ktorý riadok je presmerovaná pošta, ktorý riadok je pravdepodobne falšovanie, čo sa musí zmeniť v SPF zázname podľa riadku 6, ktorý riadok uspeje len vďaka DKIM u služby s vlastným Return-Path, a môže doména teraz prejsť na p=quarantine? Program vaše odpovede skontroluje podľa pevného kľúča a pri každej otázke vysvetlí, ktorý riadok reportu dáva odpoveď.

Odporúčame na ďalšie čítanie

Kroky v týchto článkoch platia pre panely WebOké; u iných poskytovateľov to funguje podobne.

• Čo je DMARC? Vysvetlenie v jednoduchom jazyku
• Návod na DirectAdmin 5.9: DMARC nastavenie
• Bezplatný kurz DNS 4.5: DMARC: čo majú príjemcovia robiť s podvodnou poštou
• RFC 9990 (DMARC Aggregate Reporting), s ukážkovým reportom v prílohe B; RFC 9991 (Failure Reporting)