DMARC začnite z nadzorom: prehiter »reject« lahko ustavi legitimno pošto

DMARC nastavite tako, da preverite pošiljatelje, SPF in DKIM, nato v DNS objavite politiko p=none z naslovom za poročila rua. Googlova navodila za DMARC priporočajo začetno spremljanje in poznejši prehod na strožjo politiko, ko veste, kako prejemniki overjajo vašo pošto. Prehiter prehod na reject lahko ustavi tudi legitimno sporočilo, ki zaradi napačne nastavitve ne prestane DMARC.

Sporočilo prestane DMARC, če uspešno preverjanje SPF ali DKIM potrdi domeno, usklajeno z domeno v vidnem polju From. Uspešen SPF za domeno ponudnika ali veljaven podpis DKIM z njegovo domeno sam po sebi še ne zadostuje. Zato pred zaostritvijo politike preverite dejanske poti pošiljanja, ne le zapisa, ki ga nameravate objaviti.

Popišite pošiljatelje in preverite njihove domene

Na seznam uvrstite običajne poštne predale ter vse storitve, ki pošiljajo z vaše domene: spletne obrazce, trgovino, račune, rezervacije, podporo in e-novice. Pri vsaki zabeležite domeno v polju From, domeno tehničnega povratnega naslova oziroma Return-Path ter domeno v podpisu DKIM. Vključite tudi sisteme, ki pošiljajo le občasno; odsotnost sporočil med kratkim opazovanjem še ne pomeni, da jih ne uporabljate.

Pri zunanjem ponudniku preverite, kako nastavi SPF in DKIM ter ali omogoča podpisovanje DKIM z vašo domeno ali uporabo usklajene domene za povratno pošto. Če njegov strežnik uspešno opravi SPF za ponudnikovo domeno, polje From pa kaže vašo, DMARC prek SPF ne uspe. Enako velja za podpis DKIM, kadar je veljaven, vendar njegova domena ni usklajena z domeno v From.

Iz vsake storitve pošljite preskusno sporočilo po isti poti kot običajno pošto. V glavi prejetega sporočila primerjajte From, Return-Path, domeno DKIM in rezultate preverjanj. Pri glasilih lahko preverjanje dostave e-novic pomaga ločiti težave z overjanjem od drugih razlogov za uvrstitev med vsiljeno pošto.

Objavite začetni zapis TXT

Za pogojno domeno example.com je uporaben začetni zapis TXT na imenu _dmarc.example.com z vrednostjo v=DMARC1; p=none; rua=mailto:[email protected]. Domeno in naslov zamenjajte s svojima ter poskrbite, da predal za poročila deluje. Cloudflarejeva dokumentacija DNS navaja ime _dmarc in politiko p=none kot priporočeno možnost za začetno spremljanje.

V urejevalniku DNS preverite, ali ponudnik domeno sam pripne vnesenemu imenu. Če jo, vnesite samo _dmarc; sicer uporabite celotno ime zapisa. Po shranitvi z javno poizvedbo za TXT preverite, kaj je objavljeno na _dmarc vaši domeni. Obstoječi zapis popravite, namesto da dodate drugega: več zapisov DMARC na istem imenu lahko prepreči uporabo politike.

Politika p=none prejemniku ne naroča karantene ali zavrnitve zaradi neuspešnega DMARC. To pa ne izključi njegovih drugih pravil za filtriranje pošte. Namen začetnega zapisa je zbrati podatke o vseh virih, preden bi napaka v njihovi nastavitvi vplivala na dostavo zaradi strožje politike.

V poročilih rua poiščite znane vire z napako

Oznaka rua določa naslov za zbirna poročila prejemnikov, ki jih pošiljajo. Specifikacija DMARC za ta poročila določa podatke o izvoru sporočil, rezultatih SPF in DKIM ter ukrepu prejemnika; podatki prispejo kot XML, pogosto stisnjen. Če je poročil veliko, jih je lažje pregledovati z namenskim orodjem, ki združi zapise po izvoru.

