Cum configurez DKIM pentru un domeniu de e-mail personalizat?

Cum funcționează DKIM?

DKIM îi permite serverului expeditor să semneze fiecare mesaj cu o cheie privată și permite oricărui receptor să verifice semnătura cu o cheie publică publicată în DNS. Semnătura stă într-un antet DKIM-Signature. Ea conține domeniul de semnare (d=), selectorul (s=), antetele semnate (h=), o sumă de control a corpului (bh=) și semnătura în sine (b=). RFC 6376, un standard de internet, definește aceste tag-uri.

Receptorul construiește numele DNS din selector și domeniu: selector._domainkey.domeniu. Pentru selectorul fm1 și domeniul example.com, cere fm1._domainkey.example.com. Răspunsul este o înregistrare cu tag-urile v=DKIM1, k=rsa și p= urmat de cheia publică în base64. Un p= gol înseamnă că cheia este revocată.

O semnătură validă dovedește două lucruri: mesajul a fost semnat de un sistem care deține cheia privată a domeniului, iar părțile semnate nu s-au modificat în tranzit. Nu spune că mesajul este dorit. Această judecată aparține DMARC, tratat în SPF vs DKIM vs DMARC.

De ce cer furnizorii înregistrări CNAME în loc de o cheie?

Un CNAME predă cheia furnizorului: cheia publică rămâne la adresa furnizorului, iar furnizorul o poate înlocui fără să îți ceară să editezi DNS-ul. Proton Mail, Fastmail și Mailbox.org folosesc toate acest model. Înregistrările lor sunt CNAME de la numele selectorului tău către o gazdă pe care o controlează, care deține înregistrarea cheii propriu-zise.

Beneficiul este rotația cheilor. RFC 6376 recomandă publicarea cheilor noi sub selectori noi, în loc de reutilizarea unui selector, iar Proton Mail publică trei selectori (protonmail, protonmail2, protonmail3), ceea ce îi dă furnizorului loc să treacă de la o cheie la următoarea. Costul pentru tine este încrederea: te bazezi pe faptul că gazda furnizorului continuă să răspundă.

Conform comparației Postelva din 12 noiembrie 2026, cei trei furnizori ale căror înregistrări DKIM au fost citite pe paginile lor de ajutor au nevoie de 3, 4 și 3 înregistrări CNAME, 10 în total, iar niciunul nu cere o cheie TXT.

Cât de lungă ar trebui să fie cheia DKIM?

Folosește o cheie RSA de 2048 de biți; 1024 de biți este minimul pe care RFC 6376 îl permite pentru chei de lungă durată. Standardul spune că semnatarii trebuie să folosească chei RSA de cel puțin 1024 de biți, iar verificatorii trebuie să poată verifica chei de la 512 la 2048 de biți. Ghidurile de expeditor ale Google cer cel puțin 1024 de biți și recomandă 2048. Când furnizorul creează cheia, ca în configurarea CNAME de mai sus, lungimea este alegerea lui, iar nimic nu rămâne să configurezi tu.

Când trebuie să alegi tu o dimensiune, alege 2048. O cheie de 2048 de biți este mai lungă decât un șir de 255 de caractere în DNS, deci valoarea TXT este împărțită în mai multe șiruri, lucru pe care majoritatea editorilor DNS îl fac singuri. Aceeași limită a editorului se aplică și înregistrării SPF descrise în cum creezi o înregistrare SPF.

Pot folosi mai mulți furnizori pe același domeniu?

Da: fiecare furnizor semnează cu propriul selector, deci înregistrările lor DKIM nu se ciocnesc. Motivul este selectorul. Proton folosește protonmail, protonmail2 și protonmail3; Fastmail folosește fm1, fm2 și fm3; Mailbox.org folosește MBO0001 până la MBO0004. Un instrument de newsletter care trimite în numele tău adaugă un selector propriu.

SPF este diferit: are o singură înregistrare pentru toți expeditorii, cu limita de 10 interogări. Când părăsești definitiv un furnizor, elimină înregistrările sale DKIM după ce ai confirmat că cel nou semnează, ca o cheie abandonată să nu poată fi folosită de cineva care câștigă acces la vechiul cont. Ordinea completă a unei migrări este în cum muți e-mailul la un furnizor nou fără să pierzi mesaje.

Cum verific că DKIM funcționează?

Caută selectorul cu dig și apoi trimite un mesaj real. Comanda dig CNAME fm1._domainkey.example.com +short ar trebui să afișeze ținta furnizorului. Pentru o cheie TXT, cere TXT. Testul decisiv este un mesaj: antetele copiei primite arată dacă serverul receptor a înregistrat dkim=pass.

Dacă înregistrarea este corectă și verificarea tot eșuează, cauzele obișnuite sunt un nume de gazdă greșit (domeniul adăugat de două ori de editorul DNS), un cache vechi sau un mesaj trimis înainte ca furnizorul să activeze semnarea. Următorul ghid, cum verifici înregistrările MX, SPF, DKIM și DMARC, enumeră comenzile. Pașii Fastmail complet sunt în ghidul domeniului personalizat Fastmail.