SPF: cine are dreptul să trimită
RFC 7208 pornește de la o constatare: nimic din protocolul de e-mail nu împiedică un server să anunțe orice adresă de expediere. SPF permite proprietarului unui domeniu să publice în DNS lista serverelor autorizate să trimită în numele său, iar serverului care primește să verifice această autorizare.
Două precizări schimbă totul:
- SPF verifică adresa de plic (cea din dialogul dintre servere, numită „MAIL FROM”) și numele anunțat de server, nu adresa pe care destinatarul o citește în „De la”.
- SPF judecă ultimul server care a predat mesajul. Când un mesaj este redirecționat de un alt server, cel care îl predă nu mai este un server autorizat de domeniul de origine: verificarea poate eșua deși mesajul este legitim.
Un domeniu publică o singură înregistrare SPF. Toate sursele de trimitere figurează în ea: serviciul de e-mail, programul de facturare, instrumentul de newsletter, CRM-ul, copiatorul care scanează către e-mail.
DKIM: mesajul este semnat
Potrivit RFC 6376, DKIM permite proprietarului unui domeniu semnatar să își asume o parte din responsabilitatea pentru un mesaj, prin intermediul unei semnături criptografice. Cheia publică se află în DNS. Verificarea semnăturii stabilește că părțile semnate nu s-au schimbat de la semnare.
Semnătura călătorește împreună cu mesajul. Prin urmare, rezistă mai bine decât SPF la un releu sau la o redirecționare, atâta timp cât releul nu modifică subiectul sau corpul mesajului. O listă de distribuție care adaugă o mențiune în josul mesajului o invalidează.
Ce nu face DKIM, potrivit aceluiași RFC: nu criptează mesajul, un eșec nu impune respingerea lui, iar domeniul care semnează nu trebuie să fie cel afișat în „De la”. Aceasta este exact lacuna pe care o acoperă DMARC.
DMARC: alinierea și politica
RFC 7489 definește DMARC ca un mijloc prin care proprietarul unui domeniu poate exprima o politică la nivelul domeniului. Mecanismul se bazează pe aliniere: domeniul adresei afișate în „De la” trebuie să corespundă domeniului validat de SPF sau de DKIM. Dacă niciunul dintre ele nu este aliniat, DMARC eșuează.
Domeniul publică atunci ceea ce dorește:
- none: nicio acțiune cerută, doar observare;
- quarantine: mesajul este tratat ca suspect;
- reject: mesajul este respins.
DMARC prevede și rapoarte: rapoarte agregate, care rezumă ce servere au trimis în numele domeniului și cu ce rezultat, și rapoarte de eșec, mesaj cu mesaj. Ele sunt cele care permit descoperirea unui instrument uitat care trimite în numele dumneavoastră sau a cuiva care vă uzurpă domeniul.
| Mecanism | Ce verifică | Ce nu analizează |
|---|
| SPF | Serverul care predă mesajul este autorizat pentru domeniul de plic | Adresa afișată, conținutul |
| DKIM | Mesajul semnat nu a fost modificat; un domeniu își asumă responsabilitatea | Adresa afișată, onestitatea conținutului |
| DMARC | Domeniul afișat este aliniat cu SPF sau DKIM; politica în caz de eșec | Domeniile asemănătoare, numele afișat, textul |
Blochează DMARC phishingul?
Blochează o parte din uzurparea domeniului, nu phishingul în general. RFC 7489 o spune explicit: DMARC nu tratează numele de domeniu asemănătoare vizual, nici abuzul de nume afișat, iar analiza conținutului iese din perimetrul său. Nu încearcă să rezolve toate problemele e-mailurilor frauduloase.
Concret, DMARC nu vede:
- un domeniu asemănător: fraudațul își autentifică perfect propriul domeniu, care seamănă cu al dumneavoastră;
- un nume afișat uzurpat: „Departamentul de contabilitate”, scris de la o adresă fără nicio legătură;
- un cont compromis care semnează corect, deoarece serverul real este cel care trimite;
- un mesaj fără legătură cu domeniul dumneavoastră: o alertă falsă de la un transportator sosește de la un domeniu care nu are nimic de-a face cu al dumneavoastră;
- un domeniu fără politică: dacă domeniul imitat publică „none”, destinatarul nu are nicio instrucțiune de respingere.
Aceste cazuri țin de alte analize: asemănarea domeniilor, reputația, conținutul, comportamentul. Vedeți spam, phishing, malware și cont compromis.
Redirecționări și liste de distribuție: ARC
O redirecționare invalidează adesea SPF, o listă care modifică mesajul invalidează DKIM, iar DMARC eșuează atunci pentru un mesaj legitim. ARC, descris în RFC 8617 (statut experimental), permite fiecărui intermediar să ateste rezultatul autentificării pe care l-a constatat. Serverul final poate alege să țină cont de el.
Protejarea propriului domeniu, filtrarea a ceea ce sosește
Sunt două subiecte care se confundă adesea.
- Protejarea domeniului care trimite: publicarea SPF, DKIM și DMARC pentru domeniul dumneavoastră, astfel încât ceilalți să poată refuza mesajele care îl uzurpă. Dumneavoastră publicați; destinatarii aplică.
- Filtrarea a ceea ce sosește: verificarea înregistrărilor celorlalte domenii pentru e-mailurile pe care le primiți, apoi aplicarea tuturor celorlalte analize.
Implementare treptată
- Inventarul a tot ce trimite în numele domeniului.
- O singură înregistrare SPF care le autorizează; o semnătură DKIM pentru fiecare serviciu capabil să semneze.
- DMARC în „none”, cu o adresă de primire a rapoartelor.
- Citirea rapoartelor timp de mai multe săptămâni; corectarea surselor uitate.
- Trecerea la „quarantine”, apoi la „reject” atunci când toate trimiterile legitime sunt aliniate.
Exemplu, cu titlu ilustrativ. Un cabinet publică DMARC în „none” și își citește primele rapoarte. Descoperă trei surse: serviciul său de e-mail, bine aliniat; programul de facturare, care trimite facturile cu domeniul cabinetului fără semnătură DKIM; și un server necunoscut din străinătate care trimite sute de mesaje în numele său. Corectează programul de facturare, așteaptă un ciclu de rapoarte curat, apoi trece la „quarantine”: destinatarii care aplică DMARC tratează de acum mesajele serverului necunoscut ca suspecte.
În ziua în care schimbați serviciul de e-mail, aceste înregistrări se pregătesc înainte de schimbarea MX. Ghidul migrarea unui serviciu de e-mail fără întreruperi descrie acest moment; nu îl reluăm aici.
Întrebări frecvente
Protejează o politică DMARC „none”?
Nu. Permite observarea datorită rapoartelor. Protecția începe cu „quarantine” sau „reject”.
De ce eșuează un mesaj legitim la DMARC?
Cel mai adesea: o redirecționare, o listă de distribuție sau un serviciu care trimite în numele dumneavoastră fără a fi declarat în SPF și fără a semna DKIM.
Serviciul nostru de e-mail nu semnează DKIM: ce putem face?
O poartă plasată pe traseul trimiterilor poate semna în locul lui. Vedeți Protejarea serviciului de e-mail pe care îl aveți deja.
Unde se citește rezultatul acestor controale pentru un mesaj primit?
În antetele mesajului. Pentru Klytic MTA, vedeți Citirea și exportul unei decizii a filtrului.
Unde se situează Klytic
Klytic MTA tratează ambele subiecte, în fața oricărui serviciu de e-mail:
- Essential și Advanced: verificare SPF, DKIM și MX; verificare DMARC, inclusiv pentru mesajele redirecționate, datorită ARC; semnarea DKIM a trimiterilor, chiar dacă serviciul dumneavoastră de e-mail nu o face.
- Advanced: consolă DMARC, cu rapoartele domeniilor dumneavoastră, alerte și soluții de corectare, pentru a gestiona trecerea treptată la „reject”.
DMARC este doar un strat: Klytic MTA adaugă detectarea domeniilor-clonă, a numelui afișat și a scenariilor de fraudă, descrisă în uzurparea identității și frauda de tip CEO.
Dacă folosiți Klytic Mail, SPF, DKIM și DMARC sunt configurate pentru domeniul dumneavoastră: aceasta este protecția domeniului care trimite. Klytic MTA, în schimb, se poate contracta cu sau fără Klytic Mail.
Surse
Consultate în octombrie 2026.
- RFC 7208, SPF: proprietarul unui domeniu publică gazdele autorizate să folosească domeniul său în identitatea „MAIL FROM” sau „HELO”, iar receptorul verifică această autorizare. rfc-editor.org
- RFC 6376, DKIM: un domeniu își asumă responsabilitatea pentru un mesaj printr-o semnătură criptografică; fără criptare, fără respingere impusă, domeniul semnatar poate fi distinct de autorul afișat. rfc-editor.org
- RFC 7489, DMARC: alinierea domeniului din „From” cu SPF sau DKIM, politicile none, quarantine și reject, rapoarte agregate și de eșec; domeniile asemănătoare vizual, numele afișat și analiza conținutului în afara perimetrului. rfc-editor.org
- RFC 9989 (mai 2026), care înlocuiește RFC 7489: aceleași valori de politică și aceleași excluderi (domenii asemănătoare, nume afișat). rfc-editor.org
- RFC 8617, ARC (experimental): lanț de transmitere autentificat; un receptor DMARC poate accepta evaluările purtate de un lanț ARC valid. rfc-editor.org
- Klytic, pagina Klytic MTA: controale de autentificare, semnarea DKIM a trimiterilor și consola DMARC din ofertele Essential și Advanced, opțiuni, moduri de implementare, punere în funcțiune prin MX. klytic.com
