Phishing-ul prin e-mail rămâne una dintre cele mai simple metode prin care atacatorii încearcă să păcălească angajați, clienți sau parteneri. Uneori mesajul pare trimis chiar de pe domeniul firmei: aceeași adresă vizibilă, același nume de brand, același ton. Pentru un utilizator grăbit, diferența poate fi greu de observat.
DMARC este una dintre metodele prin care o firmă poate reduce riscul ca domeniul ei să fie folosit în mesaje false. Dar DMARC nu trebuie activat brutal, direct pe „reject”, mai ales dacă firma folosește mai multe servicii de e-mail: Microsoft 365 sau Google Workspace, newslettere, CRM-uri, facturare, platforme de suport, magazine online ori aplicații care trimit notificări.
O politică DMARC bună se construiește gradual. Scopul nu este să blochezi rapid tot ce pare suspect, ci să înțelegi mai întâi cine trimite e-mail legitim în numele domeniului tău.
DMARC, pe scurt
DMARC vine peste două mecanisme deja cunoscute: SPF și DKIM. SPF arată ce servere au voie să trimită e-mail pentru domeniul tău. DKIM adaugă o semnătură criptografică mesajului, astfel încât destinatarul să poată verifica dacă mesajul nu a fost modificat și dacă vine dintr-o sursă autorizată.
DMARC verifică dacă aceste rezultate sunt aliniate cu domeniul vizibil în câmpul „From”. Dacă mesajul nu trece verificările, politica DMARC îi spune serverului destinatar ce să facă: să nu ia nicio măsură specială, să trateze mesajul ca suspect sau să îl respingă.
Cele trei politici sunt: p=none, p=quarantine și p=reject. Diferența dintre ele este importantă.
p=none înseamnă monitorizare. E-mailurile nu sunt blocate doar din cauza DMARC, dar firma primește rapoarte agregate prin care poate vedea ce surse trimit mesaje folosind domeniul.
p=quarantine cere serverelor destinatare să trateze mesajele care nu trec DMARC ca suspecte, de regulă prin trimiterea lor în spam sau prin verificări suplimentare.
p=reject este varianta strictă: mesajele care nu trec DMARC pot fi respinse înainte să ajungă la destinatar.
De ce nu începi direct cu reject
Pentru o firmă mică, tentația poate fi mare: „activăm reject și am rezolvat problema”. În practică, acesta este exact pasul care poate produce blocaje.
Dacă un serviciu legitim de newsletter nu are DKIM configurat corect, mesajele pot eșua la DMARC. Dacă o platformă de facturare trimite e-mailuri cu domeniul firmei, dar nu este inclusă corect în SPF sau nu semnează cu DKIM aliniat, facturile pot ajunge în spam sau pot fi respinse. La fel se poate întâmpla cu notificările din CRM, resetările de parolă, confirmările de comandă sau mesajele automate trimise de aplicații externe.
De aceea, prima etapă ar trebui să fie monitorizarea.
Etapa 1: pornește cu p=none
În această fază, firma publică o înregistrare DMARC în DNS cu politică de monitorizare. Ideea este să colecteze rapoarte, nu să blocheze.
Un exemplu generic arată astfel:
v=DMARC1; p=none; rua=mailto:dmarc@domeniu.ro
Adresa folosită pentru rapoarte trebuie să fie pregătită pentru volume mari de mesaje automate, mai ales dacă domeniul trimite mult e-mail. În multe cazuri, firmele folosesc un serviciu specializat pentru citirea rapoartelor DMARC, deoarece rapoartele brute sunt greu de interpretat manual.
În această etapă trebuie identificate toate sursele legitime: serverul principal de e-mail, platforma de newsletter, CRM-ul, aplicația de facturare, magazinul online, sistemele de suport și orice furnizor care trimite mesaje în numele firmei.
Etapa 2: corectează SPF și DKIM
După ce vezi sursele reale din rapoarte, urmează partea esențială: configurarea corectă.
Pentru fiecare furnizor legitim, verifică dacă SPF este autorizat și dacă DKIM este activat. Ideal, cel puțin una dintre metode trebuie să treacă și să fie aliniată cu domeniul vizibil al firmei. Nu este suficient ca un mesaj să fie „trimis de undeva autorizat”; trebuie ca domeniile folosite în autentificare să se potrivească, în mod acceptat de DMARC, cu domeniul pe care îl vede destinatarul.
Aici apar multe greșeli: domenii de tracking, subdomenii de marketing, servicii externe uitate, semnături DKIM neactivate sau înregistrări SPF prea aglomerate.
Etapa 3: treci la quarantine gradual
Când rapoartele arată că sursele legitime trec verificările, politica poate fi întărită. O variantă prudentă este p=quarantine, eventual aplicată treptat cu tagul pct, care permite aplicarea politicii doar pe o parte din flux.
Exemplu generic:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@domeniu.ro
Apoi procentul poate fi crescut treptat, dacă rapoartele nu arată probleme cu mesajele legitime. Dacă apar blocaje sau livrare în spam pentru mesaje reale, nu forța trecerea mai departe. Revino la configurații, verifică furnizorul afectat și repară SPF/DKIM.
Etapa 4: reject doar când ai încredere în flux
p=reject este obiectivul de securitate pentru multe domenii folosite strict pentru comunicare controlată, dar nu este o bifă administrativă. Trebuie aplicat numai după ce fluxurile legitime sunt clare și stabile.
Mai există un detaliu important: fluxurile indirecte, cum ar fi redirecționările și listele de discuții, pot crea probleme de livrare. Specificațiile DMARC actualizate discută aceste situații, iar firmele care folosesc intens mailing lists sau forwarding trebuie să fie mai atente înainte de a merge la respingere strictă.
Pentru o firmă, DMARC nu este doar o setare DNS. Este un mic proiect de inventariere a tuturor sistemelor care trimit e-mail. Făcut corect, ajută la reducerea mesajelor false trimise în numele brandului. Făcut în grabă, poate bloca exact comunicarea legitimă pe care firma se bazează zilnic.
Surse
- DNSC — Ghid „Ingineria socială”
- DNSC — Ghid practic pentru managementul riscurilor cibernetice
- IETF — RFC 7489, Domain-based Message Authentication, Reporting, and Conformance
- RFC Editor — RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance
- NCSC UK — Email security and anti-spoofing, DMARC quarantine/reject guidance
