
DMARC ilma katkestuseta: „reject“ tuleb alles pärast aruannete kontrolli

Ettevõtte domeenil alusta DMARC-i kasutuselevõttu kõigi tegelike saatjate kaardistamisest, SPF-i ja DKIM-i korrastamisest ning aruandeid koguvast p=none-kirjest. Microsofti DMARC-i juhis soovitab pärast tulemuste jälgimist liikuda järk-järgult karantiini ja alles siis reject-poliitikani, et joondusveaga õiguspärased kirjad ei jääks kohale toimetamata.
Kontrolli eraldi töötajate postkaste, arvesüsteemi, veebivorme, uudiskirjateenust, alamdomeene ja edasi suunatud kirju. DMARC-i läbimiseks peab vähemalt üks edukas SPF-i või DKIM-i kontroll kasutama nähtava From-aadressiga joondunud domeeni. Google’i saatjanõuded ütlevad, et Gmaili mahusaatjal peavad olema SPF, DKIM ja DMARC; autentimata kiri võidakse märkida rämpspostiks või tagasi lükata veaga 5.7.26.
Kaardista iga tegelik saatja
Pane iga teenuse kohta kirja saatmise otstarve, nähtav From-domeen, SPF-i kontrollitav MAIL FROM-domeen ja DKIM-allkirja domeen. Küsi sama teavet väliselt raamatupidajalt ning veebilehe, e-poe ja turunduse haldajalt. Töötajate postkastiteenuse ülevaatusest ei piisa, kui arved või tellimusteated väljuvad mujalt.
Kui domeenilt saadab ainult tavaline Microsoft 365 teenus, on Microsofti SPF-i näide „v=spf1 include:spf.protection.outlook.com -all“. Teise saatja lisandumisel täienda olemasolevat kirjet tema dokumenteeritud allikaga: sama domeeni mitu SPF-kirjet põhjustavad kontrollivea. Arvesta ka pesastatud include-kirjetega, sest SPF-i kontrollis võib liiga palju DNS-päringuid anda püsiva vea.
Lülita saatmisteenustes sisse oma domeeniga DKIM-allkirjastamine ja sisesta nende antud DNS-kirjed täpselt teenuse juhiste järgi. Saada igast teenusest proovikiri välisele postkastile. Kirja päises võrdle nähtavat From-domeeni väljadega smtp.mailfrom ja header.d: teenusepakkuja domeeniga saadud spf=pass või dkim=pass ei pruugi anda DMARC-i jaoks vajalikku joondust.
Avalda p=none ja kogu aruandeid
Lisa DNS-i tinglik näidiskirje nimega „_dmarc.firma.example“ ja väärtusega „v=DMARC1; p=none; rua=mailto:[email protected]“. Asenda firma.example oma domeeniga ning loo aruannete jaoks toimiv aadress. Kui DNS-teenus lisab domeeninime kirje nimele ise, sisesta nimeväljale ainult „_dmarc“; pärast salvestamist kontrolli avalikust DNS-ist, milline nimi ja väärtus tegelikult nähtavad on.
p=none ei palu vastuvõtjal DMARC-i vea tõttu kirja tõkestada, kuid muud rämpsposti- ja turvakontrollid toimivad edasi. Koondaruanded saabuvad rua-aadressile sageli tihendatud XML-failidena ning näitavad muu hulgas saatvaid IP-aadresse, kirjade arvu ja autentimistulemusi. Kõik vastuvõtjad aruandeid ei saada, mistõttu lisa aruannetele igast teadaolevast kanalist saadetud proovikirjad.
Kui aruandeaadress asub teise domeeni all, peab seda haldav teenus lubama välise domeeni aruandeid vastu võtta vastava DNS-kirjega. Alustuseks piisab rua-aadressist. Üksiksõnumi tõrkearuannete ruf-välja võib jätta lisamata, sest sellised aruanded võivad sisaldada sõnumi üksikasju ja nende saatmine sõltub vastuvõtjast.
Erista tundmatu saatja joondusveast
Võrdle koondaruannete korduvaid IP-aadresse ja saatjaid oma nimekirjaga. Kui tuntud teenuse SPF läbib kontrolli, kuid MAIL FROM kasutab teenusepakkuja domeeni, võib SPF-i joondus nähtava From-domeeniga ikkagi puududa. Sama kehtib DKIM-i kohta, kui allkirja d= väärtus kuulub ainult teenusepakkujale.
Tuntud saatja puhul seadista võimaluse korral oma domeeniga MAIL FROM või DKIM-allkiri ja korda proovikirja. Ühest joondunud ning edukast kontrollist piisab DMARC-i läbimiseks; mõlema puudumisel tuleb viga lahendada enne poliitika karmistamist. Tundmatut IP-aadressi ära lisa SPF-i üksnes aruandes esinemise põhjal: selgita esmalt välja, kas see kuulub ettevõtte kasutatavale teenusele või näitab domeeni võltsimise katset.
Kontrolli alamdomeene ja edasi suunamist
Saada proovikiri igalt tegelikult kasutatavalt saatmisalamdomeenilt. Selle SPF-kirje ei päri automaatselt põhidomeeni SPF-i; DKIM-allkiri peab samuti sobima kasutatava From-domeeniga. DMARC-poliitika seevastu laieneb alamdomeenile, kui alamdomeenile pole loodud eraldi DMARC-kirjet. Seetõttu võib põhidomeeni rangem poliitika mõjutada ka harva kasutatavat arve- või uudiskirjaaadressi.
Katseta eraldi teekonda läbi edasi suunava teenuse või meililisti. Edasi suunamine võib muuta SPF-i jaoks nähtavat saatvat serverit ning sõnumi muutmine võib rikkuda DKIM-allkirja. Kui õiguspärane kiri selles teekonnas DMARC-i ei läbi, uuri, kas algne DKIM-allkiri säilib või saab vastuvõttev teenus kasutada sobivat ARC-käsitlust. Sellist tõrget ei paranda tingimata algse saatja SPF-kirje muutmine.
Liigu karantiini ja reject-poliitikani etapiti
Järgmine nädalapõhine järjestus on tööplaan, mitte automaatne tähtaeg. Hoia senist poliitikat kauem, kui mõni harv saatja on veel kontrollimata või aruannetes püsib teadaoleva õiguspärase teenuse joondusviga.
- Esimene nädal: koosta saatjate nimekiri, korrasta SPF ja DKIM ning avalda p=none koos rua-aadressiga. Saada proovikirjad põhidomeenilt, kasutatavatelt alamdomeenidelt ja väliste teenuste kaudu.
- Teine nädal: võrdle saabunud koondaruandeid nimekirja ja proovikirjade päistega. Paranda teadaolevate saatjate joondusvead ning kontrolli uuesti neid kanaleid, mille tulemused olid puudulikud.
- Kolmas nädal või hiljem: kui teadaolevad saatjad läbivad kontrolli, proovi väärtust „v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]“. Suurenda pct väärtust alles pärast uute aruannete ja kohaletoimetamise kontrolli.
- Järgmine etapp: kui karantiin ei too esile lahendamata õiguspäraseid saatjaid, võid liikuda väärtusele „v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]“. Jätka aruannete jälgimist ka pärast muudatust.
pct määrab, kui suurele osale DMARC-i kontrolli mitte läbivatest kirjadest rangemat poliitikat palutakse rakendada; vastuvõtja lõplik käitumine võib erineda. Säilita eelmine toimiv DNS-väärtus, et tarneprobleemi korral poliitikat kiiresti leebemaks muuta. Reject-etapi eel peab iga teadaolev õiguspärane saatja olema läbinud nii proovikirja kontrolli kui ka aruannetes nähtava joonduskontrolli.
Loe ka:
Seotud artiklid


Kas e-post lekkis? HIBP leid on alles turvakontrolli algus

NVIDIA pani AI-agentidele riistvaralise valvekoera — karantiin võtab millisekundeid

Proton Pass või Bitwarden: e-posti alias või odavam perepakett?

Passkey või parool: andmepüük taandub, kuid konto taastamine jääb nõrgaks

AI muudab töökuulutuse pettuse usutavaks — kontrolli enne kandideerimist
Telli meie uudiskiri
Saa värskeimad Web3, AI ja krüptouudised otse oma postkasti.