Defaults.Exposed › Åtgärder › Guides

"DKIM-signatur ogiltig" — Orsakerna, i den ordning att kontrollera dem (2026)

Publicerad 2026-07-08

Siffror från 2026-06-29 · metodik v7. Aggregerade censusdata över 261 miljoner graderade domäner. Se hur vi graderar.

“DKIM-signatur ogiltig” har fem vanliga orsaker, bäst kontrollerade i ordning: innehåll ändrat under transit, en trunkerad nyckelpost, en publicerad nyckel som inte matchar undertecknaren, fel selektor och bräcklig kanonisering. Bara 10,092,481 av 261,086,232 graderade domäner (3.87%) håller den fullständiga SPF + DKIM + tillämpande-DMARC-triaden, enligt Defaults.Exposed-censuset (2026-06-29).

Åtgärdsordningen spelar roll eftersom den vanligaste orsaken inte alls är i din DNS. Kontrollera vad som ändrade meddelandet under transit först, arbeta sedan inåt: nyckelpostens integritet, om den matchar vad din e-postserver faktiskt signerar med, selektorn och slutligen signeringsinställningarna. De flesta ogiltiga signaturer åtgärdas i steg ett eller två.

Vad betyder “DKIM-signatur ogiltig” egentligen?

Varje DKIM-signerat meddelande bär en DKIM-Signature-rubrik som namnger en domän (d=), en selektor (s=), en hash av meddelandekroppen (bh=), och en kryptografisk signatur över body-hashen plus valda rubriker (b=). Mottagaren hämtar din publika nyckel från DNS på <selektor>._domainkey.<domän>, beräknar om båda hasharna och kontrollerar signaturen (RFC 6376). “Signatur ogiltig” är kontrollanters och rubrikers sätt att säga: den verifieringen kördes och misslyckades — nyckeln hittades, men matematiken stämde inte.

Den sista satsen är diagnostikguldet. En verifierare som inte kan hitta din nyckel säger något annat — vanligtvis en rubrik som dkim=fail (no key for signature) — och det är ett selekorproblem, täckt i DKIM “ingen nyckel för signatur” — selektor- och rotationsfixar. Och en verifierare som beräknar om en annan body-hash säger det vanligtvis explicit: body hash did not verify — Microsoft rapporterar det som dkim=fail (body hash did not verify), medan Gmail ofta renderar samma diagnos som dkim=neutral (body hash did not verify). Hur som helst pekar det på innehållsändring, täckt i “body hash did not verify” — vad som ändrade ditt meddelande. Läs den exakta formuleringen i Authentication-Results-rubriken innan du rör något: den talar om vilken av de fem orsakerna du håller i.

Att göra detta rätt är sällsynt: bara 51.84% av graderade domäner publicerar en synlig DKIM-nyckel i DNS överhuvudtaget, enligt Defaults.Exposed-censuset, och bara 3.87% av 261 miljoner graderade domäner kombinerar SPF, DKIM och en tillämpad DMARC-policy — konfigurationen som bulk-avsändarreglerna nu förutsätter. Steg-för-steg-bilden finns i SPF-adoptionsmognadsmodellen.

Vilka är de fem orsakerna, i ordning?

Orsak 1 är fetstilad eftersom den bryter signaturer på meddelanden som signerades perfekt. En säkerhetsgateway lägger till en ansvarsfriskrivning, en efterlevnadssidfot stämplas på efter signering, en e-postlista lägger till [listnamn] i ämnet — kroppen eller de signerade rubrikerna ändras, hasharna matchar inte längre, och signaturen är ogiltig utan fel i din DNS. Om misslyckanden korrelerar med e-post som passerade genom en gateway, en lista eller ett arkiveringshopp, börja där.

Hur åtgärdar jag “DKIM-signatur ogiltig”?

