DMARC ataskaitų skaitymas

4 modulis: Pristatomumas: SPF, DKIM ir DMARC praktikoje · Skaitymo trukmė: 12 min.

Mokymosi tikslas: Po šios pamokos galėsite atidaryti ir perskaityti DMARC suvestinę ataskaitą (aggregate report), kiekvienoje eilutėje nustatyti, koks tai šaltinis ir kodėl jis sėkmingas ar nesėkmingas, bei nuspręsti, ką reikia taisyti, ką galima ignoruoti ir kada galima griežtinti politiką.

Pagrindinės sąvokos: suvestinė ataskaita (aggregate report, RFC 9990), rua, XML, gzip arba zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selektorius, klaidų ataskaita (ruf, RFC 9991), ataskaitų paslauga, privatumas

Ką gausite

Jei savo DMARC įraše nurodėte rua adresą (4.4 pamoka), tokie dideli gavėjai kaip Google, Microsoft ir Yahoo kasdien atsiųs Jums suvestinę ataskaitą (aggregate report). Tai laiškas su priedu, dažniausiai suspaustu XML failu, kurio pavadinimas panašus į:

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

Tai reiškia: nuo gavėjo receiver.example, apie Jūsų domeną example.com, už laikotarpį tarp dviejų laiko žymų (sekundės nuo 1970 metų; čia 2026 m. lapkričio 6 d., visa diena UTC laiku).

Ataskaitoje nėra laiškų turinio, nėra temų ir dažniausiai nėra gavėjų adresų. Joje pateikiamas kiekvieno siunčiančio serverio laiškų skaičius ir SPF, DKIM bei DMARC rezultatas. Todėl tai patikima apžvalga, kas siunčia laiškus Jūsų domeno vardu, įskaitant šaltinius, apie kuriuos galbūt pamiršote, ir sukčius.

Ataskaitos sandara

Ataskaitą sudaro trys dalys. Žemiau pateikiamos svarbiausios dalys iš šios pamokos pavyzdinio failo (dmarc-rapport-1.xml).

1. Kas teikia ataskaitą ir už kokį laikotarpį

<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. Kokią politiką gavėjas rado Jūsų domene

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

Tai visada patikrinkite: jei čia nurodyta ne tai, ką manote esant savo DNS įrašuose, vadinasi, gavėjas nuskaitė kitą (arba pasenusį) įrašą.

3. Kiekvienam šaltiniui: po įrašą (record)

Kiekvienas record apima vieną siunčiantį IP adresą su viena rezultatų kombinacija:

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

Svarbiausias skirtumas: auth_results prieš policy_evaluated

Čia slypi skaitymo esmė. Aukščiau pateiktame pavyzdyje auth_results du kartus rodo pass: DKIM buvo sėkmingas domenui mailer.example, o SPF buvo sėkmingas domenui bounce.mailer.example. Tačiau policy_evaluated du kartus rodo fail. Tai nėra prieštaravimas: policy_evaluated įskaito tik sėkmingą patikrą, kuri yra suderinta (aligned) su header_from. Nė vienas iš šių domenų nepriklauso example.com, todėl DMARC nepavyksta.

Taip skaitykite kiekvieną eilutę:

1. Pažiūrėkite į policy_evaluated. Ar prie dkim arba spf nurodyta pass? Tuomet DMARC sėkmingas ir šis šaltinis tvarkingas.
2. Jei viskas nesėkminga? Pažiūrėkite auth_results domenus. Ar tai Jūsų naudojama paslauga, kuri sėkmingai praeina patikrą, bet su savo pačios domenu? Tuomet toje paslaugoje reikia įjungti DKIM su savo domenu (4.3 pamoka).
3. Jei nesėkminga ir auth_results, arba DKIM visai nėra? Išsiaiškinkite, kam priklauso IP adresas (atvirkštinis DNS, 5.1 pamoka, arba whois paieška). Jei tai viena iš Jūsų sistemų: taisykite. Jei tai nežinomas šaltinis ir skaičiai įtartini: tikėtina, kad tai klastojimas.

Dažniausi pasikartojantys modeliai

Atkreipkite dėmesį ir į IPv6: savas serveris, kuris kartais siunčia per IPv6, kai Jūsų SPF nurodo tik IPv4 adresą, tose eilutėse rodys softfail. Su DKIM parašu DMARC vis tiek bus sėkmingas, bet tai ženklas, kad Jūsų SPF nėra pilnas.

Nuo ataskaitos iki sprendimo

Esate pasiruošę griežtinti politiką (nuo none prie quarantine, vėliau prie reject), kai:

