DKIM "Ingen nøgle til signatur": Selektor- og rotationsrettelser (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.

“Ingen nøgle til signatur” betyder, at modtageren forespurgte den DNS-post, som din DKIM-signatur peger på — selektor._domainkey.ditdomæne — og fandt ingen nøgle: den er aldrig udgivet eller blev slettet midt i en rotation. Udgiv den selektor, din underskriver faktisk bruger. Kun 10,092,481 domæner — 3.87% — fuldfører SPF+DKIM+DMARC-triaden, ifølge Defaults.Exposed-census over 261,086,232 graderede domæner.

Løsningen er én DNS-post, fundet i én header. Læs s=- og d=-taggene fra en reel DKIM-Signature-header for at finde ud af, hvilken selektor din mail er signeret med, udgiv (eller reparer) præcis den post, og foretruk CNAME-delegation, så din udbyder roterer nøgler for dig. Rotér derefter efter nedenstående plan — denne fejl skyldes typisk, at nogen slettede en gammel selektor for tidligt.

Hvad betyder “dkim ingen nøgle til signatur”?

Enhver DKIM-signatur bærer to tags, der fortæller modtageren, hvor den offentlige nøgle skal hentes: d= (signeringsdomæne) og s= (selektor). Modtageren forespørger ét DNS-navn bygget fra dem — s._domainkey.d — efter nøglen. “Ingen nøgle til signatur” betyder, at den forespørgsel kom tom tilbage: signaturen eksisterer, men den nøgle, den navngiver, gør det ikke.

Formuleringen optræder i Authentication-Results-headere og DMARC-aggregerede rapporter — den præcise formulering varierer afhængigt af modtager, men to varianter er vigtige:

Resultatsstreng (fragment, som observeret)	Hvad der rent faktisk skete	Forbigående?
`dkim=temperror (no key for signature)`	DNS-forespørgslen fejlede eller fik timeout — modtageren kunne slet ikke få et svar	Ja — genforsøg lykkes ofte; undersøg kun, hvis det er vedvarende
`dkim=permerror (no key for signature)`	DNS-forespørgslen lykkedes, og svaret var “ingen post” — selektoren er genuint fraværende	Nej — posten mangler, indtil du udgiver den

En engangs-temperror er DNS-vejr. En permerror — eller en temperror, der gentages over dage og hos flere modtagere — betyder, at den post, signaturen peger på, ikke er i din zone. Det er denne vejledning.

Konsekvensen: en ikke-verificerbar signatur tæller som slet ingen DKIM, så DMARC falder tilbage til SPF alene — og SPF bryder ved videresendelse. Hvis signaturen er til stede men ugyldig i stedet for manglende (body hash, ødelagt nøgle), er det en anden fejl — se “DKIM-signatur ikke gyldig”.

Hvordan finder jeg, hvilken selektor min mail er signeret med?

Gæt ikke ud fra din udbyders dokumentation — læs det fra en reel besked:

Send en besked fra det berørte system til en postkasse, du kontrollerer (en Gmail-adresse fungerer godt).
Åbn råformatet (“Vis original” i Gmail, “Vis beskedkilde” i Outlook).
Find DKIM-Signature:-headeren og læs to tags: s= er selektoren, d= er signeringsdomænet. Et illustrativt eksempel: DKIM-Signature: v=1; a=rsa-sha256; d=ditdomæne.dk; s=mail2026; ...
Den post, modtageren forespørger, er s._domainkey.d — her mail2026._domainkey.ditdomæne.dk. Kontrollér det selv: dig TXT mail2026._domainkey.ditdomæne.dk +short. Tomt svar = fejlen er reel for alle modtagere.
Gentag pr. afsendersystem. En besked kan bære flere DKIM-signaturer — postkasseudbyder, nyhedsbrevværktøj, helpdesk — med hvert sit s=/d=-par og post. Ret den fejlende, og bemærk dens d=: kun en signatur, hvis d= matcher dit Fra-domæne, hjælper DMARC.

Hvorfor mangler selektorposten?

Fire årsager tegner sig for næsten alle disse fejl — kontrollér dem i denne rækkefølge:

Den er aldrig udgiv. Underskriveren blev slået til (eller var slået til som standard) med en selektor, som ingen har tilføjet til DNS. Hyppigt med nye værktøjer og gateways, der signerer uventet.
Den blev slettet midt i en rotation. Nogen “ryddede op” i den gamle selektor, mens beskeder signeret med den stadig var under forsendelse, i kø til genforsøg eller afventende videresendelse. Den mail er allerede signeret med s=gammel; sletning af gammel._domainkey bryder retroaktivt alle disse beskeder.
Dit DNS-brugergrænseflade ødelagde et CNAME-mål. Mange udbydere delegerer via CNAME (s1._domainkey.ditdomæne.dk → s1.domainkey.u123.esp.com), og mange DNS-paneler tilføjer lydløst din zone til målet — lagrer s1.domainkey.u123.esp.com.ditdomæne.dk, som opløser til ingenting. Verificer målet: dig CNAME s1._domainkey.ditdomæne.dk +short. Den samme fælde bider under værktøjsmigreringer — se DKIM fejler efter skift af e-mailværktøjer.
Udbyderen roterede, din zone fulgte ikke med. En udbydernøgle indsat som en statisk TXT-post (i stedet for deres CNAMEs) er forældet af deres planlagte rotation — underskriveren skifter til en selektor, du aldrig har udgivet. 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).

Hvordan løser jeg “ingen nøgle til signatur”?

