A DMARC tulos on diagnoosiluokka, ei ohje julkaistun käytännön muuttamiseen. epäonnistua, ei yhtään, temperror ja permerror viittaa erilaisiin tutkimuksiin. Niiden käsitteleminen keskenään vaihdettavina voi jättää todellisen vian ratkaisematta ja heikentää suojausta tarpeettomasti.
Aloita vastaanottavan järjestelmän luotettavista todisteista. An Authentication-Results -otsikko tallentaa järjestelmän väitteen; sen olemassaolo ei yksinään todista väitteen luotettavuutta. Tunnista, mikä vastaanottava palvelu loi sen ja mihin otsikoihin palvelu luottaa. Tämä raja on selitetty kohdassa RFC 8601 §1.2 ja RFC 8601 §7.1.
Lue menetelmä ja tulos yhdessä
Otsikossa, joka sisältää spf=pass; dkim=pass; dmarc=fail, kolme tulossanaa kuuluvat eri menetelmiin. The SPF ja DKIM passit voivat todentaa verkkotunnuksia, jotka eivät ole linjassa näkyvän Lähettäjä-verkkotunnuksen kanssa. Kääntäen, DMARC päästö voi esiintyä rinnakkain yhden taustalla olevan menetelmän epäonnistumisen kanssa, jos toinen ohituspolku kohdistuu.
Käytä seuraavaa diagnoosikarttaa. Tuloksen merkitykset tulevat RFC 9989 , kohta 9.2; seuraavat toimet ovat toimintasuosituksia.
- Tulos:
dmarc=none; Tulkinta: Tekijän verkkotunnukselle ei löytynyt soveltuvaa käytäntöä; Ensimmäinen hyödyllinen toimenpide: Muodosta käytäntöhaku todelliselle From-verkkotunnukselle - Tulos:
dmarc=pass; Tulkinta: Sovellettava käytäntö on olemassa ja läpäistävä todennettu identiteetti linjaa; Ensimmäinen hyödyllinen toimenpide: Tunnista onnistunut polku ja tutki mahdolliset erilliset toimitusongelmat - Tulos:
dmarc=fail; Tulkinta: Sovellettava käytäntö on olemassa, mutta läpäisevää linjattua identiteettiä ei ole määritetty; Ensimmäinen hyödyllinen toimenpide: Vertaa SPF ja kaikkia asiaankuuluvia DKIM tuloksia From-tulokseen - Tulos:
dmarc=temperror; Tulkinta: Arvioinnissa havaittiin ilmeisen ohimenevä virhe; Ensimmäinen hyödyllinen toimenpide: Tallenna DNS tai palveluvirhe ja vertaa myöhempää ohjattua yritystä - Tulos:
dmarc=permerror; Tulkinta: Arvioinnissa havaittiin virhe, joka ei todennäköisesti ratkea pelkällä uudelleenyrityksellä; Ensimmäinen hyödyllinen toimenpide: Tarkista tarkat käytäntötiedot ja vastaanottimen diagnostiikka jatkuvan määritysongelman varalta
Älä päättele syytä pelkän tulossanan perusteella. Väliaikainen DNS virhe ja väärin muotoiltu käytäntö voivat molemmat estää normaalin johtopäätöksen, mutta ne vaativat eri omistajia ja erilaista korjaustyötä. Säilytä kaikki diagnostiset kommentit sen sijaan, että vähennät todisteita kojelaudan väriin.
Erottele dmarc=none arvosta p=none
dmarc=none on raportoitu arvioinnin tulos. p=none on arvo julkaistussa käytännössä. Voimassa oleva valvontapolitiikka voi silti tuottaa jompaakumpaa dmarc=pass tai dmarc=fail yksittäisissä viesteissä.
Harkitse kahta synteettistä tapausta. Ensimmäisessä example.com julkaisee kelvollisen valvontatietueen ja viestillä on kohdistettu ohitus DKIM -allekirjoitus. Odotettu DMARC -arviointi läpäisee, vaikka käytäntö kieltää. Toisessa tapauksessa soveltuvaa käytäntöä ei löydy viestin tekijän verkkotunnukselle. Vastaanottaja voi raportoida dmarc=none; siitä sanasta ei voi päätellä mitään valvontapolitiikkaa.
Jos kollega sanoo " DMARC on none", kysy, tarkoittavatko he DNS käytäntöä, viestin tulosta vai lopullista sijoitusta. Tallenna kaikki kolme erikseen. Tämä lyhyt selvennys estää usein DNS muutoksen, joka on suunnattu väärään ongelmaan.
Tutki epäonnistumista henkilöllisyyksien avulla
Hanki alkuperäinen vastaanotettu viesti. Tallenna näkyvä From-verkkotunnus, SPF identiteetti ja tulos sekä d= verkkotunnus ja tulos jokaiselle asiaankuuluvalle DKIM -allekirjoitukselle. Käytä määritettyä linjaus tila identiteetin välittämiseen. A valitsin on avaimen paikannus, ei DKIM kohdistukseen käytetty toimialue.
Jos SPF hyväksyy toimittajan verkkotunnuksen ja DKIM hyväksyy toisen toimittajan verkkotunnuksen, kumpikaan ei välttämättä vastaa Lähettäjä-verkkotunnuksesi. Juuren muokkaaminen SPF ennätys ei ole automaattisesti korjaus. Selvitä, minkä identiteetin palvelu todella arvioi ja mitä asiakastoimialueen todennusvaihtoehtoja se tukee. The kohdistusvirheopas käy läpi tuon vertailun.
Tutki virheet arvaamatta
varten temperror, tallenna viestin aika, vastaanottaja, kyselyn nimi, virhe ja ratkaisukonteksti, jos saatavilla. Vertaa arvovaltaisia DNS ja rekursiivisia tuloksia. Myöhempi onnistunut haku tukee ohimenevää selitystä, mutta ei todista sitä, mitä vastaanotin näki aiemmin. Pyydä vastaanottavalta operaattorilta lokit, kun erolla on merkitystä.
varten permerror, hakea kaikki asiaankuuluvat tiedot TXT tietue sarja. Tarkista julkaisun nimi, version sijoitus, päällekkäiset käytäntötietueet ja virheelliset arvot. Älä lupaa, että jokainen väärin muotoiltu tietue tuottaa saman etiketin: nykyinen DMARC RFC 9989 §4.10 ja RFC 9989 §4.10.1 määrittää tietyn palautuksen ja oletuskäyttäytymisen joillekin syntaksi- ja käytäntöarvoongelmille, ja toteutukset voivat vaihdella. Yhdistä diagnostiikka sovellettavaan sääntöön ennen sen vaihtamista.
Säilytä näyte ennen ja jälkeen. Jos uusi yritys onnistuu, pidä tarkka korjaus ja onnistunut tulos yhdessä. Vältä tapahtuman sulkemista yksinkertaisesti siksi, että julkinen tarkistus antaa nyt vihreän tuloksen.
Pidä arviointi erillään toimituksesta
Under RFC 9989 §5.4, vastaanottaja voi toimittaa DMARC-virheellisen viestin paikallisten käsittelysääntöjensä mukaisesti, ja se voi estää ohimenevän viestin roskapostin, haittaohjelmien tai muiden syiden vuoksi. Kerää SMTP vastaus tai toimitusjärjestely erillään todennustuloksesta.
Viimeiseen tapausmuistiinpanoon tulee kertoa, mitä arvioitiin, mikä luotettu vastaanottaja, milloin, miksi tulos tapahtui ja mikä muuttui. Täsmällinen johtopäätös, kuten "laskutuspalvelu tuottaa nyt kohdistetun DKIM -passin tuotantoreittinsä kautta", on hyödyllisempi kuin " DMARC korjattu". Jos käytäntö puuttuu, jatka kohdasta DMARC tietuetta ei löytynyt.
Tee seuraava päätös selkeästi
Merkitse valvontapolitiikkaan p=none, dmarc=pass ja todellinen sijoitus kolmena erillisenä kenttänä. Jos kelvollinen käytäntö on olemassa, mutta molempia välitysmekanismien identiteettejä ei ole kohdistettu, suoritettu arviointi epäonnistuu. Jos tarvittavat DNS -kyselyt eivät valmistu, RFC 9989 §5.3.6 estää normaalin hyväksytyn/hylätyn johtopäätöksen. Nämä ovat analyyttisiä luokituksia, eivät vastaanottimen lokeja.