DMARC a devenit standard de Internet. Ce schimbă de fapt RFC 9989 în DNS-ul tău

Majoritatea companiilor configurează o înregistrare DMARC o singură dată, de obicei pentru că a cerut-o o platformă de marketing, și nu se mai uită niciodată la ea. În mai 2026, IETF a publicat RFC 9989, care înlocuiește specificația DMARC originală din 2015. Nimic din DNS-ul tău nu s-a stricat în ziua aceea și nu ai nevoie de intervenții urgente. Dar trei tag-uri dintr-o înregistrare tipică sunt acum oficial depășite, mecanismul prin care serverele destinatare îți găsesc politica a fost înlocuit complet, iar recomandarea pentru cea mai strictă politică s-a inversat. Dacă înregistrarea ta a fost scrisă acum cinci ani, o parte din ea descrie un protocol care în forma aceea nu mai există.

1. Ce a fost publicat și ce înseamnă

În mai 2026, IETF a publicat trei documente: RFC 9989 (protocolul DMARC de bază), RFC 9990 (rapoartele agregate) și RFC 9991 (rapoartele de eșec). Împreună, ele înlocuiesc RFC 7489 și RFC 9091. RFC 7489 a fost publicat în 2015 ca document Informational — o descriere a ceea ce făcea industria, nu un standard asumat de IETF. RFC 9989 este pe Standards Track, la nivelul Proposed Standard. Timp de unsprezece ani, DMARC a fost o convenție larg implementată cu ambiguități rezolvate diferit de fiecare furnizor. Acum este o specificație cu consens formal în spate. Ce nu s-a schimbat: înregistrările încep în continuare cu v=DMARC1. Nu există DMARC2. Tag-urile necunoscute trebuie ignorate de serverele destinatare, deci orice înregistrare aflată azi în producție continuă să funcționeze. Este o curățenie, nu o migrare.

2. Trei tag-uri din înregistrarea ta nu mai există

Registrul IANA pentru tag-urile DMARC a fost actualizat. Trei tag-uri sunt marcate ca historic — depreciate și neașteptate în implementările curente:

• pct (rata de eșantionare). Tag-ul care permitea aplicarea politicii doar unui procent din mesajele care eșuau a dispărut. Motivele eliminării sunt explicate în Anexa A.6 a RFC 9989.
• rf (formatul rapoartelor de eșec).
• ri (intervalul rapoartelor agregate). Serverele destinatare ar trebui oricum să genereze rapoarte agregate cel puțin o dată la 24 de ore.

În locul lor, t este acum un tag înregistrat: modul de test al politicii DMARC, cu valorile y sau n și valoarea implicită n. Setarea t=y cere destinatarului să aplice nivelul de sub politica declarată. p=reject; t=y → tratat ca quarantine. p=quarantine; t=y → tratat ca none. Acesta este înlocuitorul pentru pct. Alte două tag-uri active și insuficient folosite: np (politica pentru subdomeniile inexistente) și psd (declară dacă un domeniu este public suffix).

3. Public Suffix List a dispărut, locul lui a fost luat de DNS Tree Walk

Aceasta este cea mai mare schimbare tehnică din specificație. Sub RFC 7489, destinatarii foloseau o Public Suffix List ca să determine domeniul organizațional al unui domeniu expeditor. Vechea specificație nu impunea o listă anume, nu dădea indicații despre cât de des trebuie reîmprospătată și recunoștea că destinatari diferiți cu liste diferite ajung la rezultate inconsecvente. RFC 9989 înlocuiește asta cu DNS Tree Walk. Serverul destinatar interoghează mai întâi _dmarc la nivelul Author Domain. Dacă nu găsește o înregistrare validă, urcă în spațiul de nume câte o etichetă pe rând, limitat la opt interogări. Două consecințe practice:

1. Dacă trimiți dintr-un domeniu cu mai mult de opt etichete, publică o înregistrare exact la acel nume. O înregistrare la un zone cut intermediar nu va fi găsită niciodată de parcurgere.
2. Organizațiile mari cu DNS descentralizat câștigă un instrument. Publicând psd=n pe un subdomeniu, îl declari drept propriul domeniu organizațional, fără să atingi înregistrarea de la apex.

Regula generală nu s-a schimbat: publică înregistrări DMARC explicite pe domeniile de pe care chiar trimiți.

4. Recomandarea privind p=reject s-a inversat

Ani la rând, sfatul standard a fost să duci fiecare domeniu de la p=none la p=quarantine și apoi la p=reject. RFC 9989 este vizibil mai prudent, iar prudența este normativă:

