[ DKIM ]

DKIM TXT ja CNAME julkaisu: noudata toimittajan avaintenhallintamallia

Julkaise tietuetyyppi, jota lähetyspalvelusi tukee, ja tarkista sitten sekä DNS resoluutio että vastaanotetun postin allekirjoitusidentiteetti.

EmailAuth -tutkimusryhmä

[Avainkohdat]

  • Käytä palveluntarjoajan nykyisiä luotuja nimiä, tyyppejä ja arvoja.
  • Älä yhdistä tavanomaista CNAME ja TXT -avainta yhdellä omistajalla.
  • Tarkista DNS , todelliset allekirjoitukset ja kohdistus erikseen.
Tällä sivulla

A DKIM asennus on valmis, kun palvelu allekirjoittaa tarkoitetun sähköpostin ja vastaanottaja voi vahvistaa sen. Vihreä DNS -tila ei yksin määritä kumpaakaan tulosta. Valitse TXT tai CNAME palveluntarjoajan tukemasta avainten hallintamallista sen sijaan, että käsittelisi niitä vaihdettavina tavoina avaimen liittämiseen.

Tunnista kuka hallitsee avainta

Suoraan julkaistu TXT tietue sisältää DKIM -vahvistustiedot. CNAME -järjestelyllä valitsin nimi aliakset toista DNS nimeä, jossa vahvistustietoja hallitaan. Yksityinen allekirjoitusavain kuuluu allekirjoitusjärjestelmään, ei koskaan kumpaankaan julkiseen tietueeseen. RFC 6376 §3.6 ja RFC 6376 §6.1.2 kuvaile avainten löytämistä ja hakua; DNS -aliaksen käyttäytyminen on määritelty kohdassa RFC 1034 §3.6.2.

Microsoft 365 :n mukautetun toimialueen prosessi käyttää CNAME tietueita ja vuokralaisen luomia kohteita. Sen nykyinen dokumentaatio on esimerkki siitä, miksi vanhemman kohdekuvion kopioiminen ei ole turvallista. Hanki todelliselle vuokralaiselle ja valitulle toimialueelle näytettävät arvot. Tämä esimerkki ei tarkoita, että asiaankuulumaton palvelu hyväksyy samat tietueet.

Ennen kuin muokkaat DNS , tallenna lähettävä tili, näkyvä Lähettäjältä, tarkoitettu allekirjoitusverkkotunnus, valitsimien nimet, tietuetyyppi, tarkat luodut arvot ja vastuullinen omistaja. Kysy, mikä järjestelmä suorittaa kierron ja kuka poistaa delegoinnin, kun sopimus päättyy. Jos palveluntarjoaja ei voi käyttää vaadittua allekirjoitustoimialuetta, DNS tietuetyypin muuttaminen ei luo tätä ominaisuutta.

Julkaise oikealla omistajan nimellä

Havainnollistava allekirjoitus kanssa d=example.com ja s=billing johtaa billing._domainkey.example.com. Esimerkki tunnistaa DNS omistajan nimen, ei toimivan julkisen avaimen tai tuotannon CNAME kohteen.

Tarkista, odottaako DNS -liitäntä koko nimeä vai vain laskutus. _domainkey. Jotkut liitännät lisäävät vyöhykkeen nimen. Lue tuloksena saatu omistajan nimi takaisin sen sijaan, että olettaisit, että syöttöruutu säilyttää sen. Tarkista olemassa olevat tiedot ennen nimen vaihtamista. Perinteinen CNAME ei voi olla siellä rinnakkain erillisen TXT -avaintietueen kanssa; säilytä asiaankuulumattomat valitsimet ja noudata palveluntarjoajan tukemaa siirtomenettelyä.

Jos kyseessä on TXT , julkaise tarkka julkinen arvo tuetussa esityksessä. Käytä CNAME luotua kohdetta, älä kopioitua avainta, joka löydettiin kohteesta tänään. Nykyisen avaimen kopioiminen paikallisesti voi rikkoa palveluntarjoajan myöhemmän kiertomallin. Säilytä kuvakaappaukset tai viedyt tietueet muutostietueessa, lukuun ottamatta valtuustietoja ja yksityisiä avaimia.

Tarkista resoluutio ja todellinen lähetys erikseen

