Salt la conținut

Setări cookie-uri

Alegeți pentru fiecare tip ce cookie-uri permiteți. Puteți modifica oricând alegerea prin Setări cookie-uri, în partea de jos a fiecărei pagini. Declarație de confidențialitate

Necesare

Mereu active

Necesare pentru autentificare, pentru păstrarea coșului și pentru a vă reține alegerile. Acestea sunt mereu active.

Ce cookie-uri?
  • weboke_sessie, weboke_klant, weboke_remember: sesiunea și menținerea autentificării
  • weboke_basket: coșul de cumpărături
  • wkBtwIncl: afișarea prețurilor cu sau fără TVA
  • wok_cookies: alegerea privind cookie-urile, 12 luni

Măsoară ce reclamă duce la o vizită sau o comandă, ca să nu plătim pentru reclame care nu aduc nimic.

Ce cookie-uri?
  • Google Ads prin Google Tag Manager (_gcl_au, _gcl_aw), până la 90 de zile
  • OpenAI Ads, reclame în ChatGPT
  • wok_aff: prin ce partener ați ajuns la noi (program de afiliere), 60 de zile

4,6

Țară și limbă

Fiecare țară are propriul site, cu prețurile și TVA-ul pentru țara respectivă.

Vedeți

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=1Versiunea DKIM
a=rsa-sha256Algoritm: cheie RSA, SHA-256. De asemenea posibil: ed25519-sha256
c=relaxed/relaxedCanonicalizare: 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.comDomeniul semnatar. Acest domeniu garantează pentru mesaj. DMARC compară acest domeniu cu adresa De la
s=xSelectorul: 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.

ExpeditorSelector (exemplu)Cum apare în DNS
Server de e-mail de hostingx sau defaultTXT cu cheia, creat de panou
Microsoft 365selector1, selector2două înregistrări CNAME către Microsoft
Google Workspacegoogle (implicit)TXT cu o cheie pe care o generați în consola de administrare
Serviciu de newsletterde exemplu k2, k3, mte1de 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:

  1. Creați o cheie nouă sub un selector nou, de exemplu s2026, și puneți cheia publică în DNS.
  2. Așteptați ca înregistrarea să fie vizibilă peste tot (TTL, vezi cursul de DNS, lecția 6.1).
  3. Lăsați serverul să semneze cu noul selector.
  4. 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.
  5. 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

  1. Trimiteți un mesaj din serviciu către o adresă la Gmail sau Outlook.com.
  2. Deschideți anteturile și căutați DKIM-Signature: notați d= și s=.
  3. Verificați în Authentication-Results dacă apare dkim=pass și dacă header.d= este domeniul dumneavoastră.
  4. Căutați selectorul: dig TXT s._domainkey.example.com (sau cu un instrument online). Trebuie să existe un p= 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-Signature găsiți d= (domeniu) și s= (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

1. Într-un DKIM-Signature apare d=mailer.example; s=k1, în timp ce adresa De la este info@example.com. Ce înseamnă aceasta pentru DMARC?



2. De ce folosesc servicii precum Microsoft 365 două înregistrări CNAME pentru DKIM?



3. După copierea unei chei DKIM în DNS-ul dumneavoastră, fiecare semnătură eșuează. Cheia din DNS are 255 de caractere. Care este cauza probabilă?



4. O listă de distribuție pune [membri] înaintea subiectului. Semnătura dumneavoastră a semnat subject. Ce se întâmplă cu DKIM-ul dumneavoastră la destinatarul final?



5. Care este ordinea sigură la înlocuirea unei chei DKIM?



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.

Exercițiul Z4.3: Verificarea unui selector DKIM

Preluați d= și s= din antetul DKIM-Signature al unui e-mail de pe propriul dumneavoastră domeniu (sau de la un serviciu care trimite în numele dumneavoastră).





Ceea ce completați și ceea ce găsim nu se salvează. Browserul dumneavoastră reține răspunsurile și dacă ați rezolvat exercițiul. Dacă sunteți autentificat, păstrăm în Cursurile mele doar faptul că exercițiul a fost (aproape) corect; și de acolo îl puteți șterge.

Lectură suplimentară

Pașii din aceste articole sunt valabili pentru panourile WebOké; la alți furnizori funcționează similar.

Un moment…

Configurați domeniile

Stabiliți pentru fiecare domeniu nameserverele, legătura cu hostingul și cine devine titularul.

Se încarcă domeniile…