Defaults.Exposed › Fikser › Guides
«DKIM-signatur ikke gyldig» — Årsakene, i den rekkefølgen du bør sjekke dem (2026)
Publisert 2026-07-08
Tall per 2026-06-29 · metodikk v7. Samlet sensusdata for 261 millioner graderte domener. Se hvordan vi graderer.
«DKIM-signatur ikke gyldig» har fem vanlige årsaker, best sjekket i rekkefølge: innhold endret under transport, en avkuttet nøkkelpost, en publisert nøkkel som ikke samsvarer med signereren, feil velger, og skjør canonicalization. Bare 10,092,481 av 261,086,232 graderte domener (3.87%) har den fulle SPF + DKIM + håndhevende-DMARC-triaden, ifølge Defaults.Exposed-sensus (2026-06-29).
Fiksrekkefølgen betyr noe fordi den vanligste årsaken ikke er i DNS i det hele tatt. Sjekk hva som endret meldingen under transport først, og arbeid deg deretter innover: nøkkelpostens integritet, om den samsvarer med hva e-postserveren faktisk signerer med, velgeren, og til slutt signeringsinnstillingene. De fleste ugyldige signaturer er fikset i trinn én eller to.
Hva betyr «DKIM-signatur ikke gyldig» egentlig?
Alle DKIM-signerte meldinger bærer en DKIM-Signature-overskrift som navngir et domene (d=), en velger (s=), en hash av meldingskroppen (bh=), og en kryptografisk signatur over body-hashen pluss utvalgte overskrifter (b=). Mottakeren henter offentlig nøkkel fra DNS på <velger>._domainkey.<domene>, omberegner begge hasher og sjekker signaturen (RFC 6376). «Signatur ikke gyldig» er sjekke-tjeneste- og overskrift-språket for: den bekreftelsen kjørte og feilet — nøkkelen ble funnet, men mattematikken stemte ikke.
Den siste klausulen er diagnostisk gull. En bekrefter som ikke kan finne nøkkelen sier noe annet — vanligvis en overskrift som dkim=fail (no key for signature) — og det er et velger-problem, dekket i DKIM «no key for signature» — velger- og rotasjonsfikser. Og en bekrefter som omberegner en annen body hash sier vanligvis det eksplisitt: body hash did not verify — Microsoft rapporterer det som dkim=fail (body hash did not verify), mens Gmail ofte gjengir den samme diagnosen som dkim=neutral (body hash did not verify). Uansett peker det på innholdsendring, dekket i «body hash did not verify» — hva endret meldingen din. Les den eksakte ordlyden i Authentication-Results-overskriften før du rører noe som helst: den forteller deg hvilken av de fem årsakene du har.
Å få dette riktig er sjeldent: bare 51.84% av graderte domener publiserer en oppdagbar DKIM-nøkkel i DNS overhodet, ifølge Defaults.Exposed-sensus, og bare 3.87% av 261 millioner graderte domener kombinerer SPF, DKIM og en håndhevende DMARC-policy — konfigurasjonen bulkavsender-reglene nå antar. Stadium-for-stadium-bildet er i SPF-adopsjonens modenhetsmodell.
Hva er de fem årsakene, i rekkefølge?
| # | Årsak | Tegnet | Fiksen |
|---|---|---|---|
| 1 | Innhold endret under transport — gateway-bunntekster, juridiske ansvarsfraskrivelser, e-postliste-emnemerker | body hash did not verify i Authentication-Results; ekstern e-post feiler, direkte e-post er OK | Signer etter endringen, eller stopp endringen — se body-hash-veiledningen |
| 2 | Avkuttet eller ødelagt lang nøkkel | Publisert p= er synlig kortere enn nøkkelen du genererte; alle mottakere feiler | Republiser 2048-bit-nøkkelen som riktig splittede TXT-strenger |
| 3 | Publisert nøkkel samsvarer ikke med signereren | Feil begynner rett etter en rotasjon, migrering eller leverandørbytte | Kopier den gjeldende posten fra leverandørens admin-konsoll; foretrekk CNAME-delegering |
| 4 | Feil eller manglende velger | no key for signature — oppslaget selv feiler | Publiser velgeren signereren faktisk bruker — se velger-veiledningen |
| 5 | Skjør canonicalization eller en l=-tagg | Periodiske feil på trivielt reformaterte meldinger | c=relaxed/relaxed; fjern l= fullstendig |
Årsak 1 er uthevet fordi den bryter signaturer på meldinger som ble signert perfekt. En sikkerhetsgateeway legger til en ansvarsfraskrivelse, en samsvarsbunntekst stemples på etter signering, en e-postliste legger til [listenavn] i emnet — kroppen eller signerte overskrifter endres, hashene samsvarer ikke lenger, og signaturen er ugyldig uten noen feil i DNS. Hvis feil korrelerer med e-post som passerte gjennom en gateway, en liste eller et arkiveringshop, begynn der.
Hvordan fikser jeg «DKIM-signatur ikke gyldig»?
- Kjør den gratis skanningen på defaults.exposed før du rører DNS. Den viser om den publiserte nøkkelposten er til stede, velformet og komplett — og skiller «DNS er ødelagt» (årsaker 2–4) fra «DNS er fin, meldingen endres» (årsak 1) i ett steg.
- Les
Authentication-Results-overskriften fra en mislykket melding.body hash did not verify→ årsak 1, gå til body-hash-veiledningen — de vanlige mistenkte er gateway-bunntekster og ansvarsfraskrivelser, og fiksen er å signere etter endringen.no key for signature→ årsak 4, gå til velger-veiledningen. En ren signaturfeil → fortsett. - Sjekk den publiserte nøkkelen for avkutting. Slå opp
<velger>._domainkey.<dittdomene>som TXT (dig TXT velger._domainkey.eksempel.com). En 2048-bit RSA-offentlig nøkkel er lengre enn 255-tegns grensen for én enkelt TXT-streng, så den må publiseres som multiple siterte strenger som mottakere sammenkjeder — og DNS-leverandørers nettgrensesnitt er beryktet for å stille avkutte limet, ødelegge splittingen, eller injisere mellomrom og anførselstegn ip=-verdien. Sammenlign tegn for tegn med nøkkelen signereren genererte; våre DKIM-oppsettsveiledninger dekker per-leverandør-særegenhetene. - Bekreft at den publiserte nøkkelen samsvarer med signereren. Etter en nøkkelrotasjon, leverandørmigrering eller ESP-gjenkobling er det vanlig at signereren holder en ny privat nøkkel mens DNS fortsatt serverer den gamle offentlige nøkkelen — alle signaturer bekreftes mot feil nøkkel og feiler. Kopier den gjeldende posten fra leverandørens admin-konsoll. Bedre: der leverandøren tilbyr CNAME-delegering, bruk det — leverandøren roterer nøkler på sin side og hele denne klassen av feil forsvinner. Og slett aldri en gammel velger før trafikk signert med den er drenert.
- Fiks signeringsinnstillingene, ikke bare posten. Sett canonicalization til
c=relaxed/relaxed, som tåler mellomrom-omviklings og overskrift-omfolding som mellomservere legitimt gjør;simplecanonicalization feiler på endringer et menneske ikke engang kan se. Og ikke brukl=body-length-taggen: den var ment å la bunntekster gjennom, men den lar hvem som helst legge til innhold til den signerte meldingen din uten å bryte signaturen — et reelt angrepsvektort — og den overlever fortsatt ikke de fleste gateway-endringer. Ingenl=er både det tryggere og det mer pålitelige valget. - Skann på nytt, og sjekk deretter justering. En gyldig signatur hjelper bare DMARC hvis
d=-domenet er justert med Fra-domenet ditt — en signatur som validerer somd=dittselskap.gappssmtp.combestår DKIM og feiler fortsatt DMARC. Hvis det er deg, se standard-signatur-fellen, og arbeid deretter gjennom alt annet skanningen flagger på siden fiks DKIM.
Ofte stilte spørsmål
Er «DKIM-signatur ikke gyldig» det samme som «body hash did not verify»? Body-hash-meldingen er ett spesifikt undertilfelle: kroppen endret seg etter signering (bunntekster, ansvarsfraskrivelser, liste-omskrivinger). «Signatur ikke gyldig» er paraply-dommen for enhver mislykket bekreftelse, inkludert dårlige nøkler og overskrift-endringer — det er grunnen til at trinn 2 over handler om å lese overskriften, og grunnen til at body-hash-tilfellet har sin egen veiledning.
Betyr en ugyldig DKIM-signatur at e-posten min avvises? Ikke i seg selv — mottakere behandler en ødelagt signatur som en manglende en. Skaden lander via DMARC: hvis SPF ikke bestås med justering heller, feiler meldingen DMARC og din publiserte policy gjelder. Per 2026-06-29-sensus holder bare 3.87% av 261,086,232 graderte domener SPF, DKIM og en håndhevende DMARC-policy samlet — men Gmail og Microsoft forventer nå nøyaktig det fra avsendere, så et ødelagt DKIM-bein koster leveringsevne selv før avvisning.
Bør jeg bruke en 1024-bit eller 2048-bit DKIM-nøkkel? 2048-bit — 1024-bit nøkler er under gjeldende kryptografiske anbefalinger og noen mottakere score dem ned. Fangsten er rent operasjonell: en 2048-bit nøkkel passer ikke i én 255-tegns TXT-streng, så den må splittes riktig (årsak 2 over). CNAME-delegering til leverandøren omgår splittingsproblemet fullstendig.
DKIM er OK på en sjekketjeneste men DMARC feiler fortsatt — hvorfor?
Nesten sikkert justering: signaturen validerer, men d=-domenet (f.eks. dittselskap.gappssmtp.com eller dittleietaker.onmicrosoft.com) samsvarer ikke med Fra-domenet ditt, så DMARC kan ikke bruke den. Aktiver leverandørens egendefinerte-domene-signering — den fulle gjennomgangen er i standard-signatur-fellen-veiledningen.
Kan jeg bare slå av DKIM hvis det fortsetter å feile? Nei — siden 2024 bulkavsender-mandatene krever Gmail og Yahoo DKIM for volum-avsendere, og en håndhevende DMARC-policy trenger realistisk DKIM fordi SPF alene bryter ved videresending. Fiks signaturen; årsakene over er alle fikserbare på en ettermiddag.
Send eieren rapporten
Hvis du fikser dette for en klient eller arbeidsgiveren din, lukk løkken med bevis. Kjør den gratis skanningen etter endringene dine og videresend den graderte rapporten til bedriftseieren: datert, på enkelt norsk, DKIM viser grønt. Det er artefakten de vil trenge til fornyelse av cyberforsikring og neste leverandørsikkerhetsspørreskjema — forskjellen mellom «Jeg fikset noe DNS» og dokumentert før-og-etter som sier at domenet autentiserer e-posten sin.
Sjekk domenet ditt → · «Body hash did not verify»-veiledning → · Fiks DKIM → · Hvordan vi graderer → · Kun aggregerte data. Data lagret og behandlet i EU.