Pyydä tarkkaa omistajan nimeä arvovaltaisessa DNS ssä ja tarkista sitten rekursiivinen resoluutio vastaanottajien käyttämän polun kautta. Jos kyseessä on CNAME , seuraa aliasta lopulliseen TXT -tulokseen ja tallenna aikakatkaisu tai puuttuva kohde. Salli välimuistissa olevat vanhat tiedot, mukaan lukien kielteiset vastaukset, tulkittaessa erimielisyyttä. Julkaisu ja globaali välimuistin konvergenssi ovat eri havaintoja.

Lähetä seuraavaksi valvottu viesti oikean sovelluksen kautta. Säilytä sen raakaotsikot ja luotettavan vastaanottavan järjestelmän todennustulos. Tallentaa d=, s= ja DKIM vahvistus. Tarkista linjaus näkyvällä Lähettäjä-verkkotunnuksella erikseen. Kelvollinen allekirjoitus palveluntarjoajan omistamasta toimialueesta ei välttämättä liity asiakkaan henkilöllisyyteen, jonka aiot todentaa.

Jos DNS ratkeaa, mutta sähköposti on allekirjoittamaton, tutki palvelun aktivointi ja reititys. Jos allekirjoitus nimeää toisen valitsimen, tarkista tämä valitsin sen sijaan, että muokkaat käyttämätöntä tietuetta toistuvasti. Jos vahvistus epäonnistuu sisällön muuttamisen jälkeen, TXT muuttaminen CNAME :ksi ei ole korjaus.

Pidä riippuvuus tilillä

Sulje muutos vasta, kun tietue, allekirjoittaja ja vastaanotettu todiste ovat samaa mieltä. Tallenna edellinen kokoonpano ja valtuutettu palautussuunnitelma ennen katkaisua. Lopeta lähetyksen integrointi ja poista sen vahvistusriippuvuus tietoisesti poiskytkeytyessäsi ottaen huomioon edelleen kuljetettavan laillisen postin. Älä jätä selittämätöntä palveluntarjoajan aliasta loputtomiin tai poista aktiivista valitsinta vain siksi, että sopimuslaskentataulukossa sanotaan, että palvelu on päättynyt.

DKIM DNS n delegointi: arvioi palveluntarjoajalle myönnetyn hallinnan laajuutta · Julkisen avaimen DKIM -syntaksi: Tunnista katkaistut tai väärin muotoillut DNS arvot.

Käytä eroa

Käytä kolmiosaista hyväksyntietuetta: julkaistu omistaja/tyyppi/arvo ja tarkkailuaika; tosiasiallisesti vastaanotettu d/s ja luotettava vahvistus; kohdistus aiotun tekijän verkkotunnuksen kanssa. Jos DNS on oikea, mutta posti on allekirjoittamaton, tutki aktivointia tai reitin valintaa tietuetyypin muuttamisen sijaan. Jos eri valitsin lähetetään, noudata näitä todisteita. Tarkistuslista on ehdotettu tarkistustyö, ei suoritettu DNS tai sähköpostitesti.

[ Takeaway ]

Käytä palveluntarjoajan nykyisiä luotuja nimiä, tyyppejä ja arvoja. Älä yhdistä tavanomaista CNAME ja TXT -avainta yhdellä omistajalla. Tarkista DNS , todelliset allekirjoitukset ja kohdistus erikseen.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

Valitse roolisi ja seuraa käytännön toimia.

IT / Mail Admin

Testaa koko polku.

DNS julkaisu ja varsinaisen allekirjoituksen aktivointi vaativat erilliset huomiot.

Seuraavat vaiheet

  1. Lue takaisin luotettavat tiedot.
  2. Tallenna tuotantoreittitesti.
  3. Vahvista vastaanotettu kohdistustulos.

CISO / SecOps

Tarkista delegoitu luottamus.

Palveluntarjoajan hallinnoima kohde voi muuttaa vahvistusmateriaalia delegoidun laajuuden puitteissa.

Seuraavat vaiheet

  1. Hyväksy allekirjoituksen henkilöllisyys.
  2. Tarkista vanhentuneet aliakset.
  3. Tarkista palveluntarjoajan vuorotteluvaltuutus.

Perustaja / ei-tekninen

Tee omistajuudesta osa perehdyttämistä.

Lähettävä palveluntarjoaja lisää jatkuvan DNS ja allekirjoitusriippuvuuden, ei vain kertaluonteista asennustehtävää.

Seuraavat vaiheet

  1. Määritä omistaja.
  2. Sisällytä eläkkeelle siirtyminen myyjän tarkistuslistaan.
  3. Tarkista palvelun lopettaminen uusimisen yhteydessä.

[ UKK ]

Usein kysytyt kysymykset

Onko CNAME julkinen DKIM avain?

Ei. Se on alias toiselle DNS nimelle. Seuraa vahvistustietojen ratkaisua ja käytä palveluntarjoajan luomaa tavoitetta.

RFC 1034 §3.6.2

Voinko laittaa TXT ja CNAME samaan valitsimen nimeen?

Älä yhdistä perinteistä CNAME erillisen TXT -avaimen kanssa kyseisessä omistajan nimessä. Käytä tuettua mallia ja erillisiä valitsimia tarvittaessa.

RFC 1034 §3.6.2

Pitäisikö minun kopioida avain toimittajan CNAME kohteesta vyöhykkeelleni?

Ei improvisoituna korvaajana. Se voi irrottaa julkaisusi toimittajan avainten vaihdosta.

Todistaako onnistunut DNS tarkistus, että sähköposti on allekirjoitettu?

Ei. Lähetä oikean sovelluksen kautta ja tarkista vastaanotettu allekirjoitus ja luotettava vahvistustulos.

RFC 6376 §5.5 RFC 6376 §6.1

Minne yksityinen avain menee?

Valtuutetussa allekirjoitusjärjestelmässä tai sen tukemassa avainpalvelussa. Sitä ei saa koskaan julkaista DNS ssä.

RFC 6376 §8.3

Miksi tietueen nimi sisältää verkkotunnukseni kahdesti?

DNS liitäntä on saattanut liittää vyöhykkeen koko nimeen. Vertaa todellista julkaistua omistajan nimeä vaadittuun nimeen.

Takaako DKIM läpäiseminen verkkotunnuksen mukaisen kohdistuksen?

Ei. Vertaa ohittavan allekirjoituksen d-aluetta näkyvään Lähettäjä-verkkoalueeseen sovellettavan DMARC kohdistussäännön mukaisesti.

RFC 9989 §4.4.1

Mitä minun pitäisi säilyttää offboardin poistamista varten?

Säilytä palvelun omistaja, valitsijat, kohteet, allekirjoitushenkilöllisyys ja eläkesuunnitelma sekä vastaanotettujen viestien todisteet.

[ Lähteet ]

Lähteet

  1. RFC 6376

    Osat §1 · §3.1 · §3.5 · §3.6 · §5.5 · §6.1 · §6.1.2 · §8.3

  2. RFC 1034

    Osat §3.6.2

  3. RFC 9989

    Osat §4.4 · §4.4.1

  4. Microsoft Learn: Määritä DKIM

    Osat DKIM CNAME -tietueiden syntaksi · Määritä lähtevien viestien DKIM allekirjoitus mukautettuja verkkotunnuksia käyttämällä

[ Sanasto ]

Sanasto

DKIM
Toimialueeseen liittyvä allekirjoitus valitun viestin sisällön päälle, joka on vahvistettu julkisen avaimen tietojen avulla.

RFC 6376 §1

Valitsin
s-arvo, jota käytetään d-allekirjoitusverkkotunnuksen kanssa vahvistustietojen paikantamiseen.

RFC 6376 §3.1 RFC 6376 §3.5

DMARC -linjaus
Vaadittu suhde todennetun tunnisteen ja tekijän verkkotunnuksen välillä.

RFC 9989 §4.4

Yrityksen alkuperä

Miksi parhaat rahoituslaitokset ja hallitukset lopettivat sähköpostin suojauksen hallintapaneelinsa.

Perinteiset sähköpostin todennusalustat myyvät sinulle kojelaudan ja pyytävät insinöörejäsi tekemään työtä. Korkeiden panosten ympäristöissä manuaalinen valvonta tarkoittaa viivästynyttä täytäntöönpanoa, konfiguraatioiden siirtymistä ja valvomattomia varjoalueita.

EmailAuth on agentti sähköpostin alkuperäalusta. Agenttimme valvovat p=reject, pidä kolmannen osapuolen lähettäjät kohdakkain ja siirrä verkkotunnuksesi täyteen RFC 9989 noudattaminen, uusi DMARC standardi, jossa on in-the-loop -tarkastettavuus.

hallitukset Suuret yritykset Tason 1 rahoituslaitokset

SaaS · Dedikoitu vuokrasopimus · Ilmarakoinen on-prem · BYOK-salaus

Tietokanta