DKIM fejler efter skift af e-mailværktøjer: CNAME- og selektor-migreringsguiden (2026)

Udgivet 2026-07-08

Tal fra 2026-06-29 · metodologi v7. Aggregerede censusdata på tværs af 261 millioner graderede domæner. Se hvordan vi graderer.

DKIM bryder efter et værktøjsskifte af to mekaniske årsager: dit DNS-panel forvrængte det nye værktøjs CNAME-mål — typisk ved at tilføje din egen zone — eller de gamle selektorer blev fjernet, inden dets mail var drænet. Kun 3.87% af domæner — 10,092,481 — fuldfører SPF+DKIM+DMARC-triaden, ifølge Defaults.Exposed-census over 261,086,232 graderede domæner.

Løsningsrækkefølgen: scan domænet, kontrollér derefter hvert nyt CNAME’s lagrede mål med dig — et mål, der slutter på dit eget domænenavn, er det afgørende tegn. Ret posterne hos de autoritative navneservere, bekræft at det nye værktøj signerer og godkendes inden du sender rigtig mail igennem det, og behold de gamle selektorer udgivet, til dets trafik er drænet.

Hvorfor holdt DKIM op med at virke, da du skiftede værktøjer?

Intet ved DKIM selv ændrede sig — dine selektorer gjorde. Det gamle værktøj signerede med dets selektorer; det nye signerer med andre, typisk delegeret via to eller tre CNAME-poster tilføjet under onboarding. Fire faldgruber er årsag til næsten alle DKIM-fejl efter migrering:

Dit DNS-panel tilføjede din zone til CNAME-målet. Mange paneler behandler et indsat hostnavn som relativt og lagrer lydløst mål.leverandør.com.ditdomæne.com i stedet for mål.leverandør.com. Posten eksisterer, panelet viser et grønt flueben, og det opløses til ingenting.
Forvirring om afsluttende punktum. Nogle paneler kræver et afsluttende punktum (mål.leverandør.com.) for at betyde “absolut — stop med at tilføje min zone”; andre afviser punktummet som ugyldigt og håndterer absoluthed selv. Den samme indsatte værdi er korrekt i ét panel og forvrænget i det næste.
De gamle selektorer blev slettet på skiftedagen. Mail, som det gamle værktøj allerede har signeret, sidder i genforsøgskøer og videresendelsesforløb i dage; at fjerne dets selektorer — eller lukke den gamle konto, hvilket dræber dets delegerede CNAMEs — bryder den mail retroaktivt.
Du verificerede mod de forkerte navneservere. Hvis migreringen inkluderede en navneserverskift, kan de rettede poster eksistere hos ét NS-sæt, mens modtagerne stadig forespørger det andet.

Kun 51.84% af de 261 millioner domæner i census præsenterer en synlig DKIM-nøgle ved scanningstidspunktet (data pr. 2026-06-29).

Den samme migrering efterlader typisk også SPF-rester — 1,013,416 domæner, omtrent ét ud af 138 af dem, der forsøger SPF, kører to v=spf1-poster, det klassiske tegn på, at et udbyderskifte tilføjede en post i stedet for at flette en. Den side af flytningen har sin egen vejledning: SPF holdt op med at virke efter skift af e-mailudbyder.

Hvordan spotter jeg en forvrænget CNAME-post?

Stol ikke på panelet — spørg DNS, hvad det faktisk lagrede. Forespørg CNAME-målet for hver selektor, det nye værktøj gav dig. Et illustrativt eksempel, der efterligner en SendGrid-lignende delegeret selektor (din udbyders målform vil se anderledes ud):

$ dig CNAME s1._domainkey.ditdomæne.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.ditdomæne.com.

Udbyderen bad om s1.domainkey.u1234567.wl123.sendgrid.net — men det lagrede mål slutter på .ditdomæne.com. Panelet tilføjede zonen; det navn opløses til ingenting, så modtagerne finder ingen nøgle. Den sunde version:

$ dig CNAME s1._domainkey.ditdomæne.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Et enkelt afsluttende punktum i dig-output er normalt — det markerer et fuldt kvalificeret navn.) Er målet korrekt, skal du følge det ét hop: dig TXT s1._domainkey.ditdomæne.com +short bør returnere udbyderens nøgle. Tomt svar med et korrekt CNAME betyder, at problemet er på udbyderens side af delegationen — afslut deres verifikationstrin, eller se DKIM “ingen nøgle til signatur” for diagnosen på selektor-niveau.

Migreringsplanen: før, under og efter

Fejlen skyldes typisk ikke posterne — det er rækkefølgen. DKIM-migreringer går galt ved overgang, fordi verifikation sker efter skiftet, når rigtig mail allerede fejler.

Fase	Hvad du skal gøre	Gate inden næste trin
Inden skiftet	Tilføj det nye værktøjs DKIM-CNAMEs (og bounce-domæneposter), bevis dem derefter: `dig` hvert CNAMEs lagrede mål fra uden for dit netværk, afslut værktøjets eget verifikationstrin, og send en test via det nye værktøj til en postkasse du kontrollerer	Testbesked viser `dkim=pass` med `d=` = dit domæne — send aldrig rigtig mail via et uverificeret værktøj
Skiftedag	Flyt rigtig trafik til det nye værktøj. Rør intet, der tilhører det gamle værktøj: lad dets selektorer, CNAMEs og konto forblive aktive	Det nye værktøjs mail godkendes hos rigtige modtagere; det gamle fortsætter med at godkendes for alt, der stadig flyder igennem det
Efter dræning	Overvåg DMARC-aggregerede rapporter, til det gamle værktøjs selektorer holder op med at optræde (genforsøgskøer og videresendelser kører i dage — giv en uge eller mere), pensionér derefter dets poster og konto	Gamle selektorer fraværende fra rapporter ≥ 7 dage inden fjernelse

