Cum să citești politica DMARC a unei companii în zece secunde (și ce NU ți-o spune)

O singură interogare DNS ți-o spune ce a cerut o companie serverelor de mail din lume să facă cu mailurile falsificate trimise în numele ei. Înregistrarea este publică, iar comanda este o singură linie: dig +short TXT _dmarc.example.com. Ceea ce se întoarce este un șir scurt de setări, iar în el se află o instrucțiune — p=none, p=quarantine sau p=reject — care exprimă preferința proprietarului domeniului atunci când un mesaj care folosește acel domeniu nu trece autentificarea.

Specificația curentă, RFC 9989, publicată în mai 2026 ca document IETF Standards Track, a înlocuit mai vechia RFC 7489. Ea definește cele trei valori aproape laconic:

• p=none — „Proprietarul domeniului nu și-a exprimat o preferință."
• p=quarantine — „Proprietarul domeniului consideră un astfel de mail ca fiind suspect. Este posibil ca mailul să fie valid, deși eșecul autentificării creează o preocupare semnificativă."
• p=reject — „Proprietarul domeniului consideră toate aceste eșecuri ca o indicație clară că utilizarea numelui domeniului nu este validă."

Citește din nou aceste cuvinte, pentru că sunt mai slabe decât admite majoritatea explicațiilor despre DMARC. O politică este o preferință, publicată de expeditor pentru a fi luată în considerare de receptori. Nu este o instrucțiune pe care receptorul este obligat s-o execute. RFC 9989 spune asta într-o singură propoziție: „Tratamentul final al oricărui mesaj este întotdeauna o chestiune de politică locală și este lăsat la dispoziția receptorului de mail." Aceeași secțiune adaugă ambele laturi ale consecinței — receptorii „POT alege să respingă sau să pună în carantină un mesaj chiar dacă trece verificarea DMARC", și ei „NU AR TREBUI să respingă mesajele doar din cauza unei politici publicate de 'reject'", tocmai pentru ca mailul legitim trimis în moduri pe care DMARC nu le poate descrie, și listele de corespondență, să nu fie distruse în proces.

Deci ce mărturisește de fapt p=none? Mai puțin decât se obișnuiește să fie acuzat. În termenii specului propriu, este Monitoring Mode: proprietarul domeniului colectează rapoarte agregate și „nu și-a exprimat o preferință de tratament pentru mesajele care eșuează validarea DMARC", în timp ce un receptor care implementează DMARC „poate în continuare" valida utilizarea domeniului. Ceea ce nu face este să dezactiveze ceva la capătul receptor. Filtrul de spam al furnizorului tău, scorul de reputație, verificările URL și analiza atașamentelor sunt mecanisme separate care se execută indiferent de ceea ce a publicat expeditorul. Un mesaj falsificat care soseşte la un domeniu p=none nu este promovat în inbox-ul tău de înregistrare; este pur și simplu transmis receptorului fără o preferință declarată, și receptorul decide.

Cealaltă jumătate a neînțelegerii merge pe direcția opusă. DMARC nu citește partea periculoasă a unui email de phishing. Propria sa specificație listează ceea ce este deliberat în afara domeniului de aplicare, și „content analysis" se găsește pe acea listă, în acele cuvinte. De asemenea, se precizează că DMARC „nu abordează utilizarea numelor de domenii vizual similare sau abuzul numelui de afișare lizibil pentru om din RFC5322.From" — cele două trucuri care transportă majoritatea mailului de imitație a mărcii. Și cu privire la valoarea unui pass: „un pass DMARC singur nu garantează că livrarea către inbox-ul destinatarului ar fi sigură sau de dorit." Un mesaj corect autentificat de la un domeniu de unică folosință trece DMARC curat. DMARC răspunde la cine a fost autorizat să utilizeze domeniul din antetul From:. Nimic mai mult.

Aici sunt regulile pentru expeditori în vrac din 2024 rutinieramente greșit raportate, inclusiv în versiunea inițială a acestui articol. Liniile directoare pentru expeditori ale Google cere expeditorilor care trimit 5.000 sau mai multe mesaje pe zi conturi Gmail să „configurezi autentificarea emailului DMARC pentru domeniul tău de trimitere", și apoi spun, în același suflu: „Politica ta de aplicare DMARC poate fi setată la none." Serverul propriu Sender Hub al Yahoo, care trebuie citit separat mai degrabă decât presupus că copiază Google, enunță cerința ca „Publică o politică DMARC validă cu cel puțin p=none - DMARC trebuie să treacă", și nu publică niciun prag de volum numeric. Ambele seturi de cerințe au intrat în vigoare din februarie 2024. Nici una nu forțează pe nimeni departe de p=none. Ceea ce ambele forțează de fapt este o autentificare care se aliniază: Google cere ca „domeniul din antetul From: al expeditorului trebuie să se alinieze cu fie domeniul SPF, fie cu domeniul DKIM", iar Yahoo spune că alinearea relaxată este acceptabilă. Alinearea, nu severitatea, este poarta.

Ceea ce lasă motivul real pentru care domeniile stau la monitoring, și el este operațional mai degrabă decât timid. Trecerea la quarantine sau reject înseamnă mai întâi găsirea fiecărui serviciu care trimite mail în numele tău — payroll, ticketing, marketing, un support desk pe care nimeni nu l-a documentat — și autentificarea fiecăruia pentru ca se alinieze. Standardul însuși recunoaște pericolele care fac această procedură lentă: expeditorii terți nu sunt nici introduși nici excluși de DMARC, forwarding-ul și listele de corespondență pot rupe alinearea fără vina expeditorului, și specul îi direcționează receptorii la RFC 7960 pentru aceste moduri de eșec. O organizație care publică p=none și citește rapoartele sale face munca în ordinea descrisă de spec. Una care publică p=none și ignoră rapoartele nu face asta. Din afară, înregistrarea doar nu ți-o poate spune care din cele două privești.

Nu ai nevoie de un terminal pentru a interoga. Instrumente gratuite de interogare — domain checker-ul dmarcian, verificarea DMARC a MXToolbox — preiau înregistrarea și tipăresc politica pentru tine. Fă asta pentru banca ta, furnizorul tău de payroll, linia aeriană cu care zboară. Citește doar răspunsul pentru ceea ce este: o declarație de intenție de către proprietarul domeniului, un input printre mulți în o decizie pe care furnizorul tău de mail o ia pe cont propriu, despre un anumit tip de falsificare. Acesta este un lucru cu adevărat util pe care poți să îl citești în zece secunde. Nu este un verdict cu privire la faptul că următorul mesaj care pretinde a fi de la acea marcă este sigur.

Corectare, 20 octombrie 2026. O versiune anterioară a acestui articol descria p=none ca livrând falsificări în inbox și p=reject ca singura setare care blochează un mesaj spoofed, spunea că regulile pentru expeditori în vrac ale Google și Yahoo din 2024 forțau expeditorii departe de p=none, și cita o cifră de aproximativ unu din trei domenii în aplicare. Descrierile politicii au fost corectate față de RFC 9989; Google și Yahoo de fapt acceptă p=none, citate mai sus din documentația lor proprie; și cifra de aplicare a fost eliminată pentru că raportul de bază nu publică eșantionul sau numitorul. Articolul enunță acum de asemenea ceea ce DMARC nu examinează.

@@END@@