Kør den gratis scanning på defaults.exposed inden du rører DNS. Den læser dine live DKIM-, SPF- og DMARC-poster og viser, hvad modtagerne faktisk ser — herunder om selektoren opløses, og om et CNAME-mål er blevet ødelagt.
Udgiv den selektor, som underskriveren faktisk bruger — s=-værdien fra headeren, ikke den fra en gammel driftshåndbog. Hent posten fra din udbyders administratorkonsol (Google Workspace DKIM-opsætning · Microsoft 365 DKIM-opsætning) og tilføj den præcis på s._domainkey.ditdomæne.dk.
Foretruk CNAME-delegation frem for at indsætte en TXT-nøgle. Hvis din udbyder tilbyder DKIM-CNAMEs, brug dem: nøglen befinder sig i deres zone, så de roterer den uden at du rører DNS igen — årsag 4 bliver umulig. Nyhedsbrevplatforme fungerer næsten alle på denne måde; se Mailchimp/Brevo/Klaviyo-e-mails, der fejler DMARC.
Verificer fra uden for dit panel. dig TXT s._domainkey.ditdomæne.dk +short (eller dig CNAME … for delegerede selektorer) fra en maskine uden for dit netværk. At panelet viser posten beviser ingenting, hvis zonen serverer noget andet.
Scan igen og gensend testbeskeden. Authentication-Results bør nu vise dkim=pass. Arbejd derefter videre med alt andet, scanningen markerer, på siden ret DKIM — en godkendt signatur, der ikke justerer med dit Fra-domæne, fejler stadig DMARC.

Hvordan roterer jeg DKIM-nøgler uden at forårsage denne fejl?

Rotation er der, hvor fungerende opsætninger bryder. Den regel, der forhindrer det: en selektor slettes kun, efter den sidste besked signeret med den er drænet — aldrig ved overgang. Signeret mail lever længere, end du tror: genforsøgskøer kører i dage, og videresendte beskeder verificeres igen, hvad end de bevæger sig.

Trin	Handling	Gate inden næste trin
1. Tilføj	Udgiv den nye selektor (`s2._domainkey…`) ved siden af den gamle	`dig` bekræfter, at den opløses udefra
2. Skift	Peg underskriveren på den nye selektor	Testbesked viser `s=s2` og `dkim=pass`
3. Vent	Behold den gamle selektor udgivet, mens trafik under forsendelse, i kø og videresendt dræner	≥ 7 dage; overvåg DMARC-aggregerede rapporter, til den gamle selektor holder op med at optræde
4. Pensioner	Fjern den gamle nøgle — eller udgiv den endnu bedre med et tomt `p=`-tag: “pensioneret”, ikke “eksisterede aldrig”	Påbegynd aldrig dette ved overgang — for tidlig sletning er den #1-årsag til “ingen nøgle til signatur”

Med CNAME-delegation kører din udbyder præcis denne plan i sin egen zone, og du ser det aldrig — det stærkeste argument for delegation.

Ofte stillede spørgsmål

Er “ingen nøgle til signatur” en temperror eller en permerror? Begge strenge eksisterer: temperror er et DNS-opslag, der fejlede eller fik timeout — forbigående, ofte væk ved genforsøg — mens permerror betyder, at DNS svarede “ingen post”. En temperror, der gentages hos flere modtagere, viser sig typisk at være en genuint manglende post alligevel. Kontrollér med dig og stol på svaret, ikke etiketten.

Betyder denne fejl, at nogen spoofar mit domæne? Nej — en spoofer ville ikke signere med din selektor. Det betyder, at din egen mail bærer en signatur, som modtagere ikke kan verificere, så den tæller som usigneret, og DMARC hviler på SPF alene. Fuld, justeret godkendelse er sjælden: kun 10,092,481 af 261,086,232 domæner (3.87%) fuldførte SPF+DKIM+DMARC-triaden i Defaults.Exposed-census (data pr. 2026-06-29).

Kan jeg bare slette den gamle selektor, når den nye virker? Ikke øjeblikkeligt. Beskeder signeret med den er stadig i genforsøgskøer og videresendelsesforløb; at slette nøglen bryder dem retroaktivt. Behold den gamle post mindst en uge, overvåg dine DMARC-rapporter, til den gamle selektor holder op med at optræde, og pensionér den derefter — ideelt med et tomt p= i stedet for sletning.

Min udbyders kontrollør siger, at DKIM er konfigureret, men modtagere rapporterer stadig ingen nøgle. Hvordan? Næsten altid CNAME-måls-fælden: dit DNS-panel har tilføjet din zone til målet (…esp.com.ditdomæne.dk), så posten eksisterer men peger ingen steder. dig CNAME selektor._domainkey.ditdomæne.dk +short viser det lagrede mål verbatim — sammenlign det tegn for tegn med, hvad udbyderen bad om.

Send ejeren rapporten

Retter du dette for en klient eller din arbejdsgiver, så afslut med dokumentation. Kør den gratis scanning igen, når selektoren opløses, og videresend den graderede rapport til virksomhedsejeren: dateret, klart sprog, DKIM verificerer nu. Det er det artefakt, de skal bruge til fornyelse af cyberforsikring og det næste leverandørs sikkerhedsspørgeskema — bevis for en fungerende kontrol, ikke blot en lukket sag.

Kontrollér dit DKIM gratis

Se om dine selektorer opløses — og præcis hvad der skal rettes — privat og kun for ejeren.

Kontrollér dit domæne → · “DKIM-signatur ikke gyldig” → · Ret DKIM → · Opsæt DKIM på Google Workspace → · Kun aggregerede data. Data opbevares og behandles i EU.