DKIM eșuează după schimbarea instrumentelor de e-mail: Ghidul de migrare CNAME și selector (2026)

Publicat 2026-07-08

Date din 2026-06-29 · metodologie v7. Date agregate din recensământul a 261 milioane de domenii clasificate. Consultați cum clasificăm.

DKIM se strică după o schimbare de instrument din două motive mecanice: panoul DNS a denaturat țintele CNAME ale noului instrument — de obicei adăugând propria zonă — sau selectorii vechiului instrument au fost eliminați înainte ca e-mailul său să se dreneze. Doar 3.87% din domenii — 10,092,481 — completează triada SPF+DKIM+DMARC, conform recensământului Defaults.Exposed al 261,086,232 de domenii clasificate.

Ordinea reparării: scanați domeniul, apoi verificați ținta stocată a fiecărui CNAME nou cu dig — o țintă care se termină cu propriul domeniu este dovada clară. Reparați înregistrările la serverele DNS autoritare, confirmați că noul instrument semnează și trece înainte de a rutați e-mailul real prin el și păstrați selectorii vechiului instrument publicați până când traficul său se drenează.

De ce s-a stricat DKIM când ați schimbat instrumentele?

Nimic din DKIM în sine nu s-a schimbat — selectorii dvs. s-au schimbat. Vechiul instrument semna cu selectorii săi; cel nou semnează cu alții diferiți, de obicei delegați prin două sau trei înregistrări CNAME adăugate în timpul configurării. Patru capcane explică aproape fiecare eșec DKIM post-migrare:

Panoul DNS a adăugat zona la ținta CNAME. Multe panouri tratează orice nume de gazdă lipit ca relativ și stochează silențios target.provider.com.yourdomain.com în loc de target.provider.com. Înregistrarea există, panoul arată un bifă verde și se rezolvă la nimic.
Confuzia cu punctul final. Unele panouri cer un punct final (target.provider.com.) pentru a însemna „absolut — opriți adăugarea zonei mele”; altele resping punctul ca invalid și gestionează ei înșiși absolutivitatea. Aceeași valoare lipită este corectă într-un panou și denaturată în altul.
Selectorii vechiului instrument au fost șterși în ziua comutării. E-mailul pe care vechiul instrument l-a semnat deja se află în cozile de reîncercare și căile de redirecționare pentru zile; eliminarea selectorilor săi — sau închiderea vechiului cont, care omoară CNAMEs-urile sale delegate — strică acel e-mail retroactiv.
Ați verificat la serverele de nume greșite. Dacă migrarea a inclus o schimbare de server de nume, înregistrările corectate pot exista la un set NS în timp ce receptorii interogau în continuare celălalt.

Doar 51.84% din cele 261 milioane de domenii din recensământ prezintă o cheie DKIM descoperabilă la momentul scanării (date din 2026-06-29).

Aceeași migrare lasă de obicei și resturi SPF — 1,013,416 domenii, aproximativ 1 din 138 dintre cele care încearcă SPF, rulează două înregistrări v=spf1, semnul clasic că o schimbare de furnizor a adăugat o înregistrare în loc să o îmbine pe una existentă. Acea parte a mutării are propriul ghid: SPF a încetat să funcționeze după schimbarea furnizorului de e-mail.

Cum detectez o înregistrare CNAME denaturată?

Nu aveți încredere în panou — întrebați DNS ce a stocat de fapt. Interogați ținta CNAME pentru fiecare selector pe care noul instrument vi l-a dat. Un exemplu ilustrativ, imitând un selector delegat în stil SendGrid (forma țintei furnizorului dvs. va fi diferită):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

Furnizorul a cerut s1.domainkey.u1234567.wl123.sendgrid.net — dar ținta stocată se termină în .yourdomain.com. Panoul a adăugat zona; acel nume se rezolvă la nimic, deci receptorii nu găsesc nicio cheie. Versiunea sănătoasă:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Un singur punct final în output-ul dig este normal — marchează un nume complet calificat.) Dacă ținta este corectă, urmați-o un hop: dig TXT s1._domainkey.yourdomain.com +short ar trebui să returneze cheia furnizorului. Răspuns gol cu un CNAME corect înseamnă că problema este pe partea furnizorului a delegării — finalizați pasul lor de verificare sau consultați DKIM „no key for signature” pentru diagnosticul la nivel de selector.

Manualul de migrare: înainte, în timpul și după

Eșecul nu este de obicei înregistrările — este ordinea. Migrările DKIM merg prost la comutare deoarece verificarea are loc după comutare, când e-mailul real eșuează deja.

Faza	Ce să faceți	Poartă înainte de a continua
Înainte de comutare	Adăugați CNAMEs-urile DKIM ale noului instrument (și înregistrările de domeniu de bounce), apoi dovediți-le: `dig` fiecare țintă CNAME stocată din afara rețelei dvs., completați pasul de verificare propriu al instrumentului și trimiteți un test prin noul instrument la o căsuță poștală pe care o controlați	Mesajul de test arată `dkim=pass` cu `d=` = domeniul dvs. — nu rutați niciodată e-mailul real printr-un instrument neverificat
Ziua comutării	Mutați traficul real la noul instrument. Nu atingeți nimic aparținând vechiului instrument: lăsați selectorii, CNAMEs-urile și contul vii	E-mailul noului instrument trece la receptorii reali; vechiul instrument continuă să treacă pentru orice mai curge prin el
După drenaj	Urmăriți rapoartele agregate DMARC până când selectorii vechiului instrument nu mai apar (cozile de reîncercare și redirecționările rulează zile — permiteți o săptămână sau mai mult), apoi retrageți-i și contul	Selectorii vechi absenți din rapoarte ≥ 7 zile înainte de eliminare

