Alatunniste voi muuttaa oikein allekirjoitetun lähtevän viestin a DKIM epäonnistuminen. Korjaus alkaa käsittelysekvenssillä: tunnista, mikä järjestelmä allekirjoitti viestin, mikä järjestelmä lisäsi alatunnisteen ja minkä allekirjoituksen vastaanottaja arvioi. Toisen DNS avaimen julkaiseminen ei voi lisätä allekirjoituksen kansitekstiä sen luomisen jälkeen.
Todista mitkä tavut muuttuivat
Tallenna ohjattu viesti heti allekirjoittamisen jälkeen ja toinen yhdyskäytävän jälkeen käyttämällä raakaviestien vientiä sähköpostiohjelmasta kopioidun tekstin sijaan. Säilytä alkuperäiset tiedostot. Tallenna jokaisen allekirjoituksen d, s, c, h ja kaikki l-tunnisteet. Viestissä voi olla useita allekirjoituksia, joilla on eri kattavuus ja tulokset.
DKIM laskee kanonisoidun kappaleen tiivisteen. Tavallisessa koko kehon peitossa uusi alatunniste lisää sisältöä ja muuttaa tiivistettä. Rento kroppa kanonisointi poistaa tietyt välilyönnit; se ei poista vastuuvapauslauseketta, HTML-lohkoa tai uutta MIME osaa. Runko-hajasteen epäsuhta koskee verrattuja runko-tiivistesyöttöjä ja arvoja: runkoesitystä, c/l-asetuksia ja bh-arvoa. Vioittunut tai väärin luotu bh tai allekirjoittajan/todentajan toteutusvirhe voi myös selittää yhteensopimattomuuden. Vertailu sisään RFC 6376 kohta 6.1.3 ei sinänsä todista, että portti muutti ruumiin. Yleinen allekirjoitusvirhe voi sen sijaan sisältää allekirjoitetun otsikon, avaimen haun tai allekirjoituksen syntaksin. RFC 6376 §3.4, RFC 6376 §3.7 ja RFC 6376 §6.1 kuvaile nämä erilliset tarkastukset.
Vertaa näytteitä alatunnisteen rajalla. Tarkista sekä teksti-/pelkkä- että teksti-/html-osat, MIME rajat ja siirrä koodaus. Näennäisesti identtinen näkyvä alatunniste voidaan sarjottaa eri tavalla. Jos yhdyskäytävä vaihtaa myös Aihetta, tarkista, onko Aihe lueteltu kohdassa h: pelkkä rungon korjaaminen ei palauta allekirjoitusta muutetun otsikon yli.
Testaa järjestystä arvaamisen sijaan
Esimerkki: sovellus luo laskun, lähtevä palvelin allekirjoittaa sen ja yhdyskäytävä liittää sitten oikeudellisen huomautuksen. Vastaanotin ilmoittaa sovelluksen allekirjoituksen runko-hash-erosta. Hallitussa vaihtoehdossa yhdyskäytävä liittää ilmoituksen ensin ja valtuutettu allekirjoittaja allekirjoittaa lopullisen sarjoitetun viestin. Läpäisevä tulos toisella polulla tukee järjestysdiagnoosia. Nämä ovat ehdotettuja testihavaintoja, eivät todellisen vuokralaisen tuloksia.
Käytä samoja viestimuunnelmia molemmissa poluissa, mukaan lukien HTML, pelkkä teksti ja liite. Tallenna vastaanottimen todennus tulokset luotetusta rajasta, allekirjoitusalueesta ja näkyvästä lähettäjäalueesta. Pelkästään DKIM passi ei riitä DMARC jos ohittava allekirjoitus ei ole linjassa tekijän verkkotunnuksen kanssa. Liittymätön yhdyskäytävän allekirjoitus voi varmistaa oikein ilman, että tämä kohdistettu polku on annettu.
Valitse omistama allekirjoitusraja
Tavallinen kestävä suunnittelu on tehdä tarvittavat sisältömuutokset ennen lopullista valtuutettua allekirjoitusoperaatiota. Tämä voi tarkoittaa allekirjoittajan siirtämistä myöhemmin, alatunnisteen lisäyksen siirtämistä aikaisemmin tai yhdyskäytävän määrittämistä allekirjoittamaan lopullinen viesti käyttämällä organisaation hallitsemaa toimialuetta. Vahvista tuettu toiminta ja avaimen omistajuus ennen mallin valitsemista. Älä oleta, että jokainen yhdyskäytävä tukee mukautetun verkkotunnuksen allekirjoitusta.
Jos olemassa oleva allekirjoitus on rikki, uuden kelvollisen allekirjoituksen lisääminen ei korjaa aikaisempaa. Arvioi uusi allekirjoitus sen omien ansioiden perusteella ja varmista linjaus erikseen. Älä ota body-length l -tunnistetta käyttöön vain, jotta alatunnisteet katoavat hash-laskennasta: se jättää allekirjoittamattoman jälkiliitteen ja luo kohdassa kuvatun turvaratkaisun. RFC 6376 §8.2.
Viimeistele regressiotarkastuksella
Säilytä reittikaavio, jossa näkyy viimeinen vartaloa vaihtava komponentti ja allekirjoittaja välittömästi sen jälkeen. Testaa uudelleen, kun vastuuvapauslausekesäännöt, virustentorjunta uudelleenkirjoitus tai lähtevän liikenteen reititys muuttuvat. Onnistuminen tarkoittaa, että vaadittu alatunniste on olemassa, tarkoitettu allekirjoitus varmentaa, sen toimialue täyttää suunnitellun kohdistuskäytännön ja kriittiset viestit saapuvat silti odotetun reitin kautta. Pidä palautussuunnitelma konfiguraatiomuutoksesta ilman, että pidät pakollisen oikeudellisen huomautuksen poistamista automaattisena korjaustoimena.
Käytä regression hyväksyntätietuetta
Jokaiselle synteettiselle pelkkää teksti-, HTML- ja liiteversiolle kirjaa: alatunniste läsnä; viimeinen vartaloa muuttava hop; lopullinen allekirjoittaja d/s; valittu c/h/l; luotettava vastaanottimen tulos; Tekijä Domain ja kohdistus; ja liikereitin lopputulos. Jos alatunniste puuttuu, ilmoitusvaatimus ei täyty, vaikka DKIM läpäisi. Jos alatunniste on olemassa, mutta vain riippumaton yhdyskäytävän toimialue kulkee, suunniteltu DKIM-tasausvaatimus ei täyty. Nämä ovat hyväksymiskriteerejä, eivät suoritettuja tarkastuksia.