DMARC pentru firme: cum protejezi domeniul de email spoofing

Un atacator nu trebuie să intre în contul de email al firmei pentru a trimite un mesaj care pare expediat de pe domeniul acesteia. Uneori este suficient să falsifice adresa vizibilă din câmpul „De la” și să construiască un mesaj credibil pentru un client, un furnizor sau un angajat. DMARC ajută serverele destinatare să distingă mai bine mesajele autorizate de aceste tentative de falsificare și îi oferă proprietarului domeniului informații despre sursele care trimit în numele său.

Răspunsul scurt

Pentru o firmă, implementarea corectă înseamnă trei mecanisme care lucrează împreună: SPF declară ce infrastructură poate expedia mesaje, DKIM aplică o semnătură criptografică, iar DMARC verifică dacă rezultatele sunt aliniate cu domeniul pe care îl vede destinatarul. DMARC stabilește și politica pe care furnizorul de email o poate aplica mesajelor care nu trec verificările.

Configurația nu ar trebui pornită direct cu blocarea tuturor mesajelor neconforme. O abordare sigură începe cu inventarierea expeditorilor, activarea SPF și DKIM, monitorizarea printr-o politică p=none, corectarea fluxurilor legitime și abia apoi trecerea graduală la quarantine și reject. Documentațiile oficiale Google și Microsoft recomandă aceeași logică de implementare progresivă.

Ce problemă rezolvă DMARC

Adresa vizibilă a expeditorului are un rol important în încrederea cititorului. Dacă un mesaj afișează facturare@firma-exemplu.ro, un client poate presupune că solicitarea de plată provine chiar de la firmă. Fără controale potrivite, domeniul poate fi folosit în campanii de phishing, fraude cu facturi sau mesaje care cer schimbarea unui cont bancar.

DMARC, definit în standardul actual RFC 9989, le permite proprietarilor de domenii să publice o politică în DNS. Serverele care primesc mesajele pot verifica dacă expeditorul a trecut SPF sau DKIM și dacă domeniul autentificat este aliniat cu domeniul vizibil din antetul mesajului. Politica indică apoi dacă mesajele neconforme trebuie doar monitorizate, tratate cu suspiciune sau respinse.

Protecția este relevantă inclusiv pentru domeniile care nu trimit email în mod obișnuit. Dacă firma deține un domeniu folosit doar pentru un site sau o campanie, acel domeniu poate fi totuși imitat în mesaje. O politică explicită reduce ambiguitatea pentru furnizorii de email care respectă DMARC.

Cum lucrează SPF, DKIM și DMARC împreună

SPF verifică infrastructura de trimitere

SPF este o înregistrare DNS care indică serverele sau serviciile autorizate să trimită email pentru domeniu. Lista poate include furnizorul principal de email, platforma de facturare, aplicația de suport sau un serviciu tranzacțional. Verificarea se raportează la identitatea tehnică folosită în transportul mesajului, nu garantează singură că domeniul vizibil pentru utilizator este același.

DKIM semnează mesajul

DKIM adaugă mesajului o semnătură calculată cu o cheie privată păstrată de serviciul de trimitere. Cheia publică este publicată în DNS. Serverul destinatar poate verifica dacă anumite părți ale mesajului au rămas intacte și ce domeniu a semnat mesajul. O semnătură validă este utilă, dar DMARC are nevoie și ca domeniul semnăturii să fie aliniat cu adresa vizibilă.

DMARC verifică alinierea și aplică politica

DMARC nu cere ca SPF și DKIM să treacă simultan. În mod obișnuit este suficient ca unul dintre mecanisme să treacă și să fie aliniat cu domeniul din câmpul „De la”. Alinierea este partea care face diferența: un serviciu poate fi autentificat pentru propriul domeniu tehnic, dar să nu fie configurat corect pentru domeniul firmei.

De aceea, simpla prezență a unei înregistrări SPF sau a unei semnături DKIM nu dovedește că implementarea DMARC este completă. Firma trebuie să urmărească fiecare flux legitim și să confirme că identitatea folosită de furnizor corespunde politicii sale.

Inventarul care trebuie făcut înainte de modificarea DNS

Cea mai frecventă problemă nu este sintaxa înregistrării, ci uitarea unui expeditor legitim. Emailurile unei firme pot pleca din mult mai multe locuri decât inboxurile angajaților:

