SPF, DKIM, DMARC: ce sunt și de ce mailurile ajung în spam fără ele

SPF, DKIM și DMARC sunt trei înregistrări DNS care, împreună, permit serverelor de email să verifice că un mesaj trimis în numele unui domeniu este legitim. Fără ele, orice server poate pretinde că trimite email de pe domeniul tău, iar filtrele anti-spam ale marilor provideri nu au bază tehnică să distingă mesajul tău de un mesaj de phishing.

Cele trei standarde au apărut pe rând (SPF în 2003, DKIM în 2004, DMARC în 2012) și se completează: SPF declară cine are voie să trimită, DKIM semnează criptografic conținutul, DMARC leagă cele două cu header-ul From vizibil și generează rapoarte de abuz. Configurarea celor trei este relevantă pentru orice proiect cu email tranzacțional sau newsletter, de la notificări automate ale unei aplicații la funneluri de marketing, domenii în care crawlerra livrează ca serviciu dedicat (S06 și S07 din catalogul nostru).

Ce este SPF (Sender Policy Framework) și ce problemă rezolvă?

SPF este o înregistrare de tip TXT în DNS care listează IP-urile și hostname-urile autorizate să trimită email pentru un domeniu. Când serverul receptor primește un mesaj, extrage domeniul din envelope sender (câmpul tehnic MAIL FROM) și face un query DNS pentru înregistrarea SPF. Dacă IP-ul expeditorului nu apare în lista autorizată, serverul poate respinge sau filtra mesajul.

• Mecanisme principale: ip4: și ip6: pentru IP-uri directe, include: pentru a moșteni lista unui furnizor (SES, SendGrid, Postmark), mx pentru a autoriza serverele MX proprii.
• Qualifier final: ~all (softfail) sau -all (hardfail). Absența unui qualifier sau +all anulează protecția.
• Limita de 10 lookup-uri DNS: mecanismele include, a, mx și redirect fac fiecare câte un query DNS. Al 11-lea produce permerror, pe care mulți receiveri îl tratează ca eșec de autentificare.

SPF are o limită structurală importantă: nu protejează header-ul From vizibil, pe care îl vede destinatarul. Verifică numai MAIL FROM (envelope sender). Un atacator poate trece SPF cu un alt domeniu tehnic și tot afișa altceva în From. Asta e problema pe care o rezolvă DMARC prin alignment.

Ce este DKIM (DomainKeys Identified Mail) și cum funcționează semnătura?

DKIM adaugă o semnătură criptografică în headerele fiecărui mesaj. Serverul expeditor deține o cheie privată și semnează un subset de câmpuri din mesaj (From, Subject, corp etc.) producând un hash. Semnătura apare în headerul DKIM-Signature. Cheia publică este publicată în DNS ca înregistrare TXT sub subdomenul selector._domainkey.domeniu.com.

Când serverul receptor primește mesajul, citește headerul DKIM-Signature, extrage selectorul și face un query DNS pentru cheia publică. Dacă orice câmp declarat în h= a fost modificat în tranzit, verificarea eșuează. Selectorul permite rotația cheilor fără întrerupere: publici cheia nouă cu un selector diferit, actualizezi configurația serverului de trimitere și ștergi vechiul record abia după ce mesajele în tranzit au trecut.

Ce este DMARC și cum leagă SPF cu DKIM?

DMARC (Domain-based Message Authentication, Reporting and Conformance) este înregistrarea TXT de la _dmarc.domeniu.com care declară ce să facă serverul receptor dacă SPF și DKIM eșuează alignment, și unde să trimită rapoarte de abuz.

Conceptul cheie este alignment: DMARC nu verifică doar dacă SPF a trecut sau semnătura DKIM e validă, ci dacă domeniul din acele verificări se aliniază cu domeniul din header-ul From vizibil. Asta e greu de falsificat de un atacator.

• p=none: observă și raportează, nu respinge niciun mesaj. Pasul de start obligatoriu.
• p=quarantine: mesajele care eșuează alignment merg în Junk/Spam.
• p=reject: mesajele care eșuează sunt respinse la nivel SMTP. Protecție maximă, dar necesită că toate fluxurile de trimitere legitimă trec alignment.
• rua=: adresa la care receiverii trimit rapoarte agregate zilnice XML. Esențial pentru a vedea cine mai trimite în numele tău.