• Domeniile care găzduiesc utilizatori ce ar putea posta pe liste de discuții nu ar trebui să publice p=reject. Listele și redirecționările strică frecvent alinierea SPF, iar o politică de reject face ca software-ul de listă să îți dezaboneze automat utilizatorii.
• Domeniile care publică totuși p=reject nu trebuie să se bazeze doar pe SPF și trebuie să aplice semnături DKIM valide. Semnăturile DKIM supraviețuiesc de obicei redirecționării. SPF, de obicei, nu.
• Serverele destinatare nu trebuie să respingă un mesaj doar pentru că domeniul expeditor publică p=reject. În lipsa altor analize, ar trebui să trateze mesajul ca quarantine.
• Pentru a trece la reject: publică p=none cel puțin o lună, apoi p=quarantine pentru o perioadă la fel de lungă, și compară rezultatele înainte de a decide.

Nu este o retragere de la aplicare. Este recunoașterea faptului că unsprezece ani de producție au arătat că reject produce daune colaterale pe fluxurile indirecte de email.

5. Ce impun furnizorii de căsuțe poștale, o întrebare separată

RFC-ul descrie protocolul. Google, Yahoo și Microsoft descriu condițiile în care mesajele tale ajung la utilizatorii lor. Google: din februarie 2024, expeditorii care trimit peste 5.000 de mesaje pe zi către conturi personale Gmail trebuie să aibă și SPF, și DKIM, o înregistrare DMARC pe domeniul expeditor (none este acceptabilă), aliniere a câmpului From, dezabonare cu un singur click și rată de spam sub 0,3%. Din noiembrie 2025 Google a intensificat aplicarea, cu respingeri temporare și permanente. Microsoft: în vigoare din 5 mai 2025, domeniile care trimit peste 5.000 de mesaje pe zi necesită SPF, DKIM și DMARC de cel puțin p=none. Mesajele neconforme ajung mai întâi în Junk, iar pasul următor este respingerea cu 550 5.7.515 Access denied. Yahoo aplică cerințe echivalente. Observă forma lucrurilor: RFC-ul scade presiunea pe p=reject, în timp ce furnizorii ridică pragul minim pentru existența autentificării. Publică înregistrări peste tot, autentifică serios cu ambele mecanisme și fii deliberat în privința nivelului de aplicare.

6. Două capcane SPF pe care specificația le numește explicit

Hard fail îți poate ascunde problemele. Dacă înregistrarea ta SPF se termină cu -all, serverul destinatar poate respinge mesajul devreme în tranzacția SMTP, înainte ca DMARC să fie evaluat. Sesiunea nu ajunge la faza DATA, domeniul From nu este dezvăluit, iar mesajul nu apare deloc în rapoartele tale agregate. Mesaje care ar fi trecut DMARC pe baza unei semnături DKIM aliniate sunt respinse doar pe SPF — fără vizibilitate. Subdomeniile delegate îți pot falsifica domeniul principal. Cu aliniere relaxată, dacă un atacator controlează DNS-ul unui subdomeniu al domeniului tău organizațional și publică acolo o înregistrare SPF, poate trimite mesaje cu domeniul tău de apex în câmpul From și poate obține un pass DMARC. Măsurile de reducere sunt alinierea strictă, înregistrări DMARC explicite pe fiecare domeniu expeditor, control atent al delegării subdomeniilor și calificatorul ? pentru sursele permisive din înregistrarea SPF.

7. O verificare de 30 de minute pe care o poți face azi

# Politica ta DMARC
dig +short TXT _dmarc.domeniultau.md

# Înregistrarea ta SPF
dig +short TXT domeniultau.md | grep spf1

# Un selector DKIM, dacă îl știi
dig +short TXT selector._domainkey.domeniultau.md

Apoi răspunde la șase întrebări:

1. Înregistrarea conține pct, rf sau ri? Programează eliminarea lor.
2. Există o adresă rua și citește cineva efectiv rapoartele care ajung acolo? O adresă de raportare pe care nu o citește nimeni nu înseamnă monitorizare.
3. Toate domeniile de pe care trimiți au înregistrarea lor, inclusiv subdomeniile folosite de CRM, ticketing, facturare și platformele de marketing?
4. Domeniile parcate și cele de pe care nu trimiți publică p=reject; np=reject? Fără flux de mesaje nu există risc de interoperabilitate.
5. Dacă politica ta este p=reject, ai semnare DKIM pe fiecare flux de mesaje sau te bazezi pe SPF?
6. Când a citit cineva ultima dată un raport agregat și a acționat pe baza lui?

8. De ce contează asta specific în Moldova și România

Articolul 21(2) din NIS2 cere măsuri de management al riscului și igienă cibernetică de bază. Nu numește DMARC. Ce se întâmplă în practică este că evaluatorii tratează SPF, DKIM și DMARC drept implementarea tehnică acceptată pentru managementul riscului pe canalul de email. Publicarea unei înregistrări nu te face conform, iar absența ei este greu de apărat într-o evaluare. România: NIS2 transpusă prin OUG 155/2024, aprobată prin Legea 124/2025, în vigoare din 10 iulie 2025. Autoritatea competentă este DNSC. Ordinele 1 și 2/2025 (Monitorul Oficial nr. 776 din 20 august 2025) stabilesc procesul de înregistrare a entităților esențiale și importante. Moldova: Legea 48/2023 privind securitatea cibernetică în vigoare din 1 ianuarie 2025. Hotărârile Guvernului 860/2024 și 562/2025 identifică furnizorii din sectoarele critice și obligațiile lor. Date cu caracter personal: Legea 195/2024 intră în vigoare pe 23 august 2026. Falsificarea domeniului care duce la o plată frauduloasă este un incident cu dimensiune de protecție a datelor. Un detaliu local de verificat mai întâi: majoritatea companiilor din Moldova și România folosesc Google Workspace sau Microsoft 365 pentru poșta angajaților, apoi trimit tot restul din altă parte: softuri de facturare, panoul de control al hostingului, CRM, sisteme de rezervări. Domeniul din Workspace este de obicei autentificat corect. Celelalte patru sau cinci surse strică alinierea, și nimeni nu își amintește că există până când un client spune că factura nu a ajuns niciodată.

