Ai activat monitorizarea DMARC, iar acum inboxul tău este inundat de atașamente XML arhivate de la Google, Microsoft și Yahoo. Acestea sunt Rapoarte Agregate DMARC (RUA). Par de neînțeles pentru ochiul uman, dar conțin singurele date definitive despre cine trimite emailuri în numele domeniului tău — și dacă trec sau nu de autentificare.
Ignorarea acestor rapoarte este motivul numărul 1 pentru care proiectele DMARC se blochează. Fără să le citești, nu poți trece la o politică de "reject" (respingere) pentru că nu știi ce expeditori legitimi (cum ar fi CRM-ul, helpdesk-ul sau instrumentul de facturare) ai bloca. Acest ghid explică cum să citești aceste rapoarte, ce înseamnă datele și exact cum să repari erorile "Auth Fail" pe care le găsești.
Ce este un Raport Agregat DMARC?
Un raport agregat DMARC este un rezumat zilnic trimis de un receptor de email (precum Gmail sau Office 365) către adresa de email specificată în tag-ul rua= al înregistrării tale DMARC. Nu conține emailurile propriu-zise sau conținut sensibil. În schimb, este o listă statistică a fiecărei adrese IP care a pretins că este domeniul tău în ziua anterioară.
Fiecare raport răspunde la trei întrebări critice pentru o perioadă specifică de 24 de ore:
- Cine a trimis emailuri? Adresele IP și hostname-urile expeditorilor.
- Au trecut de SPF și DKIM? Rezultatele brute ale autentificării.
- S-au aliniat? Dacă domeniul autentificat s-a potrivit cu domeniul vizibil "From" (cheia pentru a trece de DMARC).
Cum să citești XML-ul (Fără să te pierzi în el)
Deși ar trebui să folosești un instrument pentru a vizualiza aceste date (vezi "Instrumente" mai jos), înțelegerea XML-ului brut te ajută să depanezi cazurile dificile. Iată anatomia unei înregistrări din raport:
<record>
<row>
<source_ip>192.0.2.1</source_ip>
<count>50</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>domeniultau.com</header_from>
</identifiers>
<auth_results>
<spf>
<domain>terta-parte.com</domain>
<result>pass</result>
</spf>
<dkim>
<domain></domain>
<result>none</result>
</dkim>
</auth_results>
</record>Această singură înregistrare spune o poveste completă:
- Expeditorul: IP-ul 192.0.2.1 a trimis 50 de emailuri.
- Problema: SPF a trecut (tehnic), dar DMARC probabil a eșuat sau s-a bazat pur pe alinierea SPF. Observi
<domain>terta-parte.com</domain>în secțiunea SPF? Serverul a fost autorizat de terta-parte.com, nu de domeniultau.com. - Lipsa de Aliniere: Expeditorul vizibil (
header_from) este domeniultau.com, dar calea de retur SPF (domain) este terta-parte.com. Dacă acestea nu se potrivesc, Alinierea SPF eșuează.
Conceptul de bază: Aliniere vs. Autentificare
Aici se blochează 90% dintre administratori. S-ar putea să vezi "SPF Pass" în raportul tău, dar "DMARC Fail". De ce? Din cauza Alinierii.
DMARC cere ca domeniul care face autentificarea să se potrivească cu domeniul din antetul "From:".
| Verificare | Cerință | Scenariu Comun de Eșec |
|---|---|---|
| Autentificare SPF | Este IP-ul autorizat să trimită? | IP-ul este permis, dar pentru domeniul greșit (ex. domeniul SendGrid, nu al tău). |
| Aliniere SPF | Return-Path se potrivește cu From? | Folosirea unui instrument terț care gestionează bounce-urile (Return-Path) pe propriul domeniu. |
| Autentificare DKIM | Este semnătura validă? | Corpul mesajului modificat în tranzit; eșec la rotația cheilor. |
| Aliniere DKIM | Tag-ul d= se potrivește cu From? | Semnarea cu cheia generică a vendorului (d=sendgrid.net) în loc de cheia domeniului tău personalizat. |
Repararea Eșecurilor Comune de Autentificare
Scenariul 1: "SPF Nealiniat" (Mailchimp, SendGrid, Zendesk)
Simptomul: SPF spune "Pass", dar domeniul listat este mcsv.net sau sendgrid.net, în timp ce header-ul from este companiata.com. DMARC eșuează la alinierea SPF.
Soluția: Nu poți repara alinierea SPF pentru multe servicii găzduite deoarece ele trebuie să gestioneze bounce-urile (Return-Path) pe propriile servere. În schimb, trebuie să configurezi DKIM. DMARC trece dacă oricare dintre SPF sau DKIM se aliniază. Loghează-te la furnizorul tău de email, găsește setările de "Domain Authentication" și generează înregistrările CNAME pentru a activa semnarea DKIM pentru domeniul tău specific.
Scenariul 2: "Distrugătorul prin Redirecționare" (Forwarding)
Simptomul: Vezi eșecuri DMARC de la IP-uri aleatorii pe care nu le recunoști, dar rezultatul DKIM spune "pass" (dacă e prezent) sau "fail" (dacă corpul a fost schimbat). IP-urile aparțin adesea universităților sau ISP-urilor.
Realitatea: Aceasta este auto-redirecționare (auto-forwarding). Cineva de la o universitate și-a redirecționat emailul de alumni către Gmail. Serverul universității a trimis emailul, stricând SPF (pentru că IP-ul universității nu e în înregistrarea ta). Dacă ai o semnătură DKIM validă și aliniată, emailul supraviețuiește redirecționării. Dacă te bazezi doar pe SPF, emailul pică DMARC.
Soluția: Asigură-te că 100% din mailul tău legitim este semnat DKIM. Nu poți "repara" serverele de redirecționare, dar DKIM permite mailului tău să supraviețuiască saltului.
Scenariul 3: "Nepotrivirea Subdomeniului"
Simptomul: Trimiți mail de pe marketing.domeniultau.com. Înregistrarea ta SPF acoperă domeniultau.com. DMARC eșuează.
Soluția: SPF nu moștenește permisiunile. Ai nevoie de o înregistrare TXT separată pentru marketing.domeniultau.com. Alternativ, verifică modul de aliniere DMARC. Dacă politica ta spune aspf=s (strict), subdomeniile eșuează. Valoarea implicită este aspf=r (relaxed), care permite ca marketing.domeniultau.com să se alinieze cu domeniultau.com.
Instrumente pentru Vizualizarea Rapoartelor RUA
Nu încerca să citești fișierele XML manual în fiecare zi. Folosește un instrument pentru a le agrega în dashboard-uri.
- Gratuit/Open Source: Parsedmarc (self-hosted), Postmark DMARC (doar rezumate săptămânale).
- Comercial (SaaS): Valimail, Dmarcian, Uriports. Acestea oferă forensic detaliat și categorisirea expeditorilor.
- Verificare Rapidă: MXToolbox DMARC Report Analyzer (încarcă un singur fișier XML pentru vizualizare instantă).
Când să ignori eșecurile
Nu orice "Fail" dintr-un raport trebuie reparat. Vei vedea constant eșecuri de la:
- Spammer-i/Spoofer-i: IP-uri din Rusia sau China trimițând ca domeniul tău fără autentificare. Acesta este un lucru bun. Politica ta DMARC îi identifică. Odată ce treci la p=reject, aceștia sunt blocați.
- Invitații Calendar (uneori): Invitațiile auto-generate redirecționate între sisteme pot strica uneori alinierea.
Scopul tău nu este o rată de eșec de 0%; este o rată de eșec de 0% pentru infrastructura ta legitimă.
Sursă și Atribuire
Aceast articol se bazează pe date originale ale serverspan.com. Pentru metodologia completă și pentru a asigura integritatea datelor, articolul original trebuie citat. Sursa canonică este disponibilă la: Rapoartele DMARC explicate: Cum să le citești și să repari eșecurile de autentificare.