Najprej primerjajte vire iz poročil s svojim seznamom pošiljateljev. Pri prepoznanem viru, ki ne prestane DMARC, ugotovite, ali je odpovedalo samo preverjanje SPF oziroma DKIM ali pa je preverjanje uspelo za neusklajeno domeno. Rezultat primerjajte z glavo preskusnega sporočila iste storitve. Neznan vir najprej preverite pri skrbnikih sistemov; samo njegov naslov IP še ne dokazuje ponarejanja.

Če poročila preusmerite na naslov pri drugi domeni, lahko ta domena potrebuje dodatno odobritev v DNS. Prazen predal zato ni dokaz, da vsa pošta prestaja DMARC: napačen naslov ali manjkajoča odobritev lahko preprečita prejem poročil. Prav tako poročil ne pošilja vsak prejemnik, zato jih dopolnite s preskusnimi sporočili iz svojih sistemov.

Pred zaostritvijo preverite usklajenost in posebne poti

Privzeta, sproščena usklajenost dopušča ustrezno ujemanje na ravni osnovne domene in njenih poddomen. Oznaki aspf in adkim lahko nastavite na r za sproščeno ali s za strogo usklajenost; stroga zahteva natančno ujemanje domen. Če storitev podpisuje s poddomeno, lahko sporočilo pri sproščeni nastavitvi prestane DMARC, pri strogi pa odpove. Strožjega ujemanja zato ne vključite samo zato, ker posamezno sporočilo že prestaja SPF ali DKIM.

Pred spremembo politike preverite:

• ali seznam zajema vsako znano storitev, ki pošilja z vašo domeno, vključno z občasnimi pošiljatelji;
• ali ima vsaka storitev preskusno sporočilo z uspešnim DMARC in katera domena ji to omogoča;
• ali poročila rua prispejo ter imajo napake znanih virov ugotovljen vzrok;
• ali ste preverili poddomene, zunanje ponudnike in posebne poti dostave.

Posredovanje pošte lahko spremeni pot tako, da SPF ne uspe več. Poštni seznam lahko spremeni vsebino sporočila in s tem pokvari podpis DKIM. Zato tudi za takšne poti preglejte dejansko prejeta sporočila: uspešen preizkus neposrednega pošiljanja ne zagotavlja enakega rezultata po posredovanju.

Politiko zaostrujte glede na dostavo

Ko znani viri prestajajo DMARC in so napake v poročilih pojasnjene, spremenite p=none v p=quarantine. Prejemniki lahko neuspešna sporočila tedaj uvrstijo med vsiljeno pošto. Iz istega obdobja spremljajte poročila in dejansko dostavo pomembnih vrst pošte, posebej računov, potrditvenih sporočil in obvestil iz zunanjih storitev. Če med neuspešnimi sporočili odkrijete legitimen vir, najprej popravite njegovo overjanje ali usklajenost domene.

Oznaka pct omogoča postopno uvajanje strožje politike, saj omeji delež sporočil, za katera prejemnik uporabi zahtevani ukrep. Deleža ne obravnavajte kot zagotovila, da nobeno pomembno sporočilo ne bo prizadeto: v izbrani del lahko spada prav pošta iz slabo nastavljenega sistema. Na p=reject preidite, ko tudi pri strožjem spremljanju ni nepojasnjenih odpovedi legitimnih virov. Ta politika prejemniku naroča zavrnitev sporočil, ki ne prestanejo DMARC, zato je popravljen seznam pošiljateljev pomembnejši od same spremembe vrednosti v DNS.

Preberite tudi:

• E-novice končajo med vsiljeno pošto: preverite SPF, DKIM in DMARC
• OBS ali Streamlabs: lažja nastavitev lahko porabi do 28 % več procesorja
• Podcast prek RSS na YouTube: napačen datum lahko podvoji epizode