SECURITATE · SECURIZARE EMAIL

Poate cineva să trimită azi email în numele domeniului tău?

Configurare SPF, DKIM și DMARC aliniată la RFC 9989, audit al tuturor sistemelor care trimit mesaje în numele tău, monitorizarea rapoartelor agregate și un traseu etapizat către aplicare, fără să blocheze mesajele legitime. De la 400 EUR.

3 ZILE

LIVRARE COMPLETĂ

Securizează emailul →

Cum ajută echipa WebDirect

Majoritatea problemelor de autentificare email nu înseamnă o înregistrare DNS lipsă. Înseamnă cele patru sisteme uitate care trimit mesaje în numele tău, subdomeniul pe care nu l-a documentat nimeni și politica reject publicată fără DKIM în spate. Echipa WebDirect auditează întreaga suprafață de trimitere pentru companii din Moldova, România și UE, aduce înregistrările în linie cu specificația curentă și mută domeniile către aplicare într-un ritm care nu blochează facturile și resetările de parolă pe drum. Dacă vrei să știi cine poate trimite azi mesaje în numele domeniului tău, scrie-ne.

Surse

• RFC 9989, DMARC, IETF, mai 2026.
• RFC 9990, DMARC Aggregate Reporting, IETF, mai 2026.
• RFC 9991, DMARC Failure Reporting, IETF, mai 2026.
• Google, Email sender guidelines, support.google.com.
• Microsoft, Outlook's New Requirements for High Volume Senders, aprilie 2025.
• Directiva (UE) 2022/2555 (NIS2), articolul 21.
• România: OUG 155/2024, Legea 124/2025, Ordinele DNSC nr. 1 și 2/2025.
• Moldova: Legea 48/2023, Hotărârile Guvernului 860/2024 și 562/2025.
• Moldova: Legea 195/2024 privind protecția datelor cu caracter personal.

Acest material are caracter informativ și nu constituie consultanță juridică.

Întrebări frecvente

RFC 9989 înseamnă că trebuie să îmi rescriu înregistrarea DMARC?
Nu. Înregistrările încep în continuare cu v=DMARC1 și orice înregistrare validă aflată azi în producție continuă să funcționeze. Elimină tag-urile depreciate pct, rf și ri la următoarea modificare de DNS și asigură-te că publici înregistrări pe toate domeniile de pe care trimiți.Ce a înlocuit tag-ul pct?
Tag-ul t, modul de test al politicii DMARC. Publicarea lui t=y cere serverelor destinatare să aplice politica cu un nivel sub cea declarată: p=reject; t=y este tratat ca quarantine, iar p=quarantine; t=y este tratat ca none.Ce este DNS Tree Walk?
Mecanismul care a înlocuit Public Suffix List. Serverul destinatar interoghează _dmarc la domeniul tău expeditor, iar dacă nu găsește o înregistrare validă urcă în spațiul de nume câte o etichetă pe rând, până la opt interogări. Dacă trimiți dintr-un domeniu cu mai mult de opt etichete, publică o înregistrare exact la acel nume.Ar trebui să setăm p=reject?
Doar după ce semnarea DKIM funcționează pe fiecare flux de mesaje și după ce ai analizat rapoartele agregate. RFC 9989 descurajează p=reject pentru domeniile ai căror utilizatori postează pe liste de discuții. Domeniile parcate pot trece la reject imediat.Regulile Gmail și Outlook ni se aplică dacă trimitem doar câteva sute de mesaje pe zi?
Pragurile de 5.000 de mesaje pe zi definesc cine este obligat să se conformeze. Sub acest prag, autentificarea este oricum verificată și influențează plasarea în inbox. Cerințele sunt de tratat ca prag minim, nu ca plafon.DMARC ne face conformi cu NIS2?
Niciun control singular nu asigură conformitatea cu NIS2. Articolul 21 nu numește DMARC. În practică, autentificarea email este tratată drept implementarea acceptată pentru managementul riscului pe canalul de email.Cât costă un audit de securitate a emailului?
Email Security Hardening (configurare SPF, DKIM, DMARC, măsuri anti-phishing și audit al infrastructurii de email) pornește de la 400 EUR, livrat în 3 zile lucrătoare.