DMARC explicat: de ce e-mailul dumneavoastră este vulnerabil și cum să-l reparați în 24h

DMARC este unul dintre cele mai ieftine controale de securitate cibernetică disponibile unei firme mijlocii europene. Implementarea lui corectă nu necesită achiziție de licență, infrastructură nouă, personal nou sau certificat de conformitate. Implementarea lui greșită costă la fel de puțin. Diferența este de câteva zile de disciplină operațională.

Începem fiecare misiune OSINT defensivă cu o verificare DMARC, SPF și DKIM pe domeniile principale ale clientului. În 2025 și prima jumătate a lui 2026, firma mijlocie europeană mediană pe care am analizat-o avea cel puțin unul dintre aceste trei controale configurat greșit. Cel mai des era DMARC pe `p=none` de când fusese publicat, fără nimeni care să monitorizeze rapoartele agregate pe care ar fi trebuit să le genereze.

Acest articol este un plan operațional pentru a trece de la "avem DMARC pe hârtie" la "suntem protejați la nivelul pe care directiva îl așteaptă". Presupunem că firma rulează Microsoft 365 sau Google Workspace ca platformă principală; pașii sunt echivalenți în ambele cazuri, cu detalii specifice furnizorului acolo unde diferă.

Ce face DMARC și ce nu face

DMARC înseamnă Domain-based Message Authentication, Reporting and Conformance. Este o politică exprimată într-o înregistrare DNS TXT care îi spune serverelor de mail receptoare ce să facă cu un mesaj care pretinde că vine din domeniul dumneavoastră, dar nu trece verificările SPF sau DKIM subiacente. Politica poate fi `none` (doar monitorizare), `quarantine` (mută în spam) sau `reject` (refuză livrarea).

DMARC nu vă criptează e-mailul, nu împiedică compromiterea conturilor prin reutilizarea credențialelor și nu vă apără de mesaje trimise din domenii asemănătoare. Protejează livrabilitatea și autenticitatea mesajelor trimise genuin din domeniul dumneavoastră și face ca domeniul să fie foarte greu de falsificat la scară.

Pentru fraudă tip CEO sau BEC, cea mai costisitoare amenințare prin email pentru firmele mijlocii europene din ultimii ani, DMARC pe `p=reject` taie unul dintre cele mai comune patru pretexte: un mesaj care pretinde că vine de la domeniul CEO-ului în sine, nu de la unul similar.

De ce majoritatea firmelor mijlocii sunt pe p=none

Motivul nu este lipsa conștientizării. Motivul este frica de a rupe mailul. Trecerea de la `p=none` la `p=quarantine` sau `p=reject` poate, dacă se face fără atenție, să facă mailul legitim să ajungă în spam sau să fie refuzat. Conducerea își amintește mai viu ziua în care o notificare a consiliului a ajuns în spam decât ziua în care o factură frauduloasă nu a ajuns.

Soluția acestei frici este raportul agregat. Eticheta `rua` din DMARC cere serverelor receptoare să trimită rapoarte zilnice care rezumă cine a încercat să trimită mail din domeniul dumneavoastră și dacă SPF și DKIM au trecut. Cu două săptămâni de astfel de rapoarte puteți construi o imagine completă a fiecărui expeditor legitim pe care trebuie să-l autorizați, înainte de a strânge politica.

Reparația de 24 de ore, oră cu oră

Presupunem că ați publicat deja o înregistrare DMARC pe `p=none` cu o adresă `rua` funcțională. Dacă nu, prima acțiune este să faceți asta și să așteptați două săptămâni. Planul de mai jos se aplică celei de-a doua faze.

Ora 0-4 · Inventarul expeditorilor legitimi

Adunați ultimele 14 zile de rapoarte agregate. Clasificați IP-urile sursă în patru grupuri:

1. Platforma principală de mail (M365 sau Google Workspace).

2. Platformele tranzacționale și de marketing (AWS SES, Mailgun, SendGrid, Mailchimp, Acumbamail, instanța proprie Auctimail dacă aveți).

3. Uneltele de suport și CRM care trimit mail în numele dumneavoastră (Zendesk, HubSpot, Intercom, Front).

4. Surse necunoscute.

Al patrulea grup este munca. Fiecare IP de acolo este fie un expeditor legitim nedocumentat, fie o tentativă de falsificare. Urmăriți-l pe fiecare. Surprizele cele mai comune: un server de aplicație on-premise vechi care continuă să trimită facturi printr-un relay uitat, o unealtă HR contractată anul trecut de o echipă fără coordonare cu IT și un contabil extern care v-a configurat domeniul în clientul propriu de mail pentru că nimeni nu i-a spus să nu o facă.

Ora 4-8 · Curățarea SPF

Înregistrarea SPF este o listă a expeditorilor pe care îi autorizați. Editați-o astfel încât:

• Fiecare expeditor legitim din inventar să fie inclus prin mecanismul `include:` potrivit (de ex. `include:_spf.google.com`, `include:amazonses.com`).
• Adresele IP fixe să fie eliminate dacă nu corespund unui expeditor pe care îl controlați și doriți să-l păstrați.
• Înregistrarea să nu depășească 10 căutări DNS (o cauză frecventă de eșec silențios). Dacă depășește, aplatizați cu un serviciu sau restructurați pe subdomenii.
• Mecanismul final să fie `-all` (eșec dur), nu `~all` (eșec moale).

O înregistrare SPF curată pentru o firmă mijlocie pe Google Workspace plus AWS SES plus HubSpot arată cam așa: `v=spf1 include:_spf.google.com include:amazonses.com include:_spf.hubspot.com -all`. Orice mult mai complex este un semn de drift acumulat.