1. Kör den kostnadsfria sökningen på defaults.exposed innan du rör DNS. Den visar om din publicerade nyckelpost är närvarande, välformad och komplett — separerar “din DNS är trasig” (orsak 2–4) från “din DNS är fine, meddelandet ändras” (orsak 1) i ett steg.
2. Läs Authentication-Results-rubriken för ett misslyckat meddelande. body hash did not verify → orsak 1, gå till body-hash-guiden — de vanliga misstänkta är gateway-sidfötter och ansvarsfriskrivningar, och fixen är att signera efter ändringen. no key for signature → orsak 4, gå till selektor-guiden. Ett enkelt signaturfel → fortsätt.
3. Kontrollera den publicerade nyckeln för trunkering. Slå upp <selektor>._domainkey.<dindomän> som TXT (dig TXT selector._domainkey.example.com). En 2048-bitars RSA-publik nyckel är längre än 255-teckengränsen för en enstaka TXT-sträng, så den måste publiceras som flera citerade strängar som mottagare sammanfogar — och DNS-leverantörers webb-UI:er är kända för att tyst trunkera inklistringen, förvanska uppdelningen eller injicera blanksteg och citattecken i p=-värdet. Jämför tecken för tecken med nyckeln din undertecknare genererade; våra DKIM-konfigurationsguider täcker per-leverantör-egenheterna.
4. Bekräfta att den publicerade nyckeln matchar undertecknaren. Efter en nyckelrotation, leverantörsmigrering eller ESP-återanslutning är det vanligt att undertecknaren håller en ny privat nyckel medan DNS fortfarande serverar den gamla publika nyckeln — varje signatur verifieras mot fel nyckel och misslyckas. Kopiera om den aktuella posten från din leverantörs administratörskonsol. Bättre: där leverantören erbjuder CNAME-delegering, använd den — leverantören roterar nycklar på sin sida och hela den här klassen av fel försvinner. Och radera aldrig en gammal selektor tills trafik signerad med den har tömt sig.
5. Åtgärda signeringsinställningarna, inte bara posten. Sätt kanonisering till c=relaxed/relaxed, vilket tolererar blankstegsomslagning och rubrikombrytning som mellanservrar legitimt gör; simple-kanonisering misslyckas på ändringar en människa inte ens kan se. Och använd inte l=-body-length-taggen: den var tänkt att låta sidfötter igenom, men den låter vem som helst lägga till innehåll till ditt signerade meddelande utan att bryta signaturen — en verklig attackvektor — och den överlever fortfarande inte de flesta gateway-ändringar. Ingen l= är både det säkrare och mer tillförlitliga valet.
6. Scanna igen, kontrollera sedan anpassning. En giltig signatur hjälper bara DMARC om d=-domänen anpassas till din From-domän — en signatur som valideras som d=yourcompany.gappssmtp.com godkänner DKIM och misslyckas fortfarande med DMARC. Om det är du, se standardsignatursfällan, arbeta sedan igenom allt annat som sökningen flaggar på sidan åtgärda DKIM.

Vanliga frågor

Är “DKIM-signatur ogiltig” detsamma som “body hash did not verify”? Body-hash-meddelandet är ett specifikt underfall: kroppen ändrades efter signering (sidfötter, ansvarsfriskrivningar, listomskrivningar). “Signatur ogiltig” är paraplydomet för alla misslyckade verifieringar, inklusive dåliga nycklar och rubrikändringar — det är därför steg 2 ovan handlar om att läsa rubriken, och varför body-hash-fallet har sin egen guide.

Innebär en ogiltig DKIM-signatur att min e-post avvisas? Inte i sig — mottagare behandlar en bruten signatur som en saknad. Skadan landar via DMARC: om SPF inte heller godkänns med anpassning misslyckas meddelandet med DMARC och din publicerade policy tillämpas. Per 2026-06-29-censuset håller bara 3.87% av 261,086,232 graderade domäner SPF, DKIM och en tillämpad DMARC-policy tillsammans — men Gmail och Microsoft förväntar sig nu exakt det från avsändare, så ett brutet DKIM-ben kostar leveransbarhet redan innan avvisning.

Ska jag använda en 1024-bitars eller 2048-bitars DKIM-nyckel? 2048-bitars — 1024-bitarsnycklar är under aktuella kryptografirekommendationer och vissa mottagare poängsätter dem lägre. Fångsten är rent operativ: en 2048-bitarsnyckel passar inte i en 255-teckens TXT-sträng, så den måste delas korrekt (orsak 2 ovan). CNAME-delegering till din leverantör kringgår delningsproblemet helt.

Min DKIM godkänns på en kontrollant men DMARC misslyckas fortfarande — hur? Nästan säkert anpassning: signaturen valideras, men dess d=-domän (t.ex. yourcompany.gappssmtp.com eller yourtenant.onmicrosoft.com) matchar inte din From-domän, så DMARC kan inte använda den. Aktivera din leverantörs anpassade domänsignering — den fullständiga genomgången finns i standardsignatursfällan-guiden.

Kan jag bara stänga av DKIM om det fortsätter misslyckas? Nej — sedan bulk-avsändarmandat 2024 kräver Gmail och Yahoo DKIM för volymhöga avsändare, och en tillämpad DMARC-policy behöver realistiskt DKIM eftersom SPF ensamt bryter under vidarebefordring. Åtgärda signaturen; orsakerna ovan är alla åtgärdbara under en eftermiddag.

Skicka ägaren rapporten

Om du åtgärdar detta för en kund eller din arbetsgivare, avsluta loopen med bevis. Kör om den kostnadsfria sökningen efter dina ändringar och vidarebefordra den graderade rapporten till företagsägaren: daterad, klarspråk, DKIM visar grönt. Det är artefakten de behöver för förnyelse av cyberförsäkring och nästa leverantörs säkerhetsenkät — skillnaden mellan “jag åtgärdade ett DNS-problem” och en dokumenterad före-och-efter som säger att domänen autentiserar sin e-post.

Kontrollera din domän → · “Body hash did not verify”-guiden → · Åtgärda DKIM → · Hur vi graderar → · Enbart aggregerade data. Data lagras och behandlas inom EU.