Modulul 4 · 4.3
DKIM în practică: selectori, chei și servicii
Modulul 4: Livrabilitate: SPF, DKIM și DMARC în practică · Timp de citire: 12 minute
Obiectiv de învățare: După această lecție veți putea analiza un antet DKIM-Signature, veți configura DKIM cu propriul dumneavoastră domeniu pentru fiecare serviciu de trimitere, veți verifica dacă un selector funcționează și veți putea explica cum se înlocuiesc cheile în siguranță.
Concepte cheie: DKIM-Signature, d= (domeniul semnatar), s= (selector), h= (anteturile semnate), bh= și b=, canonicalizare (c=), <selector>._domainkey.<domeniu>, TXT cu p= sau CNAME către serviciu, lungimea cheii de 2048 de biți (RFC 8301), fragmente de 255 de caractere, ed25519 (RFC 8463), înlocuirea cheii, p= gol (revocat), DKIM și redirecționare
De ce DKIM este cel mai important dintre cele trei
SPF indică ce servere au voie să trimită mesaje, dar se întrerupe la redirecționare și se uită la Return-Path, care la multe servicii nu este al dumneavoastră. DKIM pune o semnătură chiar în mesaj. Această semnătură supraviețuiește redirecționării (atât timp cât mesajul nu este modificat) și este legată de un domeniu pe care îl alegeți dumneavoastră. De aceea, în practică, DKIM este adesea singurul lucru care face ca DMARC să treacă pentru newslettere, facturi dintr-un program de contabilitate și mesaje redirecționate.
Bazele (cum apare cheia în DNS, ce este un selector) se găsesc în cursul despre DNS, lecția 4.4. Aici mergem mai departe: ce conține exact o semnătură și cum configurați DKIM pentru fiecare serviciu?
Analizarea unei semnături
Deschideți anteturile unui mesaj pe care l-ați primit (lecția 1.5). În partea de sus, dacă mesajul este semnat, apare ceva de genul:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=x;
t=1762588800; h=from:to:subject:date:message-id:mime-version:content-type;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=Gm7yW3q...lange reeks tekens...Qx9A==| Etichetă | Semnificație |
|---|---|
v=1 | Versiunea DKIM |
a=rsa-sha256 | Algoritm: cheie RSA, SHA-256. De asemenea posibil: ed25519-sha256 |
c=relaxed/relaxed | Canonicalizare: cât de strict sunt tratate modificările mici (spații, majuscule în numele anteturilor), pentru anteturi și pentru text. relaxed este obișnuit și mai permisiv decât simple |
d=example.com | Domeniul semnatar. Acest domeniu garantează pentru mesaj. DMARC compară acest domeniu cu adresa De la |
s=x | Selectorul: ce cheie a domeniului respectiv a fost folosită |
t= | Momentul semnării (secunde de la 1970) |
h= | Ce anteturi sunt semnate. from trebuie să fie întotdeauna prezent |
bh= | O amprentă (hash) a textului mesajului |
b= | Semnătura propriu-zisă |
Destinatarul preia cheia publică de la <s>._domainkey.<d>, în acest caz deci x._domainkey.example.com, și verifică dacă b= se potrivește cu anteturile din h= și cu amprenta bh=. Dacă pe parcurs a fost modificată o singură literă în text sau într-un antet semnat, verificarea eșuează.
În Authentication-Results vedeți rezultatul, de exemplu dkim=pass header.d=example.com header.s=x. Un mesaj poate avea mai multe semnături, de exemplu una din domeniul dumneavoastră și una din partea serviciului în sine. Pentru DMARC contează doar o semnătură al cărei d= corespunde domeniului dumneavoastră De la.
Fiecare serviciu, propriul său selector
Un domeniu poate avea simultan multe chei DKIM, fiecare sub propriul selector. Acesta este chiar scopul: fiecare serviciu care trimite mesaje în numele dumneavoastră semnează cu propria cheie.
| Expeditor | Selector (exemplu) | Cum apare în DNS |
|---|---|---|
| Server de e-mail de hosting | x sau default | TXT cu cheia, creat de panou |
| Microsoft 365 | selector1, selector2 | două înregistrări CNAME către Microsoft |
| Google Workspace | google (implicit) | TXT cu o cheie pe care o generați în consola de administrare |
| Serviciu de newsletter | de exemplu k2, k3, mte1 | de regulă înregistrări CNAME către serviciu |
TXT sau CNAME?
- Cu o înregistrare TXT puneți dumneavoastră înșivă cheia publică în DNS-ul dumneavoastră. Dacă serviciul dorește o cheie nouă, trebuie să modificați dumneavoastră înregistrarea.
- Cu o înregistrare CNAME redirecționați selectorul către un nume de la serviciu, de exemplu
k2._domainkey.example.com CNAME dkim2.mailer.example.Serviciul administrează atunci singur cheia și o poate înlocui fără ca dumneavoastră să trebuiască să faceți ceva. De aceea serviciile mari aleg CNAME și folosesc deseori două: astfel pot comuta între o cheie activă și una nouă.
Atenție: un CNAME nu poate exista alături de o altă înregistrare la același nume. Dacă există deja un TXT la selector1._domainkey, eliminați-l.
Cel mai important: activarea DKIM la serviciu
La multe servicii, DKIM cu propriul dumneavoastră domeniu nu este activat implicit. Ele semnează atunci cu propriul lor domeniu (d=mailer.example). Mesajul este deci semnat, dar nu este aliniat cu adresa dumneavoastră De la. Pentru DMARC, acest lucru nu contează. În administrarea serviciului, acest lucru se numește adesea "verificare domeniu", "verificarea domeniului", "autentificare" sau "domeniu de expeditor propriu". Doar după ce ați setat înregistrările ȘI ați activat acest lucru în serviciu, acesta va semna cu d=example.com.
Chei: lungime, fragmente și algoritm
- Lungime. RFC 8301 prevede: cel puțin 1024 de biți, iar expeditorii ar trebui să folosească cel puțin 2048 de biți. Folosiți 2048. O cheie de 512 biți este considerată nevalidă de către destinatari.
- Fragmente de 255 de caractere. O înregistrare TXT este formată din șiruri de caractere de maximum 255 de caractere. O cheie de 2048 de biți are aproximativ 400 de caractere și nu încape într-un singur șir. Înregistrarea este atunci formată din două sau mai multe șiruri consecutive (
"v=DKIM1; k=rsa; p=MIIBIj..." "...IDAQAB"), pe care destinatarul le lipește împreună. Majoritatea panourilor fac acest lucru automat. Dacă ceva nu merge bine, obțineți o cheie trunchiată și fiecare semnătură eșuează. Copiați deci întotdeauna o cheie în întregime, fără spații suplimentare sau ghilimele la mijloc. - ed25519 (RFC 8463) este un algoritm mai modern cu chei scurte. Nu toți destinatarii îl verifică încă. Cine îl folosește semnează deci cu două semnături: una RSA și una ed25519.
Înlocuirea unei chei
Este bine să înlocuiți o cheie din când în când, și cu siguranță dacă bănuiți că cheia privată a fost compromisă (de exemplu după un atac asupra serverului sau plecarea unui administrator). Procedați astfel:
- Creați o cheie nouă sub un selector nou, de exemplu
s2026, și puneți cheia publică în DNS. - Așteptați ca înregistrarea să fie vizibilă peste tot (TTL, vezi cursul de DNS, lecția 6.1).
- Lăsați serverul să semneze cu noul selector.
- Lăsați vechea cheie să rămână câteva zile: mesajele care erau deja pe drum sau care sunt verificate din nou se referă încă la ea.
- Revocați vechea cheie golind
p=(v=DKIM1; p=), sau eliminați înregistrarea.
La serviciile cu înregistrări CNAME, serviciul face acest lucru singur.
Ce face ca DKIM să eșueze
- Mesajul este modificat pe parcurs: o listă de distribuție care pune
[numele listei]în subiect sau adaugă un subsol, un scaner de viruși care adaugă o linie sub mesaj, un server de redirecționare care transformă formatarea. - Cheie greșită sau trunchiată în DNS.
- Selectorul nu există: o greșeală de tastare în nume, sau
selector1._domainkey.example.com.example.com(numele de domeniu dublat, deoarece panoul îl adaugă deja singur). - Cheie revocată (
p=gol) în timp ce serverul încă semnează cu acel selector.
Verificarea funcționării
- Trimiteți un mesaj din serviciu către o adresă la Gmail sau Outlook.com.
- Deschideți anteturile și căutați
DKIM-Signature: notațid=șis=. - Verificați în
Authentication-Resultsdacă aparedkim=passși dacăheader.d=este domeniul dumneavoastră. - Căutați selectorul:
dig TXT s._domainkey.example.com(sau cu un instrument online). Trebuie să existe unp=cu o cheie lungă, sau un CNAME care duce către o astfel de înregistrare.
În practică: cum arată într-un panou
La un pachet de hosting WebOké, DKIM este activat implicit, cu selectorul x: înregistrarea se numește x._domainkey.<domeniuldumneavoastră>. În DirectAdmin îl vedeți în DNS Administration; dacă DNS-ul dumneavoastră se află la un alt furnizor, copiați acea înregistrare acolo. În Contul meu WebOké, cardul Set E-mail arată ce valoare trebuie să existe și dacă aceasta este găsită. La alți furnizori selectorul se numește diferit (default, mail, dkim), dar îl găsiți în același mod: în panou sau în s= al unui mesaj semnat.
Rezumat
- DKIM este verificarea care supraviețuiește redirecționării și pe care o legați, per serviciu, de propriul dumneavoastră domeniu; pentru DMARC contează doar o semnătură cu domeniul dumneavoastră în
d=. - În
DKIM-Signaturegăsițid=(domeniu) șis=(selector); cheia se află la<s>._domainkey.<d>. - Fiecare serviciu primește propriul selector; înregistrările CNAME permit serviciului să înlocuiască singur cheile. Activați efectiv DKIM cu propriul dumneavoastră domeniu în serviciu.
- Folosiți 2048 de biți; atenție la cheile trunchiate la copiere.
- Înlocuiți o cheie cu un selector nou și revocați-o pe cea veche abia după aceea.
Quiz
Exercițiu
Exercițiu Z4.3: Verificarea unui selector DKIM. Trimiteți un mesaj din propriul dumneavoastră domeniu (sau dintr-un serviciu care trimite în numele dumneavoastră) către o adresă proprie la un alt furnizor. Deschideți anteturile și completați valorile d= și s= din DKIM-Signature, precum și ce apare la dkim= în Authentication-Results. Programul caută selectorul în timp real, urmărește un eventual CNAME, verifică cheia (prezență, dacă nu este goală, lungime) și vă spune dacă d= este aliniat cu domeniul pe care îl indicați ca expeditor.
Lectură suplimentară
Pașii din aceste articole sunt valabili pentru panourile WebOké; la alți furnizori funcționează similar.
- Curs gratuit de DNS 4.4: DKIM: semnătura sub e-mailul dumneavoastră
- Manual DirectAdmin 5.8: Activarea și verificarea DKIM
- Configurarea DKIM când DNS-ul este găzduit pe un server extern
- Manual WebOké 6.7: Caseta Configurați e-mailul (MX, SPF, DKIM, DMARC)
- RFC 6376 (DKIM), RFC 8301 (lungimea cheii și algoritmi), RFC 8463 (ed25519)
