Luotettavin paikka löytää a DKIM valitsin on DKIM-Signature tutkimasi viestin otsikko. Lue s=-arvo ja yhdistä se d=-allekirjoitusalueen kanssa samasta allekirjoituksesta.
Valitsija tunnistaa, missä varmistusmateriaali julkaistaan. Se ei tunnista näkyvää lähettäjää tai todista, että allekirjoitus on mennyt läpi. Tämä opas seuraa todisteita vastaanotetusta viestistä oikeaan DNS nimeen ja selittää sitten, mitä haku voi määrittää ja mitä ei.
Hanki alkuperäinen vastaanotettu viesti
Käytä ohjattua viestiä, joka lähetetään varsinaisen palvelun kautta erilliselle vastaanottajalle. Säilytä alkuperäinen viesti sellaisena kuin se vastaanotettiin siellä. Edelleen lähetetystä kuvakaappauksesta tai uudelleen tallennetusta, muokatusta viestistä voidaan jättää pois tai muuttaa todisteita.
Paikanna jokainen DKIM-Signature otsikko. Viesti voi sisältää useamman kuin yhden. Tallenna jokaiselle allekirjoitukselle sen allekirjoitusalue ja valitsin erikseen ja korreloi sitten luotettavan vastaanottajan vahvistustulos.
- d: allekirjoitustoimialue.
- s: valitsin.
- a: allekirjoitus/hajautusalgoritmi.
- h: valittu allekirjoitettu otsikkoluettelo.
- bh ja b: body hash ja allekirjoitusarvot, ei DNS -julkisen avaimen tietueita.
Nämä kentät määrittelee RFC 6376 §3.5.
Älä korvaa näkyvää Lähettäjä-verkkotunnusta d= kun rakennat avainhakua. Tasaus on myöhempi vertailu ohimenevän allekirjoitusidentiteetin ja näkyvän From-identiteetin välillä.
Luo ja kysy vahvistuksen nimi
Under RFC 6376 §3.6.2.1, vahvistusnimi yhdistää kaksi arvoa samasta allekirjoituksesta:
<valitsin>. _domainkey .<signing-domain>
Tässä synteettisessä esimerkissä allekirjoitus tunnistaa:
Synteettisessä allekirjoituksessa on d=example.com ja s=mail2026.
Vastaava haku on:
dig TXT mail2026._domainkey.example.com +noall +answer
Jos palveluntarjoaja delegoi avainten hallinnan a CNAME, tarkista myös tämä ketju:
dig CNAME mail2026._domainkey.example.com +noall +answer
Nämä ovat havainnollistavia DNS tarkistuksia, eivät siepatun oikean viestin vahvistusta. Käytä todellisia allekirjoitusarvoja. Under RFC 1034 §3.6.2, jos kyseessä on julkaistu alias, noudata aiottua tavoitetta ja varmista, että varmennustiedot ovat saatavilla ketjun kautta.
Julkinen DNS sisältää vahvistusavaimen materiaalin tai siihen johtavan delegoinnin. Yksityinen allekirjoitusavain kuuluu valtuutettuun allekirjoitusjärjestelmään, ei a TXT tietue.
Tulkitse hakua vahvistustulosten rinnalla
Julkisen avaimen vastaus osoittaa, että ratkaiseja voi hakea tiettyä varmennusmateriaalia tuolloin. Se ei todista, että viesti sisältää allekirjoituksen, että vastaavaa yksityistä avainta on käytetty oikein tai että allekirjoitettu sisältö pysyi ehjänä.
Jos avain on olemassa, mutta allekirjoitus epäonnistuu, tutki täydellinen vahvistustulos. Sisällön muutokset, virheelliset tai yhteensopimattomat avaintiedot, allekirjoituksen kattavuus, aikaan liittyvät ehdot ja DNS havainnot voivat vaatia erilaisia korjaustoimenpiteitä.
Jos avainta ei löydy, tarkista tarkka d= ja s=, arvovaltainen vyöhyke, CNAME kohde, avainten poistumishistoria ja ratkaisuvirheet. Älä julkaise arvattua valitsinta vain muuttaaksesi ruudun vihreäksi.
Jos alkuperäisessä ei ole asiaankuuluvaa DKIM allekirjoitusta, valitsinhaku ei voi tuottaa allekirjoitusta. Tarkista, onko todellinen lähettäjä määritetty allekirjoittamaan, tukeeko palvelu vaadittua identiteettiä ja onko myöhempi reitti muuttanut todisteita.
Käsittele useita allekirjoituksia ja avainten kiertoa
Tee erillinen rivi jokaiselle allekirjoitukselle ja sen luotetulle tulokselle. Palvelun oma välitysallekirjoitus voi olla kohdistamaton, kun taas asiakkaan verkkotunnuksen allekirjoitus läpäisee kohdistuksen. Toisessa viestissä voi olla epäonnistunut asiakas-verkkotunnuksen allekirjoitus ja vain asiaankuulumaton ohittava allekirjoitus.
Tarkista kiertoa varten, mitä valitsinta oikea viesti käytti, ei vain sitä, mitkä kaksi tietuetta ovat saatavilla DNS ssä. Säilytä määritystilan, allekirjoituksen katkaisun ja jo siirrettyjen viestien välinen suhde. Vanhan valitsimen käytöstä poistaminen voi vaikuttaa tallennettujen tai viivästyneiden viestien myöhempään varmentamiseen.
Käytä Microsoft 365 :ssä vuokralainenkohtainen asennusopas. Käytä työtilaa varten valitun verkkotunnuksen asennusopas. Kummankaan palveluntarjoajan yhteinen valintamalli ei saa korvata todellisten todisteiden lukemista.
Vahvista kirjautuminen todelliseen palveluun
Jos toimittaja sanoo, että verkkotunnuksellasi on DKIM määritetty, pyydä sitä näyttämään asianomaisen työnkulun lähettämä viesti ja sen todellisuudessa allekirjoittanut toimialue. Julkisesti näkyvä avain on yksi kokoonpanoriippuvuus, ei todiste live-allekirjoituksesta.
Tällä on merkitystä, kun useat työkalut käyttävät samaa näkyvää merkkiä. Työntekijöiden posteilla, tukikuitteilla ja kuiteilla voi olla eri valitsimia, allekirjoitusalueita ja omistajia. Yhden onnistunut tarkistus ei voi kestää muita.
Pidä kirjaa omistajuuden ja delegoinnin allekirjoittamisesta
Pidä valitsinvarasto sidottuina palveluun, verkkotunnukseen, avaintenhallintamalliin ja yrityksen omistajaan. Erottele avaimen suora hallinta delegoinnista toimittajalle. Tarkista valtuutus, kun palvelu on pois käytöstä.
Rajoita yksityisen avaimen käyttöä ja määritä vastaus epäiltyyn kompromissiin. Voimassa oleva julkinen asiakirja ei ole todiste siitä, että avainten säilytys on kunnossa. Samoin kelvollinen allekirjoitus muodostaa toimialuetason väitteen peitetylle sisällölle; se ei hyväksy maksupyyntöä tai sulje pois tilin vaarantumista.
Hyödyllinen todisteketju on viesti, allekirjoituksen identiteetti, avaimen haku, luotettava vahvistus ja kohdistus. Pidä nämä havainnot yhdessä, jotta seuraava arvioija voi toistaa diagnoosin.
Käytännön takeaway
Säilytä alkuperäinen viesti, allekirjoitusidentiteetit, DNS havainto ja luotetun vastaanottajan tulos yhdessä. Tämä todiste erottaa puuttuvan avaimen allekirjoittamattomasta viestistä, epäonnistuneesta allekirjoituksesta tai allekirjoituksesta, joka läpäisee mutta ei kohdista.
Käytä eroa
Kahdella hypoteettisella allekirjoituksella, d=example.com/s=mail2026 ja d=service.example.net/s=outbound, tee kysely mail2026._domainkey.example.com ja outbound._domainkey.service.example.net erikseen. Älä koskaan yhdistä mail2026:ta toiseen d. Pidä jokainen hakuaika ja luotettava tulos sen parin rinnalla. Myöhemmin puuttuva avain ei poista aikaisempaa luotettavaa vastaanottimen havaintoa.