• Google Workspace, Microsoft 365 sau alt furnizor principal;
• aplicația de facturare și sistemul de contabilitate;
• formularul site-ului și notificările magazinului online;
• CRM-ul, platforma de suport și instrumentele de programări;
• serviciile de email tranzacțional sau comunicare comercială;
• echipamente, aplicații vechi ori servicii operate de furnizori;
• domenii secundare și subdomenii folosite în campanii.

Pentru fiecare sursă trebuie notate persoana responsabilă, tipul mesajelor, domeniul vizibil, metoda de autentificare și consecința opririi. Această listă transformă configurarea dintr-o încercare tehnică într-un proces controlat. Dacă firma nu știe cine trimite în numele său, nu poate decide în siguranță ce trafic trebuie acceptat.

Implementarea în patru etape

1. Activează și verifică SPF și DKIM

Începe cu instrucțiunile oficiale ale fiecărui furnizor. Nu copia o înregistrare găsită într-un articol și nu presupune că două companii cu același furnizor au aceeași configurație. Opțiunile pot depinde de produs, regiune și domeniile utilizate.

Google recomandă ca SPF și DKIM să fie configurate cu cel puțin 48 de ore înainte de pornirea DMARC. Intervalul permite propagarea modificărilor și observarea problemelor de bază. Verifică apoi mesaje reale trimise către mai mulți furnizori și inspectează rezultatele autentificării din anteturi.

2. Pornește DMARC în mod de monitorizare

O înregistrare inițială poate avea forma de mai jos, dar domeniul și adresa de raportare sunt exemple și nu trebuie copiate fără adaptare:

_dmarc.exemplu.ro TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@exemplu.ro"

Politica p=none cere rapoarte, fără să solicite carantinarea sau respingerea mesajelor neconforme. Adresa din rua primește rapoarte agregate în format XML. Pentru o firmă mică, acestea sunt mai ușor de folosit printr-un instrument de analiză sau printr-un proces intern care le transformă în informații lizibile.

Folosește o adresă dedicată, protejată și administrată. Rapoartele pot conține metadate operaționale despre infrastructura care trimite mesaje. Accesul trebuie acordat doar persoanelor care au nevoie de el, iar perioada de păstrare trebuie stabilită rezonabil.

3. Corectează sursele legitime

Monitorizarea trebuie să răspundă la câteva întrebări concrete: ce adrese IP trimit, ce volum au, dacă trec SPF, dacă trec DKIM și dacă domeniile sunt aliniate. O sursă necunoscută nu este automat un atac, iar una cunoscută nu este automat configurată corect.

Discută cu furnizorul atunci când o platformă legitimă nu se aliniază. Uneori trebuie activată semnarea DKIM pentru domeniul clientului; alteori trebuie schimbat domeniul tehnic de retur sau traseul de expediere. Nu relaxa politica întregului domeniu doar pentru a ascunde o integrare defectuoasă.

4. Treci gradual la aplicarea politicii

După ce sursele legitime sunt stabile, politica poate avansa la p=quarantine. Parametrul pct permite aplicarea la un procent limitat, de exemplu pct=10, pentru o etapă controlată. Procentul poate fi crescut pe măsură ce rapoartele confirmă că mesajele legitime nu sunt afectate.

Ținta matură este de regulă p=reject, adică solicitarea ca mesajele neconforme să fie respinse. Ghidul Microsoft descrie aceeași progresie către respingere, după validarea surselor. Ritmul nu trebuie decis după un calendar arbitrar, ci după dovezile din rapoarte și testele operaționale.

Ce informații oferă rapoartele agregate

Rapoartele DMARC nu sunt o listă perfectă a atacatorilor și nici un jurnal complet al mesajelor. Ele grupează rezultatele autentificării observate de furnizorii participanți. În practică, o echipă poate urmări:

• sursele și volumele care folosesc domeniul;
• proporția mesajelor care trec sau eșuează verificările;
• domeniul raportat de SPF și cel folosit de DKIM;
• evoluția unei remedieri după schimbarea configurației;
• apariția unui furnizor nou sau a unei surse neautorizate.