Cele două mecanisme se completează: alignment SPF sau alignment DKIM este suficient pentru ca DMARC să treacă. Asta înseamnă că forwarding-ul, care rupe SPF (IP-ul schimbat), este salvat de o DKIM corect configurată.

Cum verifici că sunt configurate corect (mxtoolbox, dig, mail-tester)?

Configurarea produce efecte verificabile direct din linia de comandă sau din tooluri web. Verificarea periodică este mai relevantă decât cea inițială: înregistrările se strică discret la migrări de furnizor sau la adăugarea unui flux de email nou.

• SPF: dig TXT domeniu.com sau MXToolbox SPF Lookup afișează înregistrarea și numărul de lookup-uri DNS consumate. Trimite un email de test la check-auth@verifier.port25.com pentru un raport automat complet.
• DKIM: dig TXT selector._domainkey.domeniu.com trebuie să returneze o înregistrare cu p= (cheia publică). Mail-tester.com afișează scorul complet și alignment-ul DKIM pe mesajul de test.
• DMARC: dig TXT _dmarc.domeniu.com arată policy curentă. Rapoartele agregate XML vin la adresa rua=; un tool ca dmarcian sau MXToolbox DMARC le parsează și afișează sursele care trimit în numele domeniului, inclusiv fluxuri necunoscute.

Verificarea celor trei o dată pe trimestru și după orice migrare de furnizor face parte din aceeași practică de observabilitate activă. Un inbox care nu primește rapoarte DMARC de câteva luni înseamnă că adresa rua= e greșită, nu că totul e în regulă. Monitorizarea livrabilității se comportă ca orice alertă dintr-un runbook de operațiuni.

Care sunt capcanele frecvente la migrare de furnizor email?

• Furnizorul vechi rămâne în SPF. La migrare, noul furnizor este adăugat în SPF, dar cel vechi nu e eliminat imediat. Fiecare include: rămas consumă din limita de 10 lookup-uri și poate provoca permerror pe domenii cu SPF complexe.
• Selectorul DKIM nu e reconfigurat pe noul furnizor. Furnizorul nou are propriul selector și cheie. Dacă nu publici înregistrarea TXT pentru noul selector, DKIM eșuează și DMARC pierde un mecanism de alignment. Majoritatea furnizorilor afișează explicit pasul de publicare DNS înainte de primul email trimis.
• DMARC policy reject activată prea devreme. La migrare există aproape întotdeauna fluxuri de trimitere necunoscute: un CRM configurat de altcineva, un serviciu de ticketing, o platformă de marketing. Cu p=reject activ, toate mesajele din aceste surse sunt respinse silențios. Faza p=none cu rapoarte active detectează sursele necunoscute înainte să le blochezi.
• Uitarea subdomeniilor. Un subdomeniu care trimite email (ex. notifications.domeniu.com) are nevoie de propriile înregistrări SPF și DKIM, și de o politică DMARC proprie sau moștenită prin directiva sp=. DMARC al domeniului rădăcină nu acoperă automat subdomeniile.
• Forwarding-ul rupe SPF și nu e compensat de DKIM. Utilizatorii care fac forward la altă adresă schimbă IP-ul de livrare, rupând verificarea SPF. Dacă DKIM nu acoperă câmpurile critice sau nu e configurată, DMARC eșuează pe mesajele forwardate.

Capcanele de mai sus apar la orice migrare, indiferent de furnizor. Ele interacționează și cu limitele de trimitere pe care furnizorii de email tranzacțional le impun, mai ales că depășirea lor poate duce la suspendarea contului fără avertisment; despre cum funcționează aceste limite dinspre server, citește intrarea despre rate limiting. Dacă ești la începutul unui proiect cu email tranzacțional, perspectiva de la nivel de arhitectură despre ce înseamnă autentificarea utilizatorilor cu tokenuri proprii o găsești în intrarea despre JWT, iar pentru hreflang și localizare corectă când emailurile includ linkuri internaționale, vezi intrarea despre hreflang.