• kiekvienas Jums priklausantis šaltinis policy_evaluated turi bent vieną pass;
• taip yra jau kelias savaites, pas visus didelius gavėjus;
• tai, kas vis dar nesėkminga, yra tik persiųsti laiškai su galiojančiu DKIM parašu (tie vis tiek bus sėkmingi) arba akivaizdus klastojimas.

Jei nesėkmingas didelis savas šaltinis, kaip pavyzdyje naujienlaiškio paslauga su 1250 laiškų, tuomet dar per anksti. Su p=reject gavėjas atmestų tuos 1250 naujienlaiškių.

Kaip padaryti ataskaitas skaitomas

Vieną ataskaitą teksto redaktoriuje dar galima atidaryti. Dvidešimt per dieną jau ne. Yra trys būdai:

• Ataskaitų paslauga (jų yra daug, kai kurios ir su nemokamu variantu). Įrašote jų adresą rua lauke, o jie paverčia duomenis grafikais ir sąrašais. Atkreipkite dėmesį: tokiu atveju suteikiate tai paslaugai įžvalgą, kokie serveriai siunčia laiškus Jūsų vardu, o ataskaitų adresas yra tos paslaugos domene (žr. patvirtinimą per _report._dmarc 4.4 pamokoje). Rinkitės paslaugą, kuria pasitikite ir kuri laikosi BDAR.
• Savas įrankis: yra atvirojo kodo programų, kurios ištraukia ataskaitas iš pašto dėžutės ir pateikia jas suvestinėje.
• Skaityti patiems naudojant XML peržiūros įrankį ar naršyklę, retkarčiais.

Klaidų ataskaitos (ruf, RFC 9991) skiriasi: jos pateikiamos kiekvienam nepavykusiam laiškui, kartais su laiško dalimis. Beveik joks didelis gavėjas jų nesiunčia, kaip tik dėl privatumo. Jos nereikalingos sėkmingam DMARC diegimui.

Praktikoje: taip tai atrodo

WebOké galite įvesti ataskaitų adresą DMARC pagalbos skiltyje DirectAdmin arba Mano WebOké (žr. 4.4 pamoką), ir patys pasirenkate pašto dėžutę, į kurią ataskaitos ateis; atskiras adresas, pavyzdžiui dmarc@, su savo aplanku apsaugo nuo to, kad įprastas paštas paskęstų ataskaitų sraute. Skaitymui naudokite pasirinktą ataskaitų paslaugą ar programą. Tai veikia vienodai pas visus tiekėjus: ataskaita yra standartinio formato.

Santrauka

• Suvestinė ataskaita yra kasdienis XML failas (dažnai suspaustas) kiekvienam gavėjui, su kiekvieno siunčiančio IP laiškų skaičiumi ir rezultatais.
• auth_results pateikia neapdorotą SPF ir DKIM rezultatą; policy_evaluated tik tai, kas buvo suderinta sėkmingai. Pass auth_results gali reikšti fail DMARC atveju.
• Persiųstą laišką atpažinsite iš DKIM pass su SPF fail; klastojimą iš viso fail iš nežinomo IP.
• Griežtinkite politiką tik tada, kai visi Jūsų šaltiniai jau kelias savaites sėkmingi.
• Klaidų ataskaitos (ruf) yra retos ir nereikalingos.

Testas

Užduotis

Užduotis Z4.5: DMARC ataskaitos skaitymas. Atidarykite pavyzdinį failą dmarc-rapport-1.xml (suvestinę ataskaitą apie example.com, su sugalvotais duomenimis). Atsakykite į klausimus: kokią politiką rado gavėjas, kiek laiškų iš viso nurodyta ataskaitoje, kiek iš jų nepraėjo DMARC, kuri eilutė yra naujienlaiškio paslauga ir ką ten reikia padaryti, kuri eilutė yra persiųstas laiškas, kuri eilutė tikriausiai yra klastojimas, ką reikia pakeisti SPF įraše pagal 6 eilutę, kuri eilutė sėkminga tik dėl DKIM paslaugoje su savo Return-Path, ir ar domenas jau gali pereiti prie p=quarantine? Programa patikrins Jūsų atsakymus pagal fiksuotą atsakymų raktą ir prie kiekvieno klausimo paaiškins, kuri ataskaitos eilutė lemia atsakymą.

Skaitykite daugiau

Šiuose straipsniuose aprašyti veiksmai galioja WebOké valdymo skydeliams; kitose paslaugų teikėjų sistemose veikimas panašus.

• Kas yra DMARC? Paaiškinimas paprasta kalba
• DirectAdmin vadovas 5.9: DMARC nustatymas
• Nemokamas DNS kursas 4.5: DMARC: ką gavėjai turi daryti su netikru paštu
• RFC 9990 (DMARC Aggregate Reporting), su pavyzdine ataskaita B priede; RFC 9991 (Failure Reporting)