DKIM «No Key for Signature»: Velger- og rotasjonsfikser (2026)

Publisert 2026-07-08

Tall per 2026-06-29 · metodikk v7. Samlet sensusdata for 261 millioner graderte domener. Se hvordan vi graderer.

«No key for signature» betyr at mottakeren spurte DNS-posten DKIM-signaturen peker til — velger._domainkey.dittdomene — og fant ingen nøkkel: den ble aldri publisert, eller ble slettet midt i en rotasjon. Publiser velgeren signereren faktisk bruker. Bare 10,092,481 domener — 3.87% — fullfører SPF+DKIM+DMARC-triaden, ifølge Defaults.Exposed-sensus over 261,086,232 graderte domener.

Fiksen er én DNS-post, funnet i én overskrift. Les s= og d=-taggene fra en ekte DKIM-Signature-overskrift for å lære hvilken velger e-posten er signert med, publiser (eller reparer) den eksakte posten, og foretrekk CNAME-delegering slik at leverandøren roterer nøkler for deg. Roter deretter etter kjøreboken nedenfor — denne feilen betyr vanligvis at noen slettet en gammel velger for tidlig.

Hva betyr «dkim no key for signature»?

Enhver DKIM-signatur bærer to tagger som forteller mottakeren hvor den offentlige nøkkelen kan hentes: d= (signeringsdomene) og s= (velger). Mottakeren spør ett DNS-navn bygget fra dem — s._domainkey.d — etter nøkkelen. «No key for signature» betyr at spørringen kom tilbake tom: signaturen finnes, men nøkkelen den navngir gjør det ikke.

Ordlyden vises i Authentication-Results-overskrifter og DMARC-samlede rapporter — den eksakte formuleringen varierer per mottaker, men to smaker betyr noe:

Resultatstreng (fragment, som mye observert)	Hva skjedde egentlig	Forbigående?
`dkim=temperror (no key for signature)`	DNS-spørringen feilet eller tidsutelukket — mottakeren fikk ikke svar overhodet	Ja — nye forsøk er ofte OK; undersøk bare hvis vedvarende
`dkim=permerror (no key for signature)`	DNS-spørringen lyktes og svaret var «ingen slik post» — velgeren mangler genuint	Nei — posten mangler til du publiserer den

En engangsmessig temperror er DNS-vær. En permerror — eller en temperror som gjentar seg over dager og mottakere — betyr at posten signaturen peker til ikke er i sonen din. Det er denne veiledningen.

Konsekvensen: en ubekreftbar signatur telles som ingen DKIM overhodet, så DMARC faller tilbake på SPF alene — og SPF bryter ved videresending. Hvis signaturen er til stede men ugyldig snarere enn manglende (body hash, ødelagt nøkkel), er det en annen feil — se «DKIM-signatur ikke gyldig».

Hvordan finner jeg hvilken velger e-posten min er signert med?

Ikke gjett fra leverandørens dokumentasjon — les det fra en ekte melding:

Send en melding fra det berørte systemet til en postkasse du kontrollerer (en Gmail-adresse fungerer godt).
Åpne kilden («Show original» i Gmail, «View message source» i Outlook).
Finn DKIM-Signature:-overskriften og les to tagger: s= er velgeren, d= er signeringsdomenet. Et illustrerende eksempel: DKIM-Signature: v=1; a=rsa-sha256; d=dittdomene.com; s=mail2026; ...
Posten mottakeren spør er s._domainkey.d — her mail2026._domainkey.dittdomene.com. Sjekk det selv: dig TXT mail2026._domainkey.dittdomene.com +short. Tomt svar = feilen er reell for alle mottakere.
Gjenta per avsendersystem. En melding kan bære multiple DKIM-signaturer — postkasseleverandør, nyhetsbrevverktøy, helpdesk — hver med sitt eget s=/d=-par og post. Fiks den som feiler, og noter d=: bare en signatur hvis d= samsvarer med Fra-domenet ditt hjelper DMARC.

Hvorfor mangler velgerposten?

Fire årsaker forklarer nesten alle disse feilene — sjekk dem i denne rekkefølgen:

Den ble aldri publisert. Signereren ble slått på (eller satt på som standard) med en velger ingen la til i DNS. Vanlig med nye verktøy og gateways som signerer uventet.
Den ble slettet midt i en rotasjon. Noen «ryddet opp» den gamle velgeren mens meldinger signert med den fortsatt var under transport, i forsøkskøer, eller ventet på videresending. Den e-posten er allerede signert med s=gammel; å slette gammel._domainkey bryter alle de meldingene retroaktivt.
DNS-grensesnittet ødela et CNAME-mål. Mange leverandører delegerer via CNAME (s1._domainkey.dittdomene.com → s1.domainkey.u123.esp.com), og mange DNS-paneler legger stille til sonen din til målet — lagrer s1.domainkey.u123.esp.com.dittdomene.com, som løser til ingenting. Bekreft målet: dig CNAME s1._domainkey.dittdomene.com +short. Den samme fellen biter ved verktøymigrasjer — se DKIM feiler etter bytte av e-postverktøy.
Leverandøren roterte, sonen din ikke. En leverandørnøkkel limt inn som en statisk TXT-post (i stedet for CNAME-ene) er foreldreløs av den planlagte rotasjonen — signereren flyttes til en velger du aldri publiserte. Bare 51.84% av de 261 millioner domenene i sensus presenterer en oppdagbar DKIM-nøkkel på skanne-tidspunktet (data per 2026-06-29).

Hvordan fikser jeg «no key for signature»?