Rândul îngroșat este locul unde migrările sunt salvate sau pierdute: fiecare verificare din el poate fi făcută cu zile înainte de comutare, fără niciun risc pentru e-mailul live. Mecanica retragerii selectorilor — inclusiv de ce re-publicarea cu un p= gol depășește ștergerea — este acoperită în manualul de rotație; acest tabel este despre secvențierea comutării instrumentului în sine.

Cum remediez DKIM după comutare?

Rulați scanarea gratuită la defaults.exposed înainte de a atinge DNS-ul. Citește înregistrările dvs. live și arată ce văd de fapt receptorii — inclusiv țintele CNAME care au primit zona adăugată și selectorii care nu se rezolvă.
Listați înregistrările DKIM pe care le așteaptă noul instrument. Din consola sa de administrare — pentru furnizorii de căsuțe poștale, ghidurile de configurare pentru Google Workspace și Microsoft 365 arată unde; instrumentele de newsletter și CRM listează CNAMEs-urile lor sub autentificarea domeniului (consultați e-mailuri Mailchimp/Brevo/Klaviyo care eșuează DMARC).
Verificați valoarea stocată a fiecărei înregistrări cu dig CNAME <name> +short și comparați caracter cu caracter cu ce a cerut instrumentul. O țintă care se termină în propriul domeniu = zona adăugată; re-introduceți-o și, dacă panoul continuă să adauge, adăugați punctul final (sau eliminați-l, dacă panoul respinge punctele).
Verificați la serverele DNS autoritare. dig +short NS yourdomain.com, apoi repetați verificările CNAME @<acel server de nume>. Dacă migrarea a schimbat serverele de nume, verificați ambele seturi — receptorii pot interoga în continuare cel vechi până când delegarea se propagă.
Re-rulați verificarea instrumentului și trimiteți un mesaj de test. Antetul Authentication-Results ar trebui să arate dkim=pass cu d= egal cu domeniul dvs. — un pass pe domeniul implicit al instrumentului nu se aliniază pentru DMARC.
Lăsați selectorii vechiului instrument publicați până când e-mailul său se drenează, apoi retrageți-i deliberat. Apoi re-scanați și parcurgeți orice altceva semnalat pe pagina corectați DKIM.

Întrebări frecvente

Am nevoie de punctul final pe CNAME-ul meu DKIM sau nu? Depinde în totalitate de panou. Punctul înseamnă „nume absolut — nu adăugați zona mea”; unele panouri îl cer, unele îl adaugă pentru dvs., unele îl resping. Singurul test care contează este output-ul dig CNAME <selector>._domainkey.yourdomain.com +short după salvare: dacă ținta se termină în propriul domeniu, panoul a adăugat zona și aveți nevoie de punct (sau un format de intrare diferit).

Pot șterge înregistrările DKIM ale vechiului instrument în ziua comutării? Nu. E-mailul pe care vechiul instrument l-a semnat se află în continuare în cozile de reîncercare și căile de redirecționare, iar ștergerea cheii la care pointează strică acele mesaje retroactiv. Păstrați selectorii vechi vii până când nu mai apar în rapoartele dvs. agregate DMARC — o săptămână sau mai mult — și nu închideți nici vechiul cont înainte de aceea.

Panoul DNS și noul instrument spun ambele „verificat”, dar receptorii tot eșuează DKIM. Cum? Două cazuri comune: instrumentul a verificat față de un check în cache în timp ce serverele DNS autoritare servesc altceva (interogați-le direct cu dig @<ns>), sau DKIM trece dar pe domeniul de semnare implicit al instrumentului mai degrabă decât al dvs., deci DMARC eșuează totuși alinierea. Scanarea distinge cele două.

Înregistrările DKIM ale ambelor instrumente pot coexista în timpul suprapunerii? Da — și ar trebui. DKIM nu are regula înregistrării unice: fiecare selector este propriul nume DNS, deci înregistrările ambelor instrumente trăiesc alături fără conflict, ceea ce face regula de a păstra selectorii vechi prin drenaj ușor de urmat. (SPF este opusul — două înregistrări v=spf1 îl anulează, de aceea ghidul de migrare SPF este despre îmbinare.)

Trimiteți proprietarului raportul

Dacă rulați această migrare pentru un client sau angajatorul dvs., încheiați-o cu dovezi. Odată ce noul instrument semnează și se aliniază, re-rulați scanarea gratuită și trimiteți raportul clasificat proprietarului afacerii: dovadă datată, în limbaj simplu, că comutarea a lăsat domeniul complet autentificat. Este artefactul de care vor avea nevoie pentru reînnoirea asigurării cibernetice și pentru următorul chestionar de securitate al furnizorilor — transformă „migrarea este gata” dintr-o afirmație într-un document.

Verificați gratuit DKIM-ul

Vedeți dacă selectorii noului dvs. instrument se rezolvă — și exact ce trebuie corectat — privat și numai pentru proprietar.

Verificați domeniul → · SPF s-a stricat după schimbarea furnizorului → · Corectați DKIM → · Configurați DKIM pe Google Workspace → · Doar date agregate. Date stocate și procesate în UE.