Defaults.Exposed › Rettelser › Guides
'DKIM-signatur ikke gyldig' — årsagerne i den rækkefølge, du bør kontrollere dem (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-signatur ikke gyldig” har fem almindelige årsager, bedst kontrolleret i rækkefølge: indhold ændret under transit, en afkortet nøglepost, en udgivet nøgle, der ikke matcher underskriveren, den forkerte selektor og skrøbelig kanonisering. Kun 10,092,481 af 261,086,232 graderede domæner (3.87%) har den fulde SPF + DKIM + håndhævet-DMARC-triade, ifølge Defaults.Exposed-census (2026-06-29).
Løsningsrækkefølgen er vigtig, fordi den mest almindelige årsag slet ikke er i din DNS. Kontrollér først, hvad der ændrede beskeden under transit, og arbejd derefter indad: nøglepostens integritet, om den matcher det, din mailserver rent faktisk signerer med, selektoren og til sidst signeringsindstillingerne. De fleste ugyldige signaturer løses i trin ét eller to.
Hvad betyder “DKIM-signatur ikke gyldig” egentlig?
Enhver DKIM-signeret besked bærer en DKIM-Signature-header, der angiver et domæne (d=), en selektor (s=), en hash af beskedens body (bh=) og en kryptografisk signatur over body-hashen plus udvalgte headere (b=). Modtageren henter din offentlige nøgle fra DNS på <selektor>._domainkey.<domæne>, genberegner begge hashes og kontrollerer signaturen (RFC 6376). “Signatur ikke gyldig” er kontrollørers og headersspeak for: verifikationen kørte og fejlede — nøglen blev fundet, men matematikken gik ikke op.
Den sidste sætning er den diagnostiske guldgrube. En verifikator, der ikke kan finde din nøgle, siger noget andet — typisk en header som dkim=fail (no key for signature) — og det er et selektor-problem, dækket i DKIM “ingen nøgle til signatur” — selektor- og rotationsrettelser. En verifikator, der genberegner en anden body hash, siger det typisk eksplicit: body hash did not verify — Microsoft rapporterer det som dkim=fail (body hash did not verify), mens Gmail ofte gengiver den samme diagnose som dkim=neutral (body hash did not verify). I begge tilfælde peger det på indholdsomdannelse, dækket i “body hash did not verify” — hvad ændrede din besked. Læs den præcise formulering i Authentication-Results-headeren, inden du rører noget som helst: den fortæller dig, hvilken af de fem årsager du har.
At få dette rigtigt er sjældent: kun 51.84% af graderede domæner udgiver en synlig DKIM-nøgle i DNS overhovedet, ifølge Defaults.Exposed-census, og kun 3.87% af 261 millioner graderede domæner kombinerer SPF, DKIM og en håndhævet DMARC-politik — den konfiguration, som masseafsenderreglerne nu forudsætter. Det trinvise billede er i SPF-adoptionsmodenheds-modellen.
Hvad er de fem årsager i rækkefølge?
| # | Årsag | Tegnet | Løsningen |
|---|---|---|---|
| 1 | Indhold ændret under transit — gateway-footers, juridiske ansvarsfraskrivelser, mailingliste-emnetaggs | body hash did not verify i Authentication-Results; ekstern mail fejler, direkte mail godkendes | Signér efter ændringen, eller stop med at ændre — se body-hash-vejledningen |
| 2 | Afkortet eller ødelagt lang nøgle | Udgivet p= er synlig kortere end den genererede nøgle; alle modtagere fejler | Genudgiv 2048-bit-nøglen som korrekt opdelte TXT-strenge |
| 3 | Udgivet nøgle matcher ikke underskriveren | Fejl starter lige efter en rotation, migrering eller udbyderskifte | Kopier den aktuelle post fra underskriverens administratorkonsol igen; foretruk CNAME-delegation |
| 4 | Forkert eller manglende selektor | no key for signature — selve opslaget fejler | Udgiv den selektor, underskriveren rent faktisk bruger — se selektor-vejledningen |
| 5 | Skrøbelig kanonisering eller et l=-tag | Intermitterende fejl på trivielt omformaterede beskeder | c=relaxed/relaxed; fjern l= fuldstændigt |
Årsag 1 er fremhævet, fordi den bryder signaturer på beskeder, der var signeret perfekt. En sikkerhedsgateway tilføjer en ansvarsfraskrivelse, en compliance-footer stemples på efter signering, en mailingliste tilføjer [listenavn] til emnet — body eller signerede headere ændres, hasherne stemmer ikke længere overens, og signaturen er ugyldig uden at din DNS er skyld i noget. Korrelerer fejl med mail, der er gået via en gateway, en liste eller et arkiverings-hop, så start der.
Hvordan løser jeg “DKIM-signatur ikke gyldig”?
- Kør den gratis scanning på defaults.exposed inden du rører DNS. Den viser, om din udgivne nøglepost er til stede, velformet og komplet — og adskiller “din DNS er defekt” (årsager 2–4) fra “din DNS er fin, beskeden ændres” (årsag 1) i ét trin.
- Læs
Authentication-Results-headeren i en fejlende besked.body hash did not verify→ årsag 1, gå til body-hash-vejledningen — de sædvanlige mistænkte er gateway-footers og ansvarsfraskrivelser, og løsningen er at signere efter ændringen.no key for signature→ årsag 4, gå til selektor-vejledningen. Et simpelt signaturfejl → fortsæt. - Kontrollér den udgivne nøgle for afkortning. Slå
<selektor>._domainkey.<ditdomæne>op som TXT (dig TXT selektor._domainkey.eksempel.dk). En 2048-bit RSA-offentlig nøgle er længere end grænsen på 255 tegn for en enkelt TXT-streng, så den skal udgives som flere citerede strenge, som modtagere sammensætter — og DNS-udbyderwebgrænseflader er berygtet for lydløst at afkorte indsætningen, ødelægge opdelingen eller injicere mellemrum og anførselstegn ip=-værdien. Sammenlign tegn for tegn med den nøgle, din underskriver genererede; vores DKIM-opsætningsvejledninger dækker udbyderspecifikke særheder. - Bekræft, at den udgivne nøgle matcher underskriveren. Efter en nøglerotation, udbydersmigrering eller ESP-gentilslutning er det almindeligt, at underskriveren holder en ny privat nøgle, mens DNS stadig serverer den gamle offentlige nøgle — enhver signatur verificeres mod den forkerte nøgle og fejler. Kopier den aktuelle post fra din udbyders administratorkonsol igen. Bedre: hvor udbyderen tilbyder CNAME-delegation, brug det — udbyderen roterer nøgler på sin side, og hele denne klasse af fejl forsvinder. Og slet aldrig en gammel selektor, inden trafik signeret med den er drænet.
- Ret signeringsindstillingerne, ikke kun posten. Sæt kanonisering til
c=relaxed/relaxed, som tolererer det mellemrum-ombrydning og header-omfoldning, som mellemliggende servere legitimt foretager;simplekanonisering fejler ved ændringer, et menneske end ikke kan se. Og brug ikkel=body-length-tagget: det var beregnet til at lade footers igennem, men det lader alle tilføje indhold til din signerede besked uden at bryde signaturen — et reelt angrebsvektor — og det overlever alligevel de fleste gateway-ændringer ikke. Ingenl=er både det sikrere og det mere pålidelige valg. - Scan igen, og kontrollér derefter justering. En gyldig signatur hjælper kun DMARC, hvis
d=-domænet justerer med dit Fra-domæne — en signatur, der validerer somd=dinvirksomhed.gappssmtp.com, godkender DKIM og fejler stadig DMARC. Er det dig, se standard-signatur-fælden, og arbejd derefter videre med alt andet, scanningen markerer, på siden ret DKIM.
Ofte stillede spørgsmål
Er “DKIM-signatur ikke gyldig” det samme som “body hash did not verify”? Body-hash-beskeden er ét specifikt undertilfælde: body’en ændret efter signering (footers, ansvarsfraskrivelser, listeopskrivninger). “Signatur ikke gyldig” er den overordnede dom for enhver mislykket verifikation, herunder dårlige nøgler og header-ændringer — det er grunden til, at trin 2 ovenfor handler om at læse headeren, og det er grunden til, at body-hash-tilfældet har sin egen vejledning.
Betyder en ugyldig DKIM-signatur, at min mail afvises? Ikke i sig selv — modtagere behandler en brækket signatur som en manglende. Skaden lander via DMARC: godkender SPF heller ikke med justering, fejler beskeden DMARC, og din udgivne politik gælder. Pr. census (2026-06-29) har kun 3.87% af 261,086,232 graderede domæner SPF, DKIM og en håndhævet DMARC-politik tilsammen — men Gmail og Microsoft forventer nu præcis det fra afsendere, så et brækket DKIM-ben koster leveringsdygtighed, selv før afvisning.
Bør jeg bruge en 1024-bit eller 2048-bit DKIM-nøgle? 2048-bit — 1024-bit-nøgler er under aktuelle kryptografiske anbefalinger, og nogle modtagere scorer dem ned. Udfordringen er rent operationel: en 2048-bit-nøgle passer ikke i én 255-tegns TXT-streng, så den skal opdeles korrekt (årsag 2 ovenfor). CNAME-delegation til din udbyder undgår opdelingsproblemet fuldstændigt.
Mit DKIM godkendes af en kontrollør, men DMARC fejler stadig — hvordan?
Næsten helt sikkert justering: signaturen validerer, men dens d=-domæne (f.eks. dinvirksomhed.gappssmtp.com eller dinlejer.onmicrosoft.com) matcher ikke dit Fra-domæne, så DMARC kan ikke bruge den. Aktivér din udbyders tilpassede-domæne-signering — den fulde vejledning er i standard-signatur-fælde-vejledningen.
Kan jeg bare slå DKIM fra, hvis det bliver ved med at fejle? Nej — siden 2024-masseforsender-mandaterne kræver Gmail og Yahoo DKIM til store afsendere, og en håndhævet DMARC-politik kræver realistisk set DKIM, fordi SPF alene bryder ved videresendelse. Ret signaturen; årsagerne ovenfor kan alle løses på en eftermiddag.
Send ejeren rapporten
Retter du dette for en klient eller din arbejdsgiver, så afslut med dokumentation. Kør den gratis scanning igen efter dine ændringer og videresend den graderede rapport til virksomhedsejeren: dateret, klart sprog, DKIM med grønt lys. Det er det artefakt, de skal bruge til fornyelse af cyberforsikring og det næste leverandørs sikkerhedsspørgeskema — forskellen mellem “jeg rettede et DNS-problem” og en dokumenteret før-og-efter, der siger, at domænet godkender sin mail.
Kontrollér dit domæne → · “Body hash did not verify”-vejledning → · Ret DKIM → · Sådan graderer vi → · Kun aggregerede data. Data opbevares og behandles i EU.