SPF, DKIM ja DMARC antaa erilaisia todisteita sähköpostista. SPF arvioi yhteyden lähteen arvioidun toimialueen lähetyskäytännön perusteella. DKIM vahvistaa verkkotunnukseen liittyvän allekirjoituksen peitetyn viestimateriaalin päällä. DMARC liittää välittävän todetun identiteetin From-alueella olevaan toimialueeseen ja soveltaa sen käytäntökehystä.
He työskentelevät yhdessä, koska mikään yksittäinen vihreä tulos ei vastaa jokaiseen identiteettikysymykseen. Hyödyllinen toteutus seuraa viestiä lähetyspalvelun, DNS riippuvuuksien ja vastaanottojärjestelmän kautta säilyttäen sen, minkä kukin tarkistus itse asiassa on määrittänyt.
Anna jokaiselle tarkastukselle oma kysymys
- Mekanismi: SPF ; Vastattu kysymykseen: Täyttääkö tämä yhdistävä lähde arvioidun identiteetin lähetyskäytännöt?; Tärkeä raja: Tämän identiteetin ei tarvitse olla näkyvä Lähettäjä-verkkotunnus
- Mekanismi: DKIM ; Vastattu kysymykseen: Verrataanko tämä verkkotunnukseen liittyvää allekirjoitusta sen katettuun viestimateriaaliin? Tärkeä raja: Vahvistus ei varmista, että kaikki viestin tai pyynnön osat ovat turvallisia
- Mekanismi: DMARC ; Vastattu kysymykseen: Onko hyväksytyn läpäisyn henkilöllisyys linjassa From-tunnuksen kanssa, ja mitä arviointikäytäntöjä sovelletaan? Tärkeä raja: Vastaanottimen käsittely sisältää todisteita DMARC ulkopuolella
Tarkastukset liittyvät toisiinsa, mutta ne eivät ole kolme kopiota samasta testistä. Järjestelmä voi julkaista kaikki kolme DNS tietuetta, kun sovellus lähettää edelleen ilman tarkoitettua allekirjoitusta tai verkkotunnuksen kohdistus.
Seuraa SPF ää lähettävästä yhteydestä
varten POSTIA LÄHETTÄJÄ tavallisen viestin tarkistaminen ei-tyhjän kirjekuoren palautusosoitteella, RFC 7208 §2.4 määrittää, että SPF arvioi lähettävän lähteen käyttämällä MAIL FROM -identiteettiä. Vastaanottaja tarkastelee kyseisen toimialueen julkaistua käytäntöä, joka voi viitata muihin käytäntötietoihin.
Tästä syystä henkilöllisyydellä on merkitystä ennen DNS muokkausta. Palvelun lisääminen osoitteeseen example.com SPF ennätys ei voi korjata SPF arviointia, joka todella käyttää palvelun ohjaamaa toimialuetta muualla. Selvitä ensin, mitä viesti ja reitti käyttävät.
Under RFC 7208 §2.3 ja RFC 7208 §2.4, SPF voi myös arvioida HELO, ja sen määritykset määrittelevät käsittelyn nolla-käänteispolulle. Nämä tapaukset eivät oikeuta korvaamaan mielivaltaista verkkotunnusta viestin näyttökentistä. Säilytä arvioitu identiteetti tuloksen kanssa.
SPF passi ei luo allekirjoitusta viestin sisällölle. Sen todisteet koskevat arvioitua lähtettä ja identiteettiä kyseisessä vastaanottopisteessä.
Seuraa DKIM ää allekirjoittamisesta vahvistukseen
Lähetysjärjestelmä koskee a DKIM -allekirjoitus käyttämällä yksityistä avainta. Under RFC 6376 §3.6.2.1, vahvistus käyttää julkista materiaalia, joka löytyy kyseisen allekirjoituksen allekirjoitusverkkotunnuksen ja valitsin. Yksityinen avain kuuluu valtuutettuun allekirjoitusjärjestelmään, ei julkiseen DNS .
Sekä allekirjoituksen että julkaisemisen on toimittava. Julkinen avain oikealla nimellä ei todista, että sovellus on allekirjoittanut viestinsä sillä. Päinvastoin, nykyinen allekirjoitus ei varmista, että sen avain voidaan noutaa tai että vahvistus onnistuu toimituksen jälkeen.
Under RFC 6376 §3.7, DKIM suojaa määritellyn allekirjoituslaskelman kattamaa materiaalia. Yhdyskäytävä, joka muuttaa asiaankuuluvaa sisältöä allekirjoituksen jälkeen, voi vaikuttaa vahvistukseen. The body-hash-tutkimusopas selittää, kuinka tietty vika voidaan jäljittää arvaamatta, että jokainen DKIM virhe tarvitsee uuden avaimen.
Käytä DMARC todisteiden yhdistämiseen From-palveluun
DMARC arvioi Lähettäjä-osoitteessa olevan toimialueen soveltuvien käytäntöjen ja kohdistussuhteiden avulla. Under RFC 9989 §5.3.5, viestitason hyväksyntä soveltuvalla käytännöllä ja suoritetuilla tarkistuksilla voi tulla joko läpäisevästä kohdistetusta SPF identiteetistä tai läpäisevästä kohdistetusta DKIM allekirjoituksesta.
Tämä hyväksyntäehto ei ole suositus määrittää vain yksi mekanismi. RFC 9989 §8 täysimääräisiin osallistumisvaatimuksiin kuuluvat yhdenmukaistettu SPF ja DKIM , raportointi ja käytäntöjen julkaiseminen. Under RFC 9989 §7.4, verkkotunnusten julkaiseminen p=reject ei saa luottaa pelkästään SPF , ja sen on käytettävä kelvollisia DKIM -allekirjoituksia.
Postilaatikoiden tarjoajat voivat myös asettaa omia lähettäjävaatimuksiaan. Googlen joukkolähetysohjeetesimerkiksi kutsua SPF , DKIM ja DMARC . Pidä protokollan viestitason tulos erillään palveluntarjoajan koko lähetyskäytännön noudattamisesta.
Ymmärrä, miksi polut voivat selviytyä eri tavalla
Seuraava on synteettinen esimerkki, ei tilitesti. Ilmoituspalvelu tuottaa läpäisevän tasatun SPF -tuloksen ja läpäisevän kohdistetun DKIM -allekirjoituksen suoralle reitilleen.
Harkitse nyt kahta muutosta kyseiseen reittiin:
- Välityspalvelu muuttaa lopullisen vastaanottajan näkemää yhteyslähdettä. Aikaisempi SPF tulos ei ole tae myöhemmästä arvioinnista. Jos asiaankuuluva allekirjoitettu sisältö säilyy, alkuperäinen kohdistettu DKIM allekirjoitus saattaa silti vahvistua.
- Yhdyskäytävä muuttaa allekirjoitettua sisältöä allekirjoitusvaiheen jälkeen. DKIM saattaa epäonnistua seuraavassa vastaanottimessa, kun taas SPF riippuu lopullisesta yhteysreitistä ja arvioidusta identiteetistä.
Kumpikaan lopputulos ei ole väistämätön jokaiselle välittäjälle. Tarkista todellinen reitti, henkilöllisyydet ja varmistustulokset. Tämä ero selittää, miksi nämä kaksi mekanismia tarjoavat hyödyllisiä erillisiä polkuja ilman, että niistä tulee yleisesti luotettavia kaikissa edelleenlähetyksissä tai muokkauksissa.
Pidä konfiguraatiotodisteet erillään viestitodisteista
Pieni palvelutason tietue on hyödyllisempi kuin selittämätön toimialueen laajuinen tila. Tämä kuvitteellinen hyväksyntämatriisi havainnollistaa eroa:
- Palvelun tarkkailu: Työntekijän postissa on julkinen DKIM avain; Todisteita tarvitaan edelleen: Todiste siitä, että valittu verkkotunnus allekirjoittaa ja varmistaa todellisen reittinsä
- Palvelun tarkkailu: Laskutusposti läpäisee SPF :n palveluntarjoajan verkkotunnukselle; Todisteita tarvitaan edelleen: Sen suhde From-osoitteeseen ja kaikkiin kohdistettuihin DKIM polkuihin
- Palvelun huomio: markkinointiviestillä on voimassa oleva DMARC käytäntö; Todisteita tarvitaan edelleen: Todellinen allekirjoitus, todennus ja käytäntöön liittyvät todisteet
- Palvelun tarkkailu: Vastaanotettu viesti läpäisee asianmukaiset tarkastukset; Todisteita tarvitaan edelleen: Yrityksen omistaja ja hyväksytty käyttö, erikseen arvioitu
Säilytä kunkin palvelun tuetut kokoonpanot, tärkeät identiteetit ja edustava alkuperäinen vastaanotettu viesti. Under RFC 8601 §7.1, käytä luotettavia vastaanottojärjestelmän tuloksia; epäluotettavan lähettäjän lisäämä hyväksyntä ei voi kestää vastaanottajan työtä.
The lähettäjän inventaario yhdistää nämä tietueet omistajiin. The DMARC -tietueen työnkulku liittyy julkaisuun viestien ja raportoinnin vahvistukseen.
Säilytä yhdistetyn tuloksen rajat
Kuten allekirjoituksen laajuus sisällä RFC 6376 §3.7 ja vastaanottimen käsittely RFC 9989 §5.4 Näytä, nämä tarkistukset eivät salaa viestiä vastaanottajalle, vahvista sen sisällön totuutta tai takaa saapuneiden kansioiden sijoittelua. Kuljetuksen turvallisuus ja arkaluonteisen viestisisällön suojaaminen ovat erillisiä huolenaiheita.
Vaarantunut valtuutettu palvelu voi silti lähettää todennettua postia. Samoin kelvollinen tekninen tulos ei osoita, että organisaatio on hyväksynyt kyseisen sovellustilin tai yrityspyynnön.
Hyödyllinen yhdistetty tulos on siksi tarkka: vastaanottaja arvioi todelliset lähde- ja allekirjoitusidentiteetit, löysi vaaditun kohdistetun kulkupolun From-kohteelle ja harkitsi asiaankuuluvaa käytäntöä. Säilytä todisteet sen tuottaneen palvelun ja reitin kanssa. Kolme määritettyä tietuetta ovat aloitusriippuvuus; varmennettu, ylläpidetty viestintä on toiminnan tulos.
Säilytä rajallinen johtopäätös
Kuvitteellisessa hyväksymismatriisissa julkinen avain vain sulkee julkaisun todisteet. Palveluntarjoajan verkkotunnuksen SPF passi tarvitsee edelleen suhteensa Lähettäjään tarkistettavaksi. Säilytä minkä tahansa vaaditun DMARC passin osalta sovellettava käytäntö ja kohdistettu passituspolku ja pidä sitten tilin hyväksyntä ja sisällön turvallisuus erillään. Täällä ei tehty palvelun konfigurointia tai viestitestiä.