Salasanan nollaus, joka saapuu linkin vanhenemisen jälkeen, on epäonnistunut asiakkaalta, vaikka sen todennus olisi oikea. Kuitti, joka ei koskaan saavuta aiottua postilaatikkoa, voi luoda tukityötä lähetysalustan onnistuneesta API-vastauksesta huolimatta.
DMARC on yksi osa kaupankäyntipostin tekemisestä luotettavaksi. Rakenna todennuskonfiguraatio kunkin asiakkaan työnkulun ympärille ja mittaa sitten vaiheet, jotka päättävät, onko viesti edelleen hyödyllinen.
Määritä palvelu, ei vain verkkotunnus
Listaa verkkotunnuksen lähettämät viestit: kirjautumiskoodit, salasanan vaihto, laskut, maksuilmoitukset, kuitit ja tilimuutokset. Tallenna sovelluksen omistaja, lähetystili, From-identiteetti, paluupolku, allekirjoitusidentiteetti ja asiaankuuluva varareitti.
Anna jokaiselle virralle liiketoimintatulos. Kirjautumiskoodi saattaa joutua saapumaan ennen lyhyttä voimassaoloajan päättymistä. Kuitti voi sietää enemmän viivettä, mutta vaatii silti haettavan tapahtumaviitteen. Nämä ovat palvelutavoitteitasi, eivät DMARC :n luomia toimituslupauksia.
Käyttää lähettäjän inventaario yhdistää nämä odotukset todelliseen lähetyskokoonpanoon. Sisällytä vara-alueet ja -tilit sen sijaan, että olettaisit, että ensisijaisen palveluntarjoajan asetukset kattavat ne.
Tarkista kunkin sovellusreitin käyttämä henkilöllisyys
Jos haluat valvotun edustajan viestin, tarkista todellinen Lähettäjä-toimialue, SPF-arvioitu identiteetti ja jokainen DKIM allekirjoittava verkkotunnus. Tarkista sekä raakatodennus että linjaus liittyy DMARC .
Under RFC 9989 §5.3.5, yksi ohitus linjassa SPF tai DKIM polku voi täyttää sanomatason DMARC -ehdon, kun soveltuva käytäntö on olemassa. Täysi osallistuminen alla RFC 9989 §8 vaatii lisäksi yhdenmukaistetun SPF ja DKIM , raportoinnin ja käytäntöjen julkaisemisen. Under RFC 9989 §7.4, hylkäyskäytäntötoimialue ei saa luottaa pelkästään SPF , ja sen on käytettävä kelvollisia DKIM allekirjoituksia.
Tällä erolla on merkitystä, kun pilvialusta palauttaa laajan "todennettu" -tilan. Toimialueen määrityssivu ei vahvista, että sovellustili, tuotantoalue ja sanomatyyppi käyttivät odotettua identiteettiä testatussa sanomassa.
Seuraa tapahtumaa sen virstanpylväillä
Pidä hakemustapahtuma, lähetys ja vastaanottajatodistus erillään. Palveluntarjoaja, joka hyväksyy API-pyynnön, ei ole sama tapahtuma kuin SMTP vastaanotin, joka hyväksyy viestin lähetyksen jälkeen. Positiivinen valmistuminen tietojen päättymisen jälkeen siirtää toimitusvastuun RFC 5321 §4.2.5; Vastaanottajan hyväksyntä ei todista postilaatikon sijoittelua, näyttöä tai lukemista.
Tämä kuvitteellinen testi käyttää esimerkkisovelluksen valitsemaa viiden minuutin nollauslinkin käyttöikää:
- UTC-aika: 12:00:00 ; Virstanpylväs: Nollauspyyntö luotu; Merkitys: Sovellus aloittaa tapahtuman
- UTC-aika: 12:00:02 ; Virstanpylväs: Lähetysalusta hyväksyy lähetyksen; Merkitys: Lähetys onnistui kyseisellä alustan rajalla
- UTC-aika: 12:00:20 ; Virstanpylväs: Vastaanottajapalvelin hyväksyy viestin DATA:n jälkeen; Merkitys: SMTP kanavanvaihto kyseiselle vastaanottimelle onnistui
- UTC-aika: 12:00:27 ; Virstanpylväs: Ohjattu testipostilaatikko paljastaa viestin; Merkitys: Tämän testin vastaanottajan havaittu saatavuus
- UTC-aika: 12:05:00 ; Virstanpylväs: Nollauslinkki vanhenee; Merkitys: Hakemuksen käyttökelpoisuuden määräaika
Testiviesti oli saatavilla, kun aikaa oli jäljellä neljä minuuttia ja kolmekymmentäkolme sekuntia. Se on havainto kuvitteellisessa testissä, ei vertailukohta tai takuu jokaiselle asiakkaalle.
Jos vastaanottaja lykkää viestiä tilapäisesti kello 12:06 asti, myöhemmässä onnistuneessa toimituksessa ei silti saavuteta tämän työnkulun määräaikaa. Tapahtuma tulee kirjata vanhenemisvirheeksi, vaikka viimeinen viesti läpäisi DMARC .
Säilytä tarpeeksi todisteita viivästyksen löytämiseksi
Käytä tapahtumatunnistetta, joka voidaan yhdistää sovelluslokien ja lähetyspalvelun välillä. Tallenna palautettu SMTP teksti, jonotapahtumat ja käytettävissä olevat vastaanotettujen viestien otsikot. Pidä ajat yhtenäisellä aikavyöhykkeellä.
Älä päättele DMARC hylkäämistä viivästyneestä asiakasvalituksesta. Todennusvirheet, tilapäiset viivästykset, paikallinen suodatus, osoiteongelmat ja sovellusvirheet vaativat erilaisia korjaustoimenpiteitä. Hylkäämisen osalta täydellinen palautettu vastaus ja lähetysalustan tapahtuma voivat olla käytettävissä olevat todisteet, koska toimitettua viestiä ei ole.
Toimitetussa testissä luotettu vastaanotin antaa tulokseksi kuvattujen rajojen sisällä RFC 8601 §7.1 voi näyttää todennuksen ja kohdistuksen. Rajoita säilytettävät näytteet ja lokit siihen, mitä tutkimus tarvitsee; nollaustunnusta tai koko viestin sisältöä ei saa kopioida vahingossa jaettuun lippuun.
Testaa reittiä, jota asiakas voi todella käyttää
Suora testipostilaatikko on hyödyllinen, mutta se ei edusta kaikkia vastaanottajan polkuja. Asiakkaat voivat toimittaa edelleenlähetysosoitteita tai roolipohjaisia aliaksia. Epäsuora käsittely voi muuttaa SPF n näkemää liitäntälähdettä tai muuttaa DKIM kannalta olennaista materiaalia.
Käytä edustavia testejä asiakasjoukollesi tärkeille reiteille ja tutki todellisia vikoja. Vain tapahtumaan tarkoitettu verkkotunnus voi olla paremmin hallittavissa kuin henkilökunnan kirjeenvaihtoalue, mutta vastaanottajat voivat silti ottaa käyttöön epäsuoran toimituksen.
Nykyiset hylkäyskäytäntövaatimukset tekevät kelvollisen DKIM allekirjoituksen välttämättömäksi. he eivät takaa jokaisen edelleenlähetetyn viestin vahvistusta tai perillemenoa. Politiikan valintaopas selittää, miten tuloksena oleva kompromissi arvioidaan.
Määrittele palautuminen, joka ei lisää sekaannusta
Suunnittele sovelluksen uudelleenyritys ja käyttäjäkohtainen palautus sen oman vanhenemismallin mukaan. Nollauslinkin osalta päätä, kuinka uusi valtuudet vaikuttavat aikaisempaan tunnukseen ja mitä käyttäjä näkee, jos viivästyneet viestit saapuvat epäkunnossa. Nämä valinnat kuuluvat sovellustiimille.
Pidä palveluntarjoajan vikasietoreitillä samaa identiteettivarmennusta kuin ensisijaista reittiä. Varmuuskopio, joka aloittaa lähetyksen asiaankuulumattomalla henkilöllisyydellä, voi luoda todennustapahtuman käytettävyystapahtuman aikana.
Älä hiljaa siirrä vaikuttanutta verkkotunnusta heikompaan käytäntöön reitin tutkimisen korvikkeena. Jos käytäntöjen palautus tarvitaan, valtuuta sen tarkka laajuus, säilytä määrityshistoria ja testaa kriittinen kulku uudelleen.
Seuraa tuloksia viestityypin mukaan
Erilliset nollaus-, laskutus- ja kuittitulokset sen sijaan, että raportoisit yhden verkkotunnuksen laajuisen onnistumisnumeron. Tarkastele viiveitä, lykkäyksiä, pomppimia ja käytettävissä olevia todennustodisteita palvelun määrittämää tulosta vastaan.
Yhdistetty DMARC -raportit alla RFC 9990 §3.1 auttaa tunnistamaan havaitut todennusmallit. Ne eivät tarjoa reaaliaikaista toimituskuittia jokaisesta tapahtumasta. Yhdistä ne sovelluksen ja lähetyspalvelun todisteisiin väittämättä, että raporttirivi todistaa tietyn käyttäjän vastaanottaneen tietyn sähköpostin.
Valmiista operatiivisesta tietueesta tulee käydä ilmi, kuka virran omistaa, mitä identiteettejä se käytti, missä se hyväksyttiin tai viivästettiin ja täyttyikö se asiakkaan määräajassa. DMARC toimittaa varmennettuja verkkotunnuksen todisteita kyseiseen tietueeseen; palvelu onnistuu, kun asiakkaan varsinainen tehtävä onnistuu.
Pidä seuraava toimenpide täsmällisenä
Nollausasennossa 12:05:00 miinus 12:00:27 jättää 273 sekuntia eli 4 minuuttia 33 sekuntia hyödyllistä. Saatavuus klo 12:06:00 olisi 60 sekuntia vanhenemisen jälkeen, vaikka todennus menisi läpi. Tallenna viivevaihe ja sovelluksen vanhenemishäiriö erikseen. Nämä laskelmat kuvaavat kuvitteellisia syötteitä, eivät mitattuja toimitustehoja tai suositeltua tunnuksen käyttöikää.