Defaults.Exposed › Korjaukset › Guides

"DKIM-allekirjoitus ei kelpaa" — Syyt tarkistettavassa järjestyksessä (2026)

Julkaistu 2026-07-08

Luvut 2026-06-29 alkaen · metodologia v7. Koottu väestönlaskentatiedot 261 miljoonan arvioidun verkkotunnuksen yli. Katso kuinka arvioimme.

“DKIM signature not valid” -virheellä on viisi yleistä syytä, parhaiten järjestyksessä tarkistettuna: siirron aikana muokattu sisältö, katkaistu avaintietue, julkaistu avain, joka ei vastaa allekirjoittajaa, väärä valitsin ja hauras kanonisaatio. Vain 10,092,481 261,086,232:sta arvioidusta verkkotunnuksesta (3.87%) omistaa täydellisen SPF + DKIM + valvova-DMARC -kolmikon Defaults.Exposed-väestönlaskennan mukaan (2026-06-29).

Korjausjärjestys on tärkeä, koska yleisin syy ei ole lainkaan DNS:ssäsi. Tarkista ensin, mikä muutti viestin siirron aikana, sitten työskentele sisäänpäin: avaintietueen eheys, vastaako se sitä, millä postipalvelimesi todella allekirjoittaa, valitsinta, ja lopuksi allekirjoitusasetuksia. Useimmat kelvottomat allekirjoitukset korjataan vaiheessa yksi tai kaksi.

Mitä “DKIM signature not valid” oikeasti tarkoittaa?

Jokainen DKIM-allekirjoitettu viesti kantaa DKIM-Signature-otsikkoa, joka nimeää verkkotunnuksen (d=), valitsimen (s=), tiivisteen viestin rungosta (bh=) ja salaustiivisteen runkohashin plus valituista otsikoista (b=). Vastaanottaja hakee julkisen avaimesi DNS:stä osoitteesta <selector>._domainkey.<domain>, laskee molemmat tiivisteet uudelleen ja tarkistaa allekirjoituksen (RFC 6376). “Signature not valid” on tarkistustyökalujen ja otsikoiden ilmaisu sille: kyseinen tarkistus suoritettiin ja epäonnistui — avain löytyi, mutta matematiikka ei toiminut.

Tämä viimeinen lause on diagnostinen kulta. Todentaja, joka ei löydä avaintasi, sanoo jotain muuta — tyypillisesti otsikko kuten dkim=fail (no key for signature) — ja se on valitsimen ongelma, käsitelty kohdassa DKIM “no key for signature” — valitsimen ja kierrätyksen korjaukset. Ja todentaja, joka laskee erilaisen runkohashin, sanoo yleensä sen eksplisiittisesti: body hash did not verify — Microsoft raportoi sen dkim=fail (body hash did not verify) -muodossa, kun taas Gmail renderöi saman diagnoosin usein dkim=neutral (body hash did not verify) -muodossa. Joka tapauksessa se osoittaa sisältömuokkaukseen, käsitelty kohdassa “body hash did not verify” — mikä muutti viestiäsi. Lue Authentication-Results-otsikon täsmällinen sanamuoto ennen kuin kosket mihinkään: se kertoo, mitä viidestä syystä sinulla on.

Tämän oikein saaminen on harvinaista: vain 51.84% arvioiduista verkkotunnuksista julkaisee löydettävän DKIM-avaimen DNS:ssä lainkaan Defaults.Exposed-väestönlaskennan mukaan, ja vain 3.87% 261 miljoonasta arvioidusta verkkotunnuksesta yhdistää SPF:n, DKIM:n ja valvovan DMARC-käytännön — konfiguraatio, jonka massalähettäjäsäännöt nyt olettavat. Vaihekuva on kohdassa SPF-käyttöönotto-kypsyysmalli.

Mitkä ovat viisi syytä järjestyksessä?