Kjør den gratis skanningen på defaults.exposed før du rører DNS. Den leser live DKIM, SPF og DMARC-poster dine og viser hva mottakere faktisk ser — inkludert om velgeren løser opp og om et CNAME-mål ble ødelagt.
Publiser velgeren signereren faktisk bruker — s=-verdien fra overskriften, ikke den i en gammel kjørebok. Hent posten fra leverandørens admin-konsoll (Google Workspace DKIM-oppsett · Microsoft 365 DKIM-oppsett) og legg den til nøyaktig på s._domainkey.dittdomene.com.
Foretrekk CNAME-delegering over å lime inn en TXT-nøkkel. Hvis leverandøren tilbyr DKIM CNAME-er, bruk dem: nøkkelen bor i deres sone, så de roterer den uten at du rører DNS igjen — årsak 4 blir umulig. Nyhetsbrevplattformer fungerer nesten alle slik; se Mailchimp/Brevo/Klaviyo e-poster feiler DMARC.
Bekreft utenfor panelet. dig TXT s._domainkey.dittdomene.com +short (eller dig CNAME … for delegerte velgere) fra en maskin utenfor nettverket ditt. Panelet som viser posten beviser ingenting hvis sonen serverer noe annet.
Skann på nytt og send testmeldingen på nytt. Authentication-Results skal nå lese dkim=pass. Arbeid deretter gjennom alt annet skanningen flagger på siden fiks DKIM — en bestående signatur som ikke er justert med Fra-domenet ditt feiler fortsatt DMARC.

Hvordan roterer jeg DKIM-nøkler uten å forårsake denne feilen?

Rotasjon er der fungerende oppsett bryter. Regelen som forhindrer det: en velger slettes bare etter at den siste meldingen signert med den er drenert — aldri ved innkoplingen. Signert e-post lever lenger enn du tror: forsøkskøer kjører i dager, og videresendte meldinger bekreftes på nytt når de flyttes.

Trinn	Handling	Port før neste trinn
1. Legg til	Publiser den nye velgeren (`s2._domainkey…`) ved siden av den gamle	`dig` bekrefter at den løser opp utenifra
2. Bytt	Pek signereren mot den nye velgeren	Testmelding viser `s=s2` og `dkim=pass`
3. Vent	La den gamle velgeren forbli publisert mens under-transport, køet og videresendt trafikk drenerer	≥ 7 dager; se på DMARC samlede rapporter til den gamle velgeren slutter å dukke opp
4. Trekk tilbake	Fjern den gamle nøkkelen — eller bedre, republiser den med en tom `p=`-tagg: «trukket tilbake», ikke «eksisterte aldri»	Start aldri dette ved innkoplingen — for tidlig sletting er den #1 årsaken til «no key for signature»

Med CNAME-delegering kjører leverandøren nøyaktig denne kjøreboken inni sin egen sone og du ser det aldri — det sterkeste argumentet for å delegere.

Ofte stilte spørsmål

Er «no key for signature» en temperror eller en permerror? Begge strenger finnes: temperror er et DNS-oppslag som feilet eller tidsutelukket — forbigående, borte ved nytt forsøk — mens permerror betyr at DNS svarte «ingen slik post». En temperror som gjentar seg over mottakere viser seg vanligvis å være en genuint manglende post også. Sjekk med dig og stol på svaret, ikke etiketten.

Betyr denne feilen at noen forfalsker domenet mitt? Nei — en svindler ville ikke signere med velgeren din. Det betyr at din egen e-post bærer en signatur mottakere ikke kan bekrefte, så den telles som usignert og DMARC lener seg på SPF alene. Full, justert autentisering er sjeldent: bare 10,092,481 av 261,086,232 domener (3.87%) fullførte SPF+DKIM+DMARC-triaden i Defaults.Exposed-sensus (data per 2026-06-29).

Kan jeg bare slette den gamle velgeren når den nye er i gang? Ikke umiddelbart. Meldinger signert med den er fortsatt i forsøkskøer og videresendingsstier; å slette nøkkelen bryter dem retroaktivt. Behold den gamle posten i minst en uke, se på DMARC-rapporter til den gamle velgeren slutter å dukke opp, og trekk den deretter tilbake — ideelt sett med en tom p= heller enn sletting.

Leverandørens sjekketjeneste sier DKIM er konfigurert, men mottakere rapporterer fortsatt ingen nøkkel. Hvordan? Nesten alltid CNAME-mål-fellen: DNS-panelet la til sonen din til målet (…esp.com.dittdomene.com), så posten finnes men peker ingen steder. dig CNAME velger._domainkey.dittdomene.com +short viser det lagrede målet ordrett — sammenlign tegn for tegn med hva leverandøren ba om.

Send eieren rapporten

Hvis du fikser dette for en klient eller arbeidsgiveren din, lukk løkken med bevis. Kjør den gratis skanningen når velgeren løser opp og videresend den graderte rapporten til bedriftseieren: datert, på enkelt norsk, DKIM bekreftes nå. Det er artefakten de vil trenge til fornyelse av cyberforsikring og neste leverandørsikkerhetsspørreskjema — bevis for en fungerende kontroll, ikke bare en lukket sak.

Sjekk DKIM gratis

Se om velgerne dine løser opp — og nøyaktig hva du skal fikse — privat og kun for eieren.

Sjekk domenet ditt → · «DKIM-signatur ikke gyldig» → · Fiks DKIM → · Sett opp DKIM på Google Workspace → · Kun aggregerte data. Data lagret og behandlet i EU.