Implementarea DMARC: de la none la reject

Modulul 4: Livrabilitate: SPF, DKIM și DMARC în practică · Timp de citire: 12 minute

Obiectivul lecției: După această lecție veți putea explica modul în care funcționează alinierea, veți putea planifica o implementare DMARC în faze de la p=none la p=reject, veți alege etichetele potrivite (rua, sp, np, t) și veți putea gestiona capcanele cunoscute legate de redirecționare și listele de corespondență.

Noțiuni-cheie: DMARC (RFC 9989), Author Domain (domeniul din câmpul From), aliniere (alignment), relaxed și strict (adkim, aspf), domeniu organizațional, DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (mod de testare), etichetele învechite pct, rf, ri, liste de corespondență, rescrierea câmpului From, ARC

Ce verifică exact DMARC

DMARC răspunde la o singură întrebare pentru fiecare mesaj primit: a reușit SPF sau DKIM pentru un domeniu care corespunde adresei din câmpul From? Domeniul din adresa de expeditor este denumit în standard Author Domain. Elementele de bază ale înregistrării se găsesc în cursul de DNS, lecția 4.5. În mai 2026 a apărut standardul revizuit: RFC 9989, cu RFC 9990 pentru rapoartele agregate și RFC 9991 pentru rapoartele de eroare. Înregistrările existente cu v=DMARC1 rămân valabile.

Alinierea în practică

„A corespunde” se numește aliniere (alignment). Există două moduri:

• relaxed (implicit): domeniile au același domeniu organizațional. nieuws.example.com și example.com sunt aliniate; example.com și example.net nu sunt.
• strict (adkim=s sau aspf=s): domeniile trebuie să fie exact identice.

Pentru SPF, DMARC compară domeniul din Return-Path cu domeniul din From. Pentru DKIM, compară domeniul d= al unei semnături valide. Câteva exemple pentru un mesaj cu From: info@example.com:

Lăsați deci adkim și aspf pe relaxed, cu excepția cazului în care aveți un motiv întemeiat să procedați altfel.

Cum află un destinatar care este domeniul organizațional? În trecut, prin intermediul Public Suffix List, o listă cu domenii precum .nl, .co.uk și github.io. RFC 9989 înlocuiește acest mecanism cu un DNS tree walk: destinatarul caută înregistrări _dmarc ale domeniului și ale domeniilor superioare acestuia. Pentru un utilizator obișnuit nu se schimbă nimic; observați acest lucru doar dacă lucrați cu înregistrări pe subdomenii.

Implementarea în patru faze

Obiectivul este p=reject: astfel destinatarii resping mesajele care se dau drept dumneavoastră, iar aceasta este cea mai bună protecție împotriva facturilor false și a atacurilor de phishing trimise în numele dumneavoastră. Dar cine trece direct la reject fără să își cunoască expeditorii riscă să își respingă propriile facturi. De aceea recomandăm următoarea ordine (linia de recomandare a acestui curs):

Faza 0: pregătirea

• Realizați inventarul tuturor expeditorilor dumneavoastră (lecția 4.2).
• Asigurați-vă că fiecare expeditor are SPF sau DKIM aliniat; de preferat DKIM, deoarece acesta supraviețuiește redirecționării.
• Creați o adresă separată pentru rapoarte, de exemplu dmarc@example.com, sau folosiți un serviciu de rapoarte. Veți primi destul de repede câteva rapoarte pe zi.

Faza 1: măsurare cu p=none

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

p=none nu face nimic cu mesajul în sine. Destinatarii livrează totul ca de obicei, dar vă trimit zilnic un raport agregat (aggregate report) cu fiecare server care a trimis mesaje în numele domeniului dumneavoastră și dacă SPF, DKIM și DMARC au reușit. Astfel respectați și cerința minimă a Gmail, Yahoo și Microsoft pentru expeditorii în volum mare (lecția 5.3).

Lăsați acest setaj cel puțin două până la patru săptămâni, și mai mult dacă aveți servicii care trimit mesaje doar ocazional (o reamintire anuală, o factură trimestrială). Citiți rapoartele (lecția 4.5) și reparați fiecare sursă proprie care eșuează.

Faza 2: p=quarantine

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Mesajele care nu trec de DMARC ajung, la destinatar, în folderul de spam. Dacă totuși uitați o sursă, acel mesaj nu se pierde, dar devine greu de găsit. Dacă doriți să procedați cu prudență, adăugați mai întâi t=y (mod de testare): destinatarii aplică atunci o politică cu un pas mai blândă (adică none în loc de quarantine), dar veți vedea în rapoarte ce s-ar fi întâmplat. Aceasta este, în RFC 9989, înlocuitorul vechii etichete pct=.

Urmăriți din nou rapoartele timp de câteva săptămâni.

Faza 3: p=reject

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Mesajele care nu trec de DMARC sunt respinse. Expeditorul primește un bounce, la Microsoft de exemplu cu codul 5.7.509, iar la Gmail cu o referire la politica DMARC (modul 6). Continuați să urmăriți rapoartele: apar mereu servicii noi.