Syy 1 on lihavoitu, koska se rikkoo allekirjoitukset viesteissä, jotka allekirjoitettiin täydellisesti. Tietoturvayhdyskäytävä lisää vastuuvapauslausekkeen, vaatimustenmukaisuuden alatunniste leimataan allekirjoittamisen jälkeen, postituslistalle lisätään [listname] aiheeseen — runko tai allekirjoitetut otsikot muuttuvat, tiivisteet eivät enää täsmää, ja allekirjoitus on kelvoton DNS:ssäsi olevan vian sijaan. Jos epäonnistumiset korreloivat yhdyskäytävän, listan tai arkistointihypyn kautta kulkeneen postin kanssa, aloita sieltä.

Miten korjaan “DKIM signature not valid” -virheen?

1. Aja ilmainen tarkistus osoitteessa defaults.exposed ennen kuin kosket DNS:ään. Se näyttää, onko julkaistu avaintietueesi läsnä, hyvin muodostettu ja täydellinen — erottaen “DNS:si on rikki” (syyt 2–4) tilanteesta “DNS:si on kunnossa, viesti muutetaan” (syy 1) yhdessä vaiheessa.
2. Lue epäonnistuvan viestin Authentication-Results-otsikko. body hash did not verify → syy 1, mene runkohashin oppaaseen — tavalliset epäillyt ovat yhdyskäytävän alatunnisteet ja vastuuvapauslausekkeet, ja korjaus on allekirjoittaa muutoksen jälkeen. no key for signature → syy 4, mene valitsimen oppaaseen. Pelkkä allekirjoitusepäonnistuminen → jatka.
3. Tarkista julkaistu avain katkaisun varalta. Hae <selector>._domainkey.<yourdomain> TXT:nä (dig TXT selector._domainkey.example.com). 2048-bittinen RSA-julkinen avain on pidempi kuin yksittäisen TXT-merkkijonon 255 merkin raja, joten se täytyy julkaista useina lainausmerkeillä merkittyinä merkkijonoina, jotka vastaanottajat yhdistävät — ja DNS-palveluntarjoajien verkkokäyttöliittymät ovat tunnetusti hiljaa katkaisevia liitettyjä, vääristämässä jakoa tai ruiskuttamassa välilyöntejä ja lainausmerkkejä p=-arvoon. Vertaa merkki merkiltä allekirjoittajasi tuottamaan avaimeen; DKIM-asennusläpikäyntimme kattavat palveluntarjoajakohtaiset oikukkuudet.
4. Vahvista, että julkaistu avain vastaa allekirjoittajaa. Avainenkierrätyksen, palveluntarjoajan migraation tai ESP-yhteyden muodostamisen jälkeen on yleistä, että allekirjoittajalla on uusi yksityinen avain, kun DNS edelleen tarjoilee vanhan julkisen avaimen — jokainen allekirjoitus tarkistetaan väärää avainta vasten ja epäonnistuu. Kopioi nykyinen tietue uudelleen palveluntarjoajasi hallintakonsolista. Parempi: kun palveluntarjoaja tarjoaa CNAME-delegoinnin, käytä sitä — palveluntarjoaja kierrättää avaimia omalla puolellaan ja tämä koko epäonnistumisluokka katoaa. Äläkä koskaan poista vanhaa valitsinta ennen kuin sen allekirjoittama liikenne on tyhjennetty.
5. Korjaa allekirjoitusasetukset, ei vain tietue. Aseta kanonisaatioksi c=relaxed/relaxed, joka sietää välilyöntien uudelleenrivitystä ja otsikon uudelleentaittamista, joita välipalvelimet laillisesti tekevät; simple-kanonisaatio epäonnistuu muutoksilla, joita ihminen ei edes näe. Äläkä käytä l= body-length -tunnistetta: se oli tarkoitettu sallimaan alatunnisteet, mutta se antaa kenelle tahansa liittää sisältöä allekirjoitettuun viestiisi rikkomatta allekirjoitusta — todellinen hyökkäysvektori — eikä se silti selviä useimmista yhdyskäytävämuokkauksista. Ei l=:ää on sekä turvallisempi että luotettavampi valinta.
6. Aja tarkistus uudelleen, sitten tarkista kohdistuminen. Kelpaava allekirjoitus auttaa DMARC:ia vain, jos d=-verkkotunnus kohdistuu From-verkkotunnukseesi — allekirjoitus, joka vahvistuu d=yourcompany.gappssmtp.com:na, läpäisee DKIM:n ja epäonnistuu silti DMARC:ssa. Jos tämä on sinun tilanteesi, katso oletusallekirjoituksen ansa, sitten käy läpi kaikki muut tarkistuksen merkitsemät ongelmat korjaa DKIM -sivulla.

