Înainte să modifici ceva, vezi ce există și, mai ales, cine trimite mail în numele domeniului. Asta e partea care strică cele mai multe implementări: pui politică strictă fără inventar și îți pică propriile facturi.

dig +short TXT firma.ro | grep spf
dig +short TXT selector1._domainkey.firma.ro
dig +short TXT _dmarc.firma.ro
Rezultat la noi: SPF cu ~all (softfail) și include doar pentru Microsoft, nicio cheie DKIM publicată pentru ERP, niciun record DMARC. Adică oricine putea falsifica domeniul și nimeni nu aflase vreodată.

Pasul zero a fost deci DMARC în mod monitorizare, fără nicio acțiune asupra mailului:

_dmarc.firma.ro TXT “v=DMARC1; p=none; rua=mailto:dmarc@firma.ro; fo=1”
Cu p=none nu blochezi nimic, dar primești rapoarte agregate (XML) de la Google, Microsoft și alții. Ele arată fiecare IP care a trimis mail cu domeniul tău și dacă a trecut SPF/DKIM. Am lăsat asta două săptămâni. Rapoartele XML sunt greu de citit direct, așa că am folosit un parser gratuit (există mai multe servicii cu plan gratuit pentru volume mici) care le transformă în tabel.

Ce am găsit în rapoarte:

Microsoft 365: trecea SPF, dar DKIM era nepornit pe domeniul custom (semna cu domeniul onmicrosoft.com, deci fără aliniere).
Serverul ERP: IP-ul lui nu era în SPF. Facturile treceau doar pentru că majoritatea clienților nu verificau. O platformă de newsletter pe care marketingul o pornise fără să anunțe IT-ul. Câteva zeci de IP-uri necunoscute din afară, încercând să trimită în numele domeniului. Acelea erau atacatorii.

Deznodământul
Am reparat pe rând, în ordinea riscului.

1. DKIM pe Microsoft 365. Se publică două CNAME-uri (selector1 și selector2) și apoi se activează semnarea din Defender:

selector1._domainkey.firma.ro CNAME selector1-firma-ro._domainkey.firma.onmicrosoft.com
selector2._domainkey.firma.ro CNAME selector2-firma-ro._domainkey.firma.onmicrosoft.com
2. SPF curat. Am adăugat IP-ul ERP-ului și platforma de newsletter, apoi am trecut la -all. Atenție la limita de 10 lookup-uri DNS din SPF: fiecare include contează, iar peste 10 primești permerror și tot recordul devine inutil. Am verificat cu un tool de flattening și am scos două include-uri vechi, rămase de la un furnizor de hosting dispărut.

firma.ro TXT “v=spf1 ip4:203.0.113.25 include:spf.protection.outlook.com include:_spf.newsletter-provider.example -all”
3. ERP-ul. Cel mai dificil. Serverul vechi nu putea semna DKIM. Soluția pragmatică: l-am pus să trimită prin conectorul SMTP autentificat al Microsoft 365, deci mailul lui pleacă semnat de Microsoft. Altfel rămânea doar alinierea prin SPF, care e fragilă.

4. Escaladarea DMARC. Nu am sărit direct la reject. Calendarul a fost:

săpt. 1-2 p=none
săpt. 3-4 p=quarantine; pct=10
săpt. 5-6 p=quarantine; pct=100
săpt. 8+ p=reject
La a treia săptămână de quarantine, un client ne-a sunat că nu primește oferte. Se dovedise că un agent comercial trimitea de pe un Gmail personal, cu From-ul firmei, prin “Send mail as”. Fără rapoarte l-am fi descoperit abia după reject, cu oferte pierdute. L-am mutat pe un cont de firmă.

Rezultatul după două luni: p=reject activ, rapoartele arată zeci de încercări de spoofing respinse pe săptămână, iar ultimul mesaj fals nu a mai ajuns la nimeni. Nu rezolvă phishingul făcut de pe domenii asemănătoare (firma-ro.com), pentru care am pus separat reguli în Exchange și am înregistrat câteva variante evidente ale domeniului.

Un detaliu pe care l-am subestimat: alinierea. DMARC nu cere doar ca SPF sau DKIM să treacă, ci ca domeniul validat să corespundă cu cel din From. Platforma de newsletter trecea SPF, dar pe domeniul ei, nu pe al nostru, deci pentru DMARC conta ca eșec. Soluția a fost să configurăm un subdomeniu dedicat (news.firma.ro) cu propriul DKIM, ceea ce a izolat și reputația: dacă marketingul greșește ceva, nu se afectează mailul de contabilitate. Recomand subdomenii separate pentru orice serviciu terț care trimite masiv.