Den fremhævede række er, hvor migreringer reddes eller går tabt: alle kontroller i den kan udføres dage inden overgang, uden risiko for igangværende mail. Mekanikken bag selektor-pensionering — herunder hvorfor genudgivelse med et tomt p= er bedre end sletning — er dækket i rotationsplanen; denne tabel handler om at sekvensere selve værktøjsskiftet.

Hvordan løser jeg DKIM efter skiftet?

Kør den gratis scanning på defaults.exposed inden du rører DNS. Den læser dine live-poster og viser, hvad modtagerne faktisk ser — herunder CNAME-mål, der har fået zonen tilføjet, og selektorer, der ikke opløses.
List de DKIM-poster, det nye værktøj forventer. Fra dets administratorkonsol — for postkasseudbydere viser Google Workspace og Microsoft 365 opsætningsvejledningerne, hvor; nyhedsbrev- og CRM-værktøjer lister deres CNAMEs under domænegodkendelse (se Mailchimp/Brevo/Klaviyo-e-mails der fejler DMARC).
Kontrollér hvert posts lagrede værdi med dig CNAME <navn> +short og sammenlign det tegn for tegn med, hvad værktøjet bad om. Et mål, der slutter på dit eget domæne = zone-tilføjet; genindtast det, og tilføj det afsluttende punktum, hvis panelet fortsætter med at tilføje (eller fjern det, hvis panelet afviser punktummer).
Verificer hos de autoritative navneservere. dig +short NS ditdomæne.com, og gentag derefter CNAME-kontrollerne @<den navneserver>. Hvis migreringen ændrede navneservere, skal du kontrollere begge sæt — modtagerne kan stadig forespørge det gamle, til delegationen propagerer.
Kør værktøjets verifikation igen og send en testbesked. Authentication-Results-headeren bør vise dkim=pass med d= lig dit domæne — et pass på værktøjets standarddomæne justerer ikke med DMARC.
Lad de gamle selektorer forblive udgivet, til dets mail er drænet, og pensionér dem derefter med vilje. Scan derefter igen og arbejd videre med alt andet, der er markeret på siden ret DKIM.

Ofte stillede spørgsmål

Har jeg brug for det afsluttende punktum på mit DKIM-CNAME eller ej? Det afhænger helt af panelet. Punktummet betyder “absolut navn — tilføj ikke min zone”; nogle paneler kræver det, nogle tilføjer det for dig, andre afviser det. Den eneste test, der tæller, er outputtet af dig CNAME <selektor>._domainkey.ditdomæne.com +short efter lagring: ender målet på dit eget domæne, tilføjede panelet zonen, og du har brug for punktummet (eller et andet inputformat).

Kan jeg slette de gamle selektorer på skiftedagen? Nej. Mail, det gamle værktøj har signeret, er stadig i genforsøgskøer og videresendelsesforløb, og at slette den nøgle, det peger på, bryder den mail retroaktivt. Hold de gamle selektorer live, til de holder op med at optræde i dine DMARC-aggregerede rapporter — en uge eller mere — og luk heller ikke den gamle konto inden da.

Mit DNS-panel og det nye værktøj siger begge “verificeret”, men modtagere fejler stadig DKIM. Hvordan? To almindelige tilfælde: værktøjet verificerede mod et cachet opslag, mens de autoritative navneservere serverer noget andet (forespørg dem direkte med dig @<ns>), eller DKIM godkendes men på værktøjets standard signeringsdomæne frem for dit, så DMARC stadig fejler justering. Scanningen skelner mellem de to.

Kan begge værktøjers DKIM-poster eksistere side om side under overlapsperioden? Ja — og det bør de. DKIM har ingen enkelt-post-regel: hver selektor er sit eget DNS-navn, så begge værktøjers poster lever side om side uden konflikt, hvilket gør reglen om at beholde gamle selektorer under dræning let at følge. (SPF er det modsatte — to v=spf1-poster ugyldiggør det, hvilket er grunden til, at SPF-migreringsguiden handler om at flette.)

Send ejeren rapporten

Kører du denne migrering for en klient eller din arbejdsgiver, skal du afslutte med dokumentation. Når det nye værktøj signerer og justerer, skal du køre den gratis scanning igen og videresende den graderede rapport til virksomhedsejeren: dateret, klart-sprog bevis for, at skiftet efterlod domænet fuldt godkendt. Det er det artefakt, de har brug for til fornyelse af cyberforsikring og det næste leverandørs sikkerhedsspørgeskema — det forvandler “migreringen er færdig” fra en påstand til et dokument.

Kontrollér dit DKIM gratis

Se om dit nye værktøjs selektorer opløses — og præcis hvad der skal rettes — privat og kun for ejeren.

Kontrollér dit domæne → · SPF holdt op med at virke efter skift af udbyder → · Ret DKIM → · Opsæt DKIM på Google Workspace → · Kun aggregerede data. Data opbevares og behandles i EU.