Usein kysytyt kysymykset

Onko “DKIM signature not valid” sama kuin “body hash did not verify”? Runkohashin viesti on yksi spesifinen alakohta: runko muuttui allekirjoittamisen jälkeen (alatunnisteet, vastuuvapauslausekkeet, listojen uudelleenkirjoitukset). “Signature not valid” on yleis­tuomio mille tahansa epäonnistuneelle tarkistukselle, mukaan lukien virheelliset avaimet ja otsikkomuutokset — siksi askel 2 on otsikon lukeminen, ja siksi runkohashin tapauksella on oma oppaansa.

Tarkoittaako kelvoton DKIM-allekirjoitus, että postini hylätään? Ei itsessään — vastaanottajat käsittelevät rikki olevan allekirjoituksen kuten puuttuvan. Vahinko tapahtuu DMARC:n kautta: jos SPF ei myöskään läpäise kohdistamisella, viesti epäonnistuu DMARC:ssa ja julkaisemasi käytäntö soveltuu. 2026-06-29 väestönlaskennan mukaan vain 3.87% 261,086,232:sta arvioidusta verkkotunnuksesta omistaa SPF:n, DKIM:n ja valvovan DMARC-käytännön yhdessä — mutta Gmail ja Microsoft odottavat juuri sitä lähettäjiltä, joten rikki oleva DKIM-jalka maksaa toimitettavuudessa jo ennen hylkäystä.

Pitäisikö minun käyttää 1024-bittistä vai 2048-bittistä DKIM-avainta? 2048-bittistä — 1024-bittiset avaimet ovat nykyisten salaussuositusten alapuolella ja jotkut vastaanottajat pisteyttävät ne alemmaksi. Ainoa käytännöllinen ongelma on operatiivinen: 2048-bittinen avain ei mahdu yhteen 255 merkin TXT-merkkijonoon, joten se täytyy jakaa oikein (yllä oleva syy 2). CNAME-delegointi palveluntarjoajallesi ohittaa jaon ongelman kokonaan.

DKIM:ni läpäisee tarkistustyökalussa, mutta DMARC epäonnistuu — miten? Lähes varmasti kohdistuminen: allekirjoitus on kelpaava, mutta sen d=-verkkotunnus (esim. yourcompany.gappssmtp.com tai yourtenant.onmicrosoft.com) ei vastaa From-verkkotunnustasi, joten DMARC ei voi käyttää sitä. Ota käyttöön palveluntarjoajasi mukautetun verkkotunnuksen allekirjoittaminen — täydellinen läpikäynti on kohdassa oletusallekirjoituksen ansaopas.

Voinko vain kytkeä DKIM:n pois, jos se jatkaa epäonnistumista? Ei — vuoden 2024 massalähettäjämandaattien jälkeen Gmail ja Yahoo vaativat DKIM:n volyymilähettäjiltä, ja valvova DMARC-käytäntö tarvitsee realistisesti DKIM:n, koska SPF yksin hajoaa edelleenlähetyksessä. Korjaa allekirjoitus; yllä olevat syyt ovat kaikki korjattavissa yhden iltapäivän aikana.

Lähetä omistajalle raportti

Jos korjaat tätä asiakkaan tai työnantajasi puolesta, sulje silmukka todisteella. Aja ilmainen tarkistus muutosten jälkeen ja välitä arvioitu raportti liike-elämän omistajalle: päivätty, selkokielinen, DKIM näyttää vihreää. Se on artefakti, jota he tarvitsevat kyberturvallisuusvakuutuksen uusinnassa ja seuraavassa toimittajan turvallisuuskyselyssä — ero “korjasin DNS-asian” ja dokumentoidun ennen-ja-jälkeen -raportin välillä, joka sanoo verkkotunnuksen todentavan postinsa.

Tarkista verkkotunnuksesi → · “Body hash did not verify” -opas → · Korjaa DKIM → · Kuinka arvioimme → · Vain koottua tietoa. Tiedot tallennetaan ja käsitellään EU:ssa.