Ora 8-12 · Verificarea DKIM

Pentru fiecare expeditor legitim care suportă semnătură DKIM în numele dumneavoastră, verificați că selectorul este publicat și cheia publică este actuală. Microsoft 365 folosește `selector1` și `selector2`. Google Workspace folosește un selector configurabil, tipic `google`. AWS SES folosește trei înregistrări CNAME care indică spre infrastructura sa de semnare DKIM.

Verificarea este simplă: trimiteți un mesaj de test din fiecare platformă către o căsuță care expune anteturile brute (`mailtester.com`, căsuța de test a `dmarcian.com` sau un cont Gmail cu "afișează originalul") și verificați atât `spf=pass` cât și `dkim=pass` pentru alinierea relevantă.

Dacă vreun expeditor legitim nu suportă DKIM în numele dumneavoastră, aveți o decizie strategică. Fie acceptați că acele mesaje vor eșua alinierea DMARC (și cereți expeditorului să se actualizeze sau înlocuiți-l), fie lăsați politica pe `p=quarantine` în loc de `p=reject` până se închide lacuna. Am încetat să o recomandăm pe cea din urmă; furnizorii care în 2026 nu pot semna cu DKIM-ul dumneavoastră sunt furnizori de care ar trebui să vă îndepărtați.

Ora 12-16 · Trecere la p=quarantine, pct=100

Actualizați înregistrarea DMARC la `p=quarantine; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=quarantine; adkim=s; aspf=s`. Steagurile stricte de aliniere (`adkim=s; aspf=s`) nu sunt întotdeauna necesare; modul relaxat implicit este acceptabil pentru majoritatea firmelor mijlocii. Important este să vă angajați la o acțiune reală de carantină și să monitorizați.

Supravegheați rapoartele agregate următoarele 24 de ore. Dacă un expeditor legitim neidentificat anterior începe să eșueze, adăugați-l la configurarea SPF sau DKIM înainte de a trece la pasul următor.

Ora 16-24 · Trecere la p=reject

Actualizați înregistrarea DMARC la `p=reject; pct=100; rua=...; ruf=...; sp=reject; adkim=s; aspf=s`. Comunicați conducerii că mailul care vă falsifică domeniul va fi refuzat de serverele receptoare care respectă DMARC, ceea ce înseamnă în esență întreaga populație de mari furnizori de mail.

Programați o întâlnire în calendar peste 14 zile pentru a revizui rapoartele agregate din nou, în căutarea vreunui expeditor legitim pe care trecerea l-a rupt. Până atunci surprizele sunt de obicei mici și ușor de remediat.

Despre BIMI

BIMI (Brand Indicators for Message Identification) este un control complementar care permite ca logo-ul verificat să apară lângă mesajele autentificate în clienții de mail compatibili. Necesită DMARC pe `p=quarantine` sau `p=reject` cu `pct=100`, un SVG verificat al logo-ului și un Verified Mark Certificate de la o autoritate autorizată.

Pentru o firmă mijlocie, BIMI este un plus, nu o necesitate de securitate. Ordinea onestă este DMARC mai întâi, BIMI după și doar dacă expunerea de brand justifică costul certificatului și efortul operațional de a menține VMC-ul.

Capcane oneste

• Subdomenii moștenite. Multe firme aplică DMARC pe domeniul-apex și uită `marketing.domeniuldvs.com` sau `mail.domeniuldvs.com`. Sunt necesare înregistrări DMARC explicite per subdomeniu sau un `sp=reject` strict pe apex.
• "Unelte DMARC" terțe. Mai multe produse SaaS administrează DMARC pentru dumneavoastră. Sunt comode și sunt și un terț care vede metadatele de mail ale fiecărui mesaj care pretinde că vine din domeniul dumneavoastră. Citiți acordul de prelucrare a datelor înainte de a semna.
• Fuziuni și achiziții. Când achiziționați o firmă, moșteniți postura ei DMARC. Faceți-l un punct ziua-unu pe lista de integrare.

> "Am măsurat timpul de la o înregistrare DMARC `p=none` la o postură `p=reject` funcțională în firme mijlocii, când munca este deținută de un singur inginer cu acoperire executivă. Mediana este 28 de ore. Scopul planului de 24 de ore este ca ziua a doua să fie de șlefuit, nu de panică." — Notă de teren IBL, 2026

Ce facem la IBL

Sprintul nostru DMARC este o misiune cu domeniu fix: două zile de muncă, una de monitorizare, una de șlefuire. Livrabilul este înregistrarea DMARC funcțională, înregistrarea SPF, documentația configurării DKIM, un inventar al fiecărui expeditor autorizat și un runbook de o pagină pentru inginerul care va deține controlul în continuare.

Dacă doriți o conversație despre postura DMARC actuală, scrieți la [email protected]. Răspundem într-o zi lucrătoare.

---

Ibida Black Level S.L. este o firmă boutique de consultanță în securitate cibernetică cu sediul în Málaga, Spania, și echipă operațională în România. Lucrăm cu firme mijlocii europene care preferă onestitatea tehnică în locul ambalajului comercial. Am fost înființați în 2026; nu inventăm o istorie mai lungă.

Lecturi conexe

• OSINT 101: 7 lucruri pe care un atacator le află despre firma dumneavoastră în 30 de minute (cluster pillar Q4)
• Autoevaluare NIS2: 25 de întrebări pentru a verifica dacă firma dumneavoastră se conformează (cluster pillar Q3)
• Email exposure scanner: cum să citiți raportul fără panică (cluster Q4)

Etichete: dmarc, spf, dkim, securitate-email, anti-spoofing, bec, conformitate