Cum citești rapoartele DMARC aggregate fără să blochezi emailurile legitime

Rapoartele DMARC aggregate nu sunt făcute pentru citit ca un email obișnuit. Ele sunt fișiere XML, trimise periodic de serverele care primesc mesaje de la domeniul tău, iar rolul lor este să-ți arate cine trimite email în numele domeniului și dacă acele mesaje trec SPF, DKIM și DMARC. Citite corect, te ajută să reduci spoofing-ul. Citite în grabă, pot duce la o politică prea dură, care blochează newslettere, facturi, resetări de parolă sau notificări legitime.

Ce este un raport DMARC aggregate

Un raport aggregate este un rezumat tehnic, nu o listă de emailuri individuale. Conform RFC 9990, el oferă vizibilitate asupra rezultatelor de autentificare, asupra acțiunilor corective necesare și asupra efectului politicii DMARC aplicate de serverele care primesc mesajele. În practică, vei vedea surse de trimitere, volume, rezultate SPF și DKIM, rezultatul DMARC și uneori motive pentru care politica a fost tratată diferit.

Raportul ajunge la adresa setată în tagul `rua` din înregistrarea DMARC. De aceea, pentru început, politica recomandată în majoritatea implementărilor prudente este `p=none`: primești date, dar nu ceri serverelor destinatare să carantineze sau să respingă mesajele care eșuează.

Nu începe cu „reject” doar pentru că vezi eșecuri

Un eșec DMARC nu înseamnă automat fraudă. Poate fi un expeditor neautorizat, dar poate fi și un serviciu legitim configurat incomplet: platformă de facturare, CRM, aplicație de suport, tool de marketing, sistem de rezervări sau furnizor care trimite mesaje tranzacționale. Aici apare riscul real: dacă treci prea repede la `p=quarantine` sau `p=reject`, poți întrerupe emailuri de care firma depinde.

Abordarea sigură este să tratezi raportul ca pe un inventar. Întâi separi sursele cunoscute de cele necunoscute, apoi verifici dacă fiecare sursă legitimă are SPF sau DKIM corect și aliniat cu domeniul din From. Dacă ai mai multe fluxuri, merită să le separi logic, mai ales între mesaje tranzacționale și campanii de marketing; am explicat această diferență în ghidul despre separarea e-mailului tranzacțional de cel de marketing.

Câmpurile care contează cel mai mult

Într-un raport DMARC aggregate, uită-te mai întâi la domeniul raportat, intervalul de timp și politica publicată. Apoi verifică fiecare grup de rezultate: adresa IP sursă, numărul de mesaje, rezultatul DMARC, rezultatul SPF, rezultatul DKIM și domeniile folosite pentru autentificare.

Cea mai importantă întrebare este simplă: „Recunosc această sursă?” Dacă IP-ul sau furnizorul aparține unui serviciu pe care îl folosești, problema este probabil de configurare. Dacă nu recunoști sursa și volumul este suspect, poate fi o încercare de spoofing. Nu ai nevoie să deschizi linkuri sau atașamente pentru această analiză; pentru verificări punctuale, poți folosi și ghidul despre cum verifici un email suspect fără să dai click.

Alinierea contează mai mult decât un „pass” izolat

Microsoft explică DMARC prin alinierea domeniului din From cu SPF sau DKIM: mesajul trece DMARC dacă SPF sau DKIM trece în mod aliniat. Asta înseamnă că un rezultat SPF „pass” nu este suficient dacă domeniul verificat nu se aliniază cu domeniul afișat expeditorului. La fel, DKIM trebuie să fie valid și relevant pentru domeniul folosit.

De aceea, când vezi multe mesaje legitime care eșuează, nu schimba imediat politica. Verifică mai întâi semnăturile DKIM, include-urile SPF, subdomeniile și furnizorii externi. Dacă obiectivul este o politică mai strictă, urmează o trecere graduală; vezi și ghidul despre politica DMARC graduală.

Cum iei decizia fără să blochezi emailuri bune

Lucrează în etape. Colectează rapoarte suficiente, documentează fiecare sursă legitimă, repară SPF/DKIM unde este cazul, apoi urmărește dacă eșecurile scad. Abia după ce sursele legitime trec constant poți lua în calcul `quarantine`, eventual cu procent redus, apoi o politică mai strictă.

Dacă folosești și protecții de transport, rapoartele DMARC trebuie privite împreună cu MTA-STS și TLS-RPT, nu ca înlocuitor pentru ele. DMARC spune cine are voie să trimită în numele domeniului; transportul securizat este o altă piesă a puzzle-ului, explicată separat în ghidul despre MTA-STS și TLS-RPT.

Întrebări frecvente

Ce fac dacă un serviciu legitim apare cu DMARC fail?

Verifică dacă serviciul este autorizat să trimită pentru domeniul tău și dacă SPF sau DKIM este configurat și aliniat corect. Nu trece imediat la `reject`, pentru că poți bloca mesaje legitime.

Rapoartele aggregate arată conținutul emailurilor?

Nu. Ele sunt rezumate tehnice despre surse, volume și rezultate de autentificare, nu copii ale mesajelor individuale.

Când pot trece de la p=none la quarantine sau reject?

După ce ai colectat suficiente rapoarte, ai identificat sursele legitime și ai reparat problemele SPF/DKIM. Trecerea trebuie făcută gradual, pe baza datelor.

Este suficient DMARC pentru securitatea emailului?

Nu. DMARC ajută la controlul folosirii domeniului în From, dar trebuie completat cu SPF, DKIM și, unde este cazul, cu măsuri de transport securizat precum MTA-STS și TLS-RPT.