Când se poate merge mai rapid?

Toată corespondența dumneavoastră trece printr-un singur furnizor care se ocupă de SPF și DKIM, și nimic altceva nu este trimis în numele domeniului dumneavoastră? Atunci o politică strictă poate fi aplicată imediat. Unele companii de găzduire setează din acest motiv implicit p=reject. Dacă ulterior totuși folosiți un serviciu de newsletter sau un program de contabilitate, setați mai întâi temporar valoarea înapoi pe p=none cu o adresă pentru rapoarte, până când serviciul respectiv funcționează corect.

Celelalte etichete

O adresă pentru rapoarte pe un alt domeniu (de exemplu un serviciu de rapoarte) funcționează doar dacă acel domeniu acordă permisiunea printr-o înregistrare precum example.com._report._dmarc.rapportdienst.example. Serviciul respectiv se ocupă de obicei singur de acest lucru (RFC 9990, capitolul 4).

Capcane

Liste de corespondență

O listă de corespondență clasică redirecționează mesajul dumneavoastră către toți membrii, de pe propriul server, și adesea adaugă [listă] în subiect sau un text de subsol. În acest caz SPF eșuează (alt server), iar DKIM eșuează de asemenea (mesajul a fost modificat). Cu p=reject, destinatarii resping mesajul dumneavoastră trimis către listă. Software-ul modern pentru liste rezolvă această problemă prin rescrierea adresei From către adresa listei („Jan via Leden”), sau prin redirecționarea mesajului nemodificat. Dacă folosiți o listă care nu face acest lucru, veți observa acest fapt în rapoartele dumneavoastră.

Redirecționare

Vedeți lecția 3.3: SPF se întrerupe, DKIM de obicei supraviețuiește. Un destinatar poate decide, cu ajutorul ARC, să aibă încredere într-un redirecționator cunoscut. În rapoarte, recunoașteți această situație ca mesaje de la un server necunoscut cu DKIM pass și SPF fail; acesta nu este un motiv pentru a relaxa politica dumneavoastră.

Două înregistrări sau o greșeală de tastare

Două înregistrări DMARC pe _dmarc fac politica nevalidă, la fel ca și o greșeală de tastare în p= (p=rejected nu există). Verificați după fiecare modificare.

În practică: cum arată într-un panou

La un pachet de găzduire WebOké este setat implicit v=DMARC1;p=reject, fără adresă pentru rapoarte. Acest lucru este sigur dacă toată corespondența dumneavoastră trece prin acele servere. Dacă trimiteți mesaje și prin alte servicii, setați valoarea pe p=none cu o adresă rua și parcurgeți fazele. În DirectAdmin faceți acest lucru în DNS Administration, cu creionul de lângă înregistrarea _dmarc (câmpurile Domain policy type și Aggregate Email (RUA)); în Contul meu WebOké, cu asistentul DMARC din fila DNS. La alți furnizori creați o înregistrare TXT pe numele _dmarc și introduceți dumneavoastră înșivă textul; rezultatul este același.

Rezumat

• DMARC reușește dacă SPF sau DKIM reușește pentru un domeniu aliniat cu domeniul din From; alinierea relaxed acceptă subdomenii.
• Implementare: inventar, p=none cu rua și citirea rapoartelor, p=quarantine (eventual cu t=y), apoi p=reject.
• Folosiți np=reject pentru subdomeniile inexistente de îndată ce politica principală este strictă. pct, rf și ri sunt învechite.
• Listele de corespondență și redirecționarea generează erori previzibile; DKIM și ARC atenuează o parte din acestea.
• Exact o singură înregistrare pe _dmarc, fără greșeli de tastare.

Quiz

Exercițiu

Exercițiu Z4.4: Verificarea DMARC pentru domeniul dumneavoastră și alegerea pasului următor. Introduceți propriul domeniu (sau internet.nl). Completați înregistrarea DMARC așa cum ați găsit-o, valoarea lui p= și dacă conține o adresă rua. Alegeți apoi ce fază a implementării considerați că reprezintă următorul pas, și de ce. Programul interoghează înregistrarea în timp real, verifică sintaxa conform RFC 9989 (o singură înregistrare, p valid, etichete cunoscute, etichete învechite ca avertisment) și compară răspunsurile dumneavoastră cu rezultatul.

Lecturi suplimentare

Pașii din aceste articole sunt valabili pentru panourile WebOké; la alți furnizori funcționează în mod similar.

• Curs gratuit de DNS 4.5: DMARC: ce trebuie să facă destinatarii cu e-mailurile false
• Manual DirectAdmin 5.9: DMARC instelarea
• Ce este DMARC? Explicație pe înțelesul tuturor
• Crearea unei înregistrări DMARC în DirectAdmin
• RFC 9989 (DMARC), în special secțiunea 4.7 (etichete) și anexa C (modificări față de RFC 7489)