Interpretarea are nevoie de context. Un volum mare de eșecuri poate indica un atac, dar și o platformă de marketing configurată greșit. Un volum mic poate proveni de la un echipament uitat. Decizia bună combină raportul cu inventarul serviciilor și cu informațiile furnizorului.

Greșeli frecvente care pot afecta emailul legitim

Prima greșeală este publicarea directă a unei politici restrictive, fără monitorizare. O factură, o confirmare de comandă sau un mesaj de resetare a parolei poate fi blocat dacă serviciul nu este aliniat.

A doua este tratarea SPF ca o listă care poate fi completată la nesfârșit. Configurațiile complicate, duplicate sau întreținute de mai multe persoane devin greu de controlat. Orice modificare trebuie documentată și verificată după propagare.

A treia este ignorarea subdomeniilor. Politica principală și parametrul sp trebuie analizate împreună cu modul real în care compania folosește subdomeniile. Un subdomeniu pentru notificări poate avea alte surse decât domeniul principal.

A patra este colectarea rapoartelor fără un proprietar al procesului. O căsuță plină cu fișiere XML nu protejează firma. Cineva trebuie să urmărească tendințele, să investigheze schimbările și să mențină inventarul.

A cincea este presupunerea că DMARC oprește orice tentativă de phishing. Un atacator poate folosi un domeniu asemănător, poate compromite un cont legitim sau poate trimite de pe o adresă complet diferită. DMARC protejează utilizarea domeniului configurat, nu înlocuiește securitatea conturilor, filtrarea mesajelor și instruirea angajaților.

Ce trebuie să decidă conducerea firmei

DMARC nu este doar o setare DNS. Conducerea trebuie să stabilească cine aprobă furnizorii de email, cine gestionează domeniul, cine primește alertele și cât de repede este escaladată o problemă. Aceste responsabilități devin importante în momentul în care un serviciu critic riscă să nu mai livreze mesaje.

Un plan minim ar trebui să răspundă clar la următoarele întrebări:

1. Care sunt toate serviciile autorizate să trimită pentru firmă?
2. Cine poate modifica înregistrările DNS și cine verifică schimbarea?
3. Unde sunt analizate rapoartele și cât timp sunt păstrate?
4. Cum este testată livrarea mesajelor critice înainte de o politică mai strictă?
5. Cine contactează furnizorul și cine aprobă revenirea temporară dacă apare un incident?

Procesul se leagă firesc de alegerea unui email profesional pentru firmă, de un audit de securitate inițial și de un plan de răspuns la incidente. Pentru site-urile care trimit notificări sau mesaje din formulare, verificarea trebuie inclusă și în procedurile de protecție a site-ului.

Limitele protecției

DMARC nu confirmă că mesajul este adevărat, că atașamentul este sigur sau că expeditorul are o intenție legitimă. Un cont compromis poate trimite mesaje care trec autentificarea. Un domeniu foarte asemănător poate păcăli un cititor neatent. De aceea, autentificarea domeniului trebuie combinată cu autentificare multifactor, politici de acces, monitorizare, backup, filtre de securitate și proceduri pentru solicitările financiare neobișnuite.

Implementarea poate sprijini reputația tehnică a domeniului, dar nu garantează că fiecare mesaj va ajunge în inbox. Livrarea depinde și de conținut, comportamentul destinatarilor, reputația adreselor IP și politicile furnizorilor. Evită promisiunile de tipul „DMARC rezolvă livrabilitatea”; rolul său principal este autentificarea și aplicarea unei politici pentru domeniu.

Concluzie

O firmă nu ar trebui să aleagă între protecție și livrarea mesajelor legitime. Implementarea graduală permite ambele obiective: inventariezi expeditorii, configurezi SPF și DKIM, observi traficul cu p=none, corectezi alinierile și aplici treptat o politică mai strictă. Rezultatul este o regulă controlată, bazată pe date, nu o înregistrare DNS publicată în grabă.

Dacă domeniul are mai mulți furnizori, integrări vechi sau responsabilități neclare, o evaluare tehnică înaintea schimbării reduce riscul operațional. Poți consulta serviciul intern de audit al site-ului și infrastructurii digitale. InternetRomania.ro și Brandwave.ro sunt operate de aceeași entitate, iar această relație este prezentată transparent atunci când un material conduce către servicii de implementare.