Nu-ți mai ghici DNS-ul: un tur prietenos pentru dezvoltatori prin MX, SPF, DKIM și DMARC

De ce contează acum înregistrările DNS pentru e-mail

Autentificarea e-mailului era cândva opțională. În 2026, este o condiție de bază. Gmail și Outlook aplică ambele SPF și DKIM pentru expeditorii de volum, iar DMARC devine rapid obligatoriu pentru orice domeniu care trimite e-mail tranzacțional. Dacă înregistrările tale DNS sunt greșite, e-mailurile tale nu ajung—fără bounce, fără avertisment, doar tăcere.

Problema este că aceste înregistrări sunt documentate ca RFC-uri, nu ca instrumente. Majoritatea dezvoltatorilor copiază exemple din ghidul de configurare al furnizorului de e-mail și speră că totul va merge bine. Asta funcționează până când trebuie să depanezi, să adaugi un al doilea serviciu de trimitere sau să explici unui client de ce e-mailurile din formularul lui de contact ajung în spam.

Acest ghid parcurge MX, SPF, DKIM și DMARC în ordinea în care le vei întâlni de fapt, cu suficiente detalii ca să le configurezi corect și suficient context ca să le poți depana când se strică.

Înregistrări MX: unde ajunge e-mailul primit

Înregistrările MX spun internetului ce servere de mail acceptă e-mail pentru domeniul tău. Sunt cele mai simple dintre cele patru, dar și cele mai ușor de configurat greșit.

O înregistrare MX are două părți: un număr de prioritate și un hostname. Numerele de prioritate mai mici sunt încercate primele. Dacă folosești Google Workspace, înregistrările tale MX ar putea arăta așa:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Punctele finale contează—ele semnalează că hostname-ul este complet calificat. Majoritatea furnizorilor DNS le adaugă automat, dar nu toți.

Greșeli comune: să direcționezi înregistrările MX către o înregistrare A în loc de un hostname, să setezi toate prioritățile la același număr (ceea ce anulează scopul serverelor de rezervă) sau să uiți să elimini înregistrările MX vechi când migrezi între furnizori. Înregistrările MX rămase nu stau acolo inofensiv—pot cauza bucle de mail sau livrare împărțită între două inboxuri.

Dacă rulezi propriul formular de contact și vrei să eviți spamul fără să depinzi de servicii terțe, înțelegerea modului în care formularele devin vectori de spam este un punct de pornire util.

SPF: ce servere au voie să trimită în numele tău

SPF (Sender Policy Framework) este o înregistrare TXT care listează adresele IP și domeniile autorizate să trimită e-mail în numele domeniului tău. Este prima verificare pe care o fac majoritatea serverelor de mail când primesc un mesaj care pretinde că vine de la tine.

O înregistrare SPF de bază arată așa:

v=spf1 include:_spf.google.com ~all

Pe scurt:

• v=spf1 declară versiunea SPF
• include:_spf.google.com deleagă către înregistrarea SPF a Google
• ~all este un soft fail—respinge mailul din surse nelistate, dar nu fi prea strict

Poți folosi și ip4: sau ip6: pentru a permite explicit anumite adrese, ori a și mx pentru a referi înregistrările A și MX ale domeniului tău. Mecanismul all de la final controlează ce se întâmplă cu mailul din surse pe care nu le-ai listat: -all este un hard fail (respinge), ~all este soft fail (marchează ca suspect), ?all este neutru (fără opinie), iar +all este acces liber pentru oricine (nu folosi asta).

SPF are două muchii ascuțite. Prima: se strică atunci când e-mailul este redirecționat, deoarece serverul de redirecționare nu este în înregistrarea ta SPF. A doua: înregistrările SPF au o limită de zece interogări DNS. Dacă incluzi prea multe servicii terțe, vei depăși limita și SPF nu va mai funcționa. Soluția este să aplatizezi înregistrarea SPF—să înlocuiești directivele include: cu intervalele IP reale—dar asta necesită întreținere atunci când furnizorii își schimbă IP-urile.

DKIM: dovadă criptografică a identității expeditorului

DKIM (DomainKeys Identified Mail) adaugă o semnătură digitală e-mailului tău trimis. Serverul destinatar verifică semnătura folosind o cheie publică publicată în DNS-ul tău. Dacă semnătura este validă și mesajul nu a fost modificat, DKIM trece.

Spre deosebire de SPF, DKIM supraviețuiește redirecționării, deoarece semnătura călătorește împreună cu mesajul. Este și mai flexibil—poți avea mai multe chei DKIM pentru servicii de trimitere diferite, fiecare cu propriul selector.

O înregistrare DNS DKIM arată așa:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Selectorul (default în acest exemplu) este arbitrar—furnizorul tău de e-mail îl alege. Valoarea p= este cheia publică, de obicei un șir lung codificat base64. Furnizorul tău de e-mail generează cheia privată și o folosește pentru a semna mesajele trimise.

Configurarea DKIM este aproape întotdeauna gestionată de furnizorul tău de e-mail. Rolul tău este să copiezi înregistrarea TXT pe care ți-o oferă și să o lipești în DNS-ul tău. Partea dificilă este că unii furnizori DNS nu gestionează bine înregistrările TXT lungi—fie le trunchiază, fie îți cer să împarți valoarea în mai multe șiruri între ghilimele.

Ca să verifici că DKIM funcționează, trimite un e-mail de test către o adresă Gmail și verifică anteturile. Caută dkim=pass în antetul Authentication-Results.

DMARC: aplicarea politicii și raportare

DMARC (Domain-based Message Authentication, Reporting and Conformance) leagă SPF și DKIM și le spune serverelor destinatare ce să facă atunci când autentificarea eșuează. Activează și raportarea, astfel încât să poți vedea cine trimite e-mail ca domeniul tău—atât legitim, cât și falsificat.

O înregistrare DMARC minimală arată așa:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none înseamnă doar monitorizare—nu respinge și nu pune în carantină mesajele eșuate
• rua=mailto:[email protected] specifică unde să fie trimise rapoartele agregate

După ce ești sigur că SPF și DKIM funcționează, poți înăspri politica la p=quarantine (trimite eșecurile în spam) sau p=reject (respinge-le direct). Poți seta și o politică pentru subdomenii cu sp= și poți specifica procentul de mesaje cărora să li se aplice politica folosind pct=.

Rapoartele DMARC sunt fișiere XML trimise zilnic de destinatarii majori. Sunt verbose și greu de citit în formă brută, dar îți spun exact ce mesaje au trecut sau au eșuat autentificarea și de ce. Dacă vezi mail legitim respins, rapoartele îți vor arăta ce verificare SPF sau DKIM eșuează.

Un detaliu important: DMARC cere aliniere. Pentru SPF, domeniul din antetul Return-Path trebuie să corespundă domeniului din antetul From (sau să fie un subdomeniu). Pentru DKIM, domeniul d= din semnătura DKIM trebuie să corespundă domeniului From. Dacă folosești un serviciu terț de trimitere, acesta trebuie să suporte return paths personalizate sau semnare DKIM cu domeniul tău, nu cu al lor.

Cum să auditezi configurarea curentă

Majoritatea problemelor DNS sunt invizibile până când provoacă o problemă. Iată cum să-ți verifici înregistrările înainte să se strice ceva:

1. Interoghează înregistrările MX: dig MX example.com ar trebui să returneze hostname-urile serverelor tale de mail și prioritățile. Verifică dacă se potrivesc cu documentația furnizorului tău de e-mail.

1. Verifică sintaxa SPF: dig TXT example.com și caută înregistrarea v=spf1. Ruleaz-o printr-un validator SPF pentru a prinde erori de sintaxă și încălcări ale limitei de interogări.

1. Verifică cheile DKIM: Trimite un e-mail de test și inspectează antetul DKIM-Signature. Extrage selectorul și domeniul, apoi interoghează dig TXT selector._domainkey.example.com ca să confirmi că există cheia publică.

1. Validează politica DMARC: dig TXT _dmarc.example.com ar trebui să returneze înregistrarea ta DMARC. Asigură-te că rua= indică o adresă pe care chiar o monitorizezi.

1. Testează cap-coadă: Folosește un serviciu precum mail-tester.com sau trimite către o adresă Gmail și verifică anteturile complete. Caută spf=pass, dkim=pass și dmarc=pass în antetul Authentication-Results.

Dacă depanezi de ce e-mailurile nu ajung, anteturile sunt cel mai bun instrument. Majoritatea clienților de mail îți permit să vezi anteturile brute—în Gmail, deschide mesajul, fă clic pe cele trei puncte și selectează „Afișează originalul”. Antetul Authentication-Results îți va spune exact ce verificare a eșuat și de ce.

Când să folosești politici pentru subdomenii

Dacă trimiți e-mail din mai multe subdomenii—să spunem newsletter.example.com pentru marketing și app.example.com pentru mail tranzacțional—poți seta politici DMARC pe subdomeniu. Asta îți permite să aplici politici stricte pe subdomeniile pe care le controlezi, păstrând în același timp o politică mai relaxată pe domeniul principal.

Compromisul este complexitatea. Fiecare subdomeniu are nevoie de propriile înregistrări SPF, DKIM și DMARC, iar tu trebuie să urmărești ce servicii de trimitere sunt autorizate pentru ce subdomenii. Pentru majoritatea echipelor mici, un singur domeniu bine configurat este mai simplu și la fel de sigur.

Ce faci când autentificarea se strică

Cel mai comun mod de eșec este adăugarea unui nou serviciu de trimitere fără actualizarea DNS. Dacă începi să folosești un nou furnizor de e-mail tranzacțional, trebuie să adaugi include-ul SPF sau intervalul IP al acestuia, să configurezi semnarea DKIM cu domeniul tău și să verifici alinierea DMARC.

A doua cea mai frecventă problemă este redirecționarea. Dacă utilizatorii îți redirecționează e-mailul către altă adresă, SPF va eșua deoarece serverul de redirecționare nu este în înregistrarea ta SPF. DKIM supraviețuiește de obicei redirecționării, așa că, atâta timp cât DKIM trece și politica ta DMARC permite aliniere parțială, mesajul ar trebui totuși livrat. Dacă vezi mail redirecționat respins, verifică politica DMARC—p=reject cu aliniere strictă va strica redirecționarea.

A treia problemă este propagarea DNS. Modificările înregistrărilor DNS pot dura ore până se propagă, iar servere de mail diferite păstrează în cache înregistrările pentru perioade diferite. Dacă tocmai ai actualizat o înregistrare și nu funcționează, așteaptă câteva ore și testează din nou. Poți verifica propagarea cu un instrument precum whatsmydns.net.

Idei principale

• Înregistrările MX rutează mailul primit; SPF, DKIM și DMARC autentifică mailul trimis. Rezolvă probleme diferite și ai nevoie de toate patru.
• SPF se strică la redirecționare și are o limită de zece interogări. DKIM supraviețuiește redirecționării, dar necesită configurare pe serviciu. DMARC le leagă și activează raportarea.
• Începe cu p=none în DMARC, monitorizează rapoartele câteva săptămâni, apoi înăsprește la p=quarantine sau p=reject după ce ești sigur că mailul legitim trece.
• Erorile DNS sunt silențioase. Testează configurarea cu e-mail real și inspectează anteturile ca să confirmi că SPF, DKIM și DMARC trec.
• Dacă autentificarea se strică după adăugarea unui nou serviciu de trimitere, verifică include-urile SPF, selectorii DKIM și alinierea DMARC. Anteturile îți vor spune ce verificare a eșuat.

FAQ

Q: Pot avea mai multe înregistrări SPF?

A: Nu. Mai multe înregistrări SPF vor face ca toate să fie ignorate. Dacă trebuie să autorizezi mai multe servicii, folosește directive include: într-o singură înregistrare SPF sau listează direct intervalele IP. Ai grijă la limita de zece interogări.

Q: Am nevoie de DMARC dacă trimit doar câteva e-mailuri pe zi?

A: Da. DMARC nu ține de volum—ține de a demonstra că ești cine spui că ești. Chiar și domeniile mici beneficiază de DMARC, deoarece previne spoofingul și îți oferă vizibilitate asupra problemelor de livrare. Începe cu p=none și o adresă de raportare.

Q: Ce se întâmplă dacă DKIM și SPF eșuează ambele, dar e-mailul pare legitim?

A: Depinde de politica ta DMARC. Dacă p=none, mailul este livrat cu un avertisment. Dacă p=quarantine, ajunge în spam. Dacă p=reject, este respins. De aceea ar trebui să monitorizezi rapoartele DMARC înainte de a aplica o politică strictă—s-ar putea să ai expeditori legitimi despre care nu știai.

Q: Pot folosi aceeași cheie DKIM pentru mai multe domenii?

A: Tehnic, da, dar nu o face. Fiecare domeniu ar trebui să aibă propria pereche de chei DKIM. Partajarea cheilor îngreunează rotația și mărește raza de impact dacă o cheie privată este compromisă.

Q: Cât de des ar trebui să rotesc cheile DKIM?

A: Nu există o regulă universală, dar o dată pe an este rezonabil pentru majoritatea domeniilor. Dacă suspectezi că o cheie a fost compromisă, rotește-o imediat. Asigură-te că publici noua cheie publică în DNS înainte să începi să semnezi cu noua cheie privată și lasă vechea cheie în DNS câteva zile după rotație pentru a gestiona mailul întârziat.

<!-- tool-cta:start -->

💡 Încearcă asta: Inspectează politica publicată a oricărui domeniu cu DMARC Lookup pentru a vedea cum se potrivesc în practică înregistrările MX, SPF și DMARC.

<!-- tool-cta:end -->

Surse

• RFC 7208: Sender Policy Framework (SPF) — Specificația SPF, inclusiv regulile de sintaxă și limita de zece interogări.
• RFC 6376: DomainKeys Identified Mail (DKIM) — Specificația DKIM, care acoperă generarea și verificarea semnăturilor.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Specificația DMARC, inclusiv sintaxa politicilor și formatul raportării agregate.
• Google Workspace: Prevent spoofing and spam — Ghid practic pentru configurarea SPF, DKIM și DMARC pentru domenii Google Workspace.