Pankin markkinointialusta voi mennä läpi DMARC jatkuvasti, kun pieni todennuskoodipalvelu epäonnistuu. Yhteenlaskettu prosenttiosuus piilottaa asiakkaan kyvyttömyyden kirjautua sisään. Inventoi kriittiset ilmoitukset tarkoituksen ja toiminnallisen seurauksen mukaan ennen kuin käytät postin yleistä kuntoa valmiuden arvioimiseen.
Erota kolme palvelulupausta
Todennuskoodiviestillä on identiteettipalvelun hallitsema vanhenemis- ja uudelleenyrityselinkaari. Petosvaroitus saattaa vaatia oikea-aikaista huomiota hyväksytyn yhteydenottotyönkulun kautta. Tiliilmoitus voi olla vähemmän välitön, mutta sisältää silti välillisiä tietoja. Dokumentoi jokaisen kohdalla laukaisija, sovelluksen omistaja, odotettu ajoitus, vaihtoehtoinen pääsypolku ja eskalointitiimi.
Älä muuta tätä luetteloa sähköpostin vahvistukseksi tietyn pankkitapahtuman todennustekijänä. Sähköpostikoodien soveltuvuus riippuu oppilaitoksen hyväksytystä turvallisuussuunnittelusta ja sovellettavista vaatimuksista. DMARC suojaa verkkotunnuksen identiteettiarvioinnin; se ei voi tehdä heikkoa palautumisprosessia tai vaarallisen tekijän valintaa hyväksyttäväksi.
Tarkista reitti, joka todella lähettää koodin
Tallenna Lähettäjä-toimialue, kirjekuoren identiteetti, DKIM allekirjoittaja, valitsin, sovellusvuokraaja ja identiteettipalvelun ympäristö. Varmista, että testi-, vaiheistus- ja tuotantokokoonpanot ovat selvästi erotettu toisistaan. Onnistunut testi kehittäjän postilaatikon kautta ei kerro mitään tuotannon ilmoitustyöntekijästä, jos se käyttää toista toimittajaa.
Jos kyseessä on petosilmoitus, tallenna hälytyksen luonut lähettäjä ja kanava, jonka kautta asiakkaiden tulee varmistaa se itsenäisesti. Vältä opetamasta asiakkaita luottamaan viestiin vain siksi, että se näyttää brändätyltä tai todennettulta. Tili-ilmoitukset voivat käyttää eräsuoritinta, jolla on erilainen allekirjoitus- ja uudelleenyrityskäyttäytyminen; sisällyttää sen eksplisiittisesti sen sijaan, että periisi koodipalvelun tuloksen.
Mittaa latenssia vaatimatta enempää kuin kellot osoittavat
Sieppauksen laukaisuaika, palveluntarjoajan lähetysaika, etähyväksyntä, jos mahdollista, ja valvottu postilaatikon tarkkailuaika. Tallenna aikavyöhykkeet ja kellon epävarmuus. Vertaa näitä vaiheita laitoksen omiin hyväksymiin palvelutavoitteisiin; tässä ei anneta yleistä toimitusaikakynnystä. Kootut raportointivälit eivät voi mitata tietyn koodin saapumisaikaa.
Käytä synteettisiä koodeja, joita ei voi todentaa millekään oikealle tilille. Älä koskaan kerää käyttökelpoisia koodeja laajalti saatavilla oleviin kuvakaappauksiin tai diagnostiikkaan. Testaa vanhentuneen koodin käyttäytymistä, viivästynyttä toimitusta ja toistuvia pyyntöjä hyväksytyssä ei-tuotantoympäristössä. Myöhäinen koodi voi todentaa täydellisesti sähköpostikerroksessa, mutta epäonnistua oikein sovellustasolla, koska se on vanhentunut.
Määritä palautus ennen politiikan kiristämistä
Henkilöllisyyden omistajan tulee määrittää, kuinka käyttäjä saa takaisin pääsyn sähköpostin epäonnistuessa, kun taas petostoimintojen tulisi määrittää, kuinka asiakkaat voivat tarkistaa hälytykset luotettavan polun kautta. Postitiimi diagnosoi lähettäjän henkilöllisyyden ja vastaanottajan todisteet. Vältä kriittisten suojausilmoitusten automaattista estämistä yksinkertaisesti parantaaksesi todennusprosenttia.
Vaadi edustava testi jokaiselle kriittiselle reitille ja nimetty omistaja jokaiselle aukolle. Alla olevassa paikallisessa kartassa tili-ilmoituksen allekirjoittajan on oltava kohdistamaton, kun taas koodin ja petoksen allekirjoittajat vastaavat tarkasti. Tämä on koulutuskontrasti, ei pankkimittaus. Tarkista uudelleen palveluntarjoajan vikasietoisuuden, identiteettialustamuutosten, valitsimen vuorottelun ja koodin käyttöiän muutoksen tai uudelleenyrityskäyttäytymisen jälkeen. Erota dokumentoitu palautusoikeus teknisestä mahdollisuudesta muuttaa DNS .
Käy läpi kolme kirjallista reittitietuetta
Nämä varatut esimerkkialueet, valitsijat, roolit ja ohittavat DKIM tilat ovat kuvitteellisia. Näissä tapauksissa ei toimiteta tai suoriteta allekirjoitettua viestiä, avainta, kryptografista vahvistusta, DNS hakua, SMTP tapahtumaa tai live-palvelutestiä. Alla olevan perustelun tarkistamiseen ei tarvita testikoodia tai ulkoista näytettä.
- todennuskoodi: näkyvä osoitteesta domain codes.bank.example ; DKIM d=codes.bank.example; valitsin demo1; oletetaan, että DKIM -passi vain tässä kirjallisessa tapauksessa. SPF POSTIA LÄHETTÄJÄ henkilöllisyys ja tulos tuntematon; muut allekirjoitukset tuntemattomat; Todellinen käytäntöjen löytäminen ja toimitus tuntematon. Ehdotettu omistaja: Identiteettipalvelun omistaja. Seuraava toimenpide: Hanki valtuutettu näyte ja luotettava vastaanotin tulos juuri tälle vuokralaiselle.
- petosvaroitus: näkyy verkkotunnuksesta fraud.bank.example ; DKIM d=fraud.bank.example; valitsin demo2; oletetaan, että DKIM -passi vain tässä kirjallisessa tapauksessa. SPF MAIL FROM henkilöllisyys ja tulos tuntematon; muut allekirjoitukset tuntemattomat; Todellinen käytäntöjen löytäminen ja toimitus tuntematon. Ehdotettu omistaja: Petostoiminnan omistaja. Seuraava toimenpide: Vahvista tämä erillinen reitti ja sen liiketapahtuma sen sijaan, että periisit ensimmäisen reitin tulosta.
- tiliilmoitus: näkyy verkkotunnuksesta accounts.bank.example ; DKIM d=provider.example.net; valitsin demo3; oletetaan, että DKIM -passi vain tässä kirjallisessa tapauksessa. SPF MAIL FROM henkilöllisyys ja tulos tuntematon; muut allekirjoitukset tuntemattomat; Todellinen käytäntöjen löytäminen ja toimitus tuntematon. Ehdotettu omistaja: Tilipalvelujen omistaja. Seuraava toimenpide: Pyydä vahvistetulta toimittajalta tämän vuokralaisen tuettu tasattu allekirjoituspolku. älä laajenna valtuutusta koko verkostoonsa.
Kahdella ensimmäisellä määrätyllä allekirjoituksella d= on täsmälleen sama kuin From-verkkotunnus, joten tunniste täyttää sekä tiukat että rento linjaus. Kun otetaan huomioon edellytetty onnistunut DKIM tulos, näille hypoteettisille viesteille on olemassa kohdistettu todennuspolku. Kolmas allekirjoittaja ei tahallaan liity tekijän verkkotunnukseen eikä voi tarjota tätä tasattua polkua. Älä kutsu kolmatta viestiä DMARC virheeksi: aligned SPF tai muu kohdistettu ohitus DKIM -allekirjoitus voisi silti täyttää mekanismin, ja näitä syötteitä ei tunneta. Älä päättele todellista käyttöönottoa tai postilaatikon sijoittelua mistään rivistä.
Salausallekirjoitus todentaa allekirjoitustoimialueen vastuun, ei jokaisen ohjeen totuuden tai valtuutuksen. Muutokset peitettyihin kanonisoituihin tavuihin voivat mitätöidä allekirjoituksen; jokainen näkyvä muokkaus ei välttämättä muuta allekirjoitettua syötettä. Todennus ja sovellustason hyväksyntä pysyvät erillään.
Lue hypoteettinen vanhenemisaikajana
OTP-01-tapauksessa, joka ei toimi, oletetaan synkronoidut kellot: laukaisu 10:00:00 GST, palveluntarjoajan lähetys 10:00:01 , SMTP etähyväksyntä 10:00:03 , hyväksytyn sovelluksen vanheneminen 10:01:00 ja valvotun postilaatikon tarkkailu 10:01:10 . Tämä keksitty saapuminen on 70 sekuntia liipaisun jälkeen ja 10 sekuntia oletetun voimassaolon jälkeen. Edes määrätty kohdistettu DKIM -passi ei voi pidentää koodin käyttöikää. Henkilöllisyyden omistaja tutkii viivettä ja hyväksyttyä palautuspolkua; sovelluksen on sovellettava sen määritettyjä kelpoisuussääntöjä. Etävastaanotto ei ole postilaatikon tarkkailua tai ihmisen lukemista. Toimintaviivettä, koodin voimassaoloa tai asiakkaan pääsyä ei mitattu. Varsinaiset lokit tarvitsevat kellon siirtymiä ja epävarmuutta ennen vaiheiden vertailua.
Käytä standardeja vaatimatta noudattamista
RFC 9989 kohdat 4.4 ja 5.3.5 tukevat kohdistuksen ja mekanismin eroa. Sen Osio 7.4 varoittaa epäsuoran postin yhteentoimivuudesta: verkkotunnukset käyttävät p=reject on käytettävä kelvollista DKIM , ei pelkästään SPF , ja yleiskäyttöinen postituslista vaatii erityistä huolellisuutta. Reittivarasto ei itsessään ole lupa pakottaa hylkäämään. RFC 6376 kohdat 3.4–3.7 ja 6.1 kuvaile allekirjoitettuja syötteitä ja todentamista. RFC 9990 kohta 3.1 tarjoaa raportointikontekstin, ei vastaanottajakohtaista saapumistodistusta. RFC 5321 kohta 4.2.5 erottaa palvelimen hyväksymisvastuun myöhemmistä toimitustuloksista. Tässä toimialakohtaiset työnkulkuvalinnat ovat toimituksellisia suosituksia; oikeudellinen ulottuvuus, tekijöiden soveltuvuus ja paikallinen lupa tarvitsevat oman vastuullisen tarkastelun.