Citirea rapoartelor DMARC

Modulul 4: Livrabilitate: SPF, DKIM și DMARC în practică · Timp de citire: 12 minute

Obiectiv de învățare: După această lecție veți putea deschide și citi un raport agregat DMARC, veți putea stabili pentru fiecare rând care este sursa și de ce reușește sau eșuează, și veți putea decide ce reparați, ce puteți ignora și când vă puteți înăspri politica.

Noțiuni cheie: raport agregat (aggregate report, RFC 9990), rua, XML, gzip sau zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selector, raport de eșec (ruf, RFC 9991), serviciu de raportare, confidențialitate

Ce primiți

Dacă ați introdus o adresă rua în înregistrarea dumneavoastră DMARC (lecția 4.4), furnizorii mari precum Google, Microsoft și Yahoo vă trimit aproximativ zilnic un raport agregat. Este un mesaj cu o anexă, de obicei un fișier XML comprimat, cu un nume de forma:

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

Aceasta înseamnă: de la destinatarul receiver.example, despre domeniul dumneavoastră example.com, pentru perioada dintre cele două marcaje de timp (secunde de la 1970; aici 6 noiembrie 2026, întreaga zi în UTC).

Un raport nu conține conținutul mesajelor, nu conține subiecte și, de regulă, nici adresele destinatarilor. Conține, pentru fiecare server de trimitere, numărul de mesaje și rezultatul SPF, DKIM și DMARC. Astfel, este o imagine de încredere a celor care trimit e-mail în numele domeniului dumneavoastră, inclusiv a surselor pe care le-ați uitat și a celor care fac fraude.

Structura unui raport

Un raport are trei părți. Mai jos sunt cele mai importante fragmente din fișierul exemplu de la această lecție (dmarc-rapport-1.xml).

1. Cine raportează, pentru ce perioadă

<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. Ce politică a găsit destinatarul la dumneavoastră

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

Verificați întotdeauna acest lucru: dacă aici nu apare ceea ce credeți că aveți în DNS, înseamnă că destinatarul a citit o altă înregistrare (sau una veche).

3. Pentru fiecare sursă: o înregistrare

Fiecare record se referă la o singură adresă IP de trimitere, cu o combinație de rezultate:

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

Diferența esențială: auth_results în raport cu policy_evaluated

Aici se află esența citirii unui raport. În exemplul de mai sus, în auth_results apare de două ori pass: DKIM a reușit pentru mailer.example, iar SPF a reușit pentru bounce.mailer.example. Totuși, în policy_evaluated apare de două ori fail. Aceasta nu este o contradicție: policy_evaluated contorizează doar o verificare reușită care este aliniată cu header_from. Niciunul dintre cele două domenii nu aparține de example.com, deci DMARC eșuează.

Așa citiți fiecare rând:

1. Priviți la policy_evaluated. Apare la dkim sau spf un pass? Atunci DMARC reușește și această sursă este în regulă.
2. Totul eșuează? Priviți în auth_results la domenii. Este vorba de un serviciu de-al dumneavoastră care reușește, dar pentru propriul său domeniu? Atunci trebuie să activați la acel serviciu DKIM cu propriul dumneavoastră domeniu (lecția 4.3).
3. Eșuează și în auth_results, sau lipsește DKIM cu totul? Aflați cine este adresa IP (reverse DNS, lecția 5.1, sau o căutare whois). Este unul dintre sistemele dumneavoastră: reparați. Este necunoscut și sunt în joc numere suspecte: probabil este vorba de falsificare.

Tipare pe care le veți vedea frecvent

Fiți atenți și la IPv6: un server propriu care uneori trimite prin IPv6, în timp ce SPF-ul dumneavoastră menționează doar adresa IPv4, generează un softfail pe acele rânduri. Cu o semnătură DKIM, DMARC reușește totuși, dar acesta este un semn că SPF-ul dumneavoastră este incomplet.

De la raport la decizie

Sunteți pregătit să vă înăspriți politica (de la none la quarantine, apoi la reject) atunci când:

• fiecare sursă care vă aparține are cel puțin un pass în policy_evaluated;
• această situație persistă deja de câteva săptămâni, la toți destinatarii mari;
• ceea ce mai eșuează este doar mesaj redirecționat cu o semnătură DKIM validă (care reușește totuși) sau falsificare evidentă.

Dacă o sursă proprie importantă eșuează, cum ar fi în exemplu serviciul de newsletter cu 1250 de mesaje, este prea devreme. Cu p=reject, destinatarul ar respinge acele 1250 de newslettere.

Cum faceți rapoartele lizibile

Un singur raport într-un editor de text este gestionabil. Douăzeci pe zi, nu. Există trei metode:

• Un serviciu de raportare (există multe, și cu o variantă gratuită). Introduceți adresa lor în rua, iar ei transformă datele în grafice și liste. Atenție: astfel îi oferiți acelui serviciu acces la informații despre ce servere trimit în numele dumneavoastră, iar adresa de raportare se află pe domeniul lor (vedeți consimțământul prin _report._dmarc în lecția 4.4). Alegeți un serviciu în care aveți încredere și care respectă GDPR.
• Un instrument propriu: există programe open source care extrag rapoartele dintr-o căsuță de e-mail și le transformă într-o prezentare generală.
• Citirea manuală cu un vizualizator XML sau un browser, pentru situații ocazionale.

Rapoartele de eșec (ruf, RFC 9991) sunt diferite: pentru fiecare mesaj eșuat în parte, uneori conținând fragmente din mesaj. Aproape niciun destinatar mare nu le trimite, tocmai din motive de confidențialitate. Nu aveți nevoie de ele pentru a implementa corect DMARC.

În practică: așa arată

La WebOké, puteți completa adresa de raportare în asistentul DMARC din DirectAdmin sau Contul meu WebOké (vedeți lecția 4.4), și alegeți dumneavoastră înșivă o căsuță poștală unde ajung rapoartele; o adresă separată, precum dmarc@, cu propriul său folder, previne aglomerarea mesajelor obișnuite. Citirea o faceți cu un serviciu de raportare sau un program la alegere. Acest lucru funcționează la fel la orice furnizor: raportul are un format standard.

Rezumat

• Un raport agregat este un fișier XML zilnic (adesea comprimat) pentru fiecare destinatar, cu numărul de mesaje și rezultatele pentru fiecare IP de trimitere.
• auth_results oferă rezultatul brut SPF și DKIM; policy_evaluated arată doar ce a reușit aliniat. Un pass în auth_results poate fi un fail în DMARC.
• Mesajele redirecționate se recunosc după DKIM pass cu SPF fail; falsificarea, după totul fail provenind de la un IP necunoscut.
• Înăspriți-vă politica doar după ce toate sursele dumneavoastră proprii reușesc de câteva săptămâni.
• Rapoartele de eșec (ruf) sunt rare și nu sunt necesare.

Quiz

Exercițiu

Exercițiul Z4.5: Citirea unui raport DMARC. Deschideți fișierul exemplu dmarc-rapport-1.xml (un raport agregat despre example.com, cu date fictive). Răspundeți la întrebări: ce politică a găsit destinatarul, câte mesaje figurează în total în raport, câte dintre acestea au eșuat DMARC, care rând este serviciul de newsletter și ce trebuie să se întâmple acolo, care rând este mesaj redirecționat, care rând este probabil falsificare, ce trebuie schimbat în înregistrarea SPF conform rândului 6, care rând reușește doar datorită DKIM la un serviciu cu propriul Return-Path, și poate domeniul să treacă acum la p=quarantine? Programul vă verifică răspunsurile folosind o grilă fixă și explică, pentru fiecare întrebare, ce rând din raport oferă răspunsul.

Lecturi suplimentare

Pașii din aceste articole sunt valabili pentru panourile WebOké; la alți furnizori funcționează similar.

• Ce este DMARC? Explicație pe înțelesul tuturor
• Manual DirectAdmin 5.9: DMARC instelarea
• Curs gratuit de DNS 4.5: DMARC: ce trebuie să facă destinatarii cu e-mailurile false
• RFC 9990 (DMARC Aggregate Reporting), cu raportul exemplu în anexa B; RFC 9991 (Failure Reporting)