- DMARC veikia virš SPF ir DKIM: jis tikrina atitikimą ir nurodo, ką daryti, kai jo nėra.
- Politikos yra trys: stebėti, karantinuoti arba atmesti.
- Pradedama visada nuo stebėjimo, nes tik taip pamatoma, kas siunčia jūsų vardu.
- Google reikalauja DMARC iš siuntėjų, per parą siunčiančių daugiau nei 5 000 laiškų į Gmail.
Kokią problemą DMARC iš tikrųjų sprendžia
SPF ir DKIM egzistuoja seniai, bet vien jų neužteko. DMARC specifikacijos apžvalgoje priežastis įvardyta tiesiai: gavėjai negali atskirti teisėtų neautentifikuotų laiškų nuo suklastotų, o siuntėjai gauna labai prastą grįžtamąjį ryšį apie tai, kaip veikia jų autentifikacija.
Pavyzdys, kuris paaiškina viską. Jūsų domenas turi SPF įrašą. Kažkas siunčia sukčiavimo laišką jūsų vardu, ir SPF patikra nepavyksta. Ką turėtų daryti gavėjo serveris? Be DMARC — spręsti pačiam, nes jūs nieko nenurodėte. Gal tai sukčius, o gal jūsų pačių sąskaitų sistema, kurios į SPF pamiršote įrašyti.
DMARC atsako būtent į šį klausimą. Jis nurodo, ką daryti neatitikimo atveju, ir kartu pareikalauja atitikimo — kad autentifikacija būtų susieta su tuo domenu, kurį gavėjas mato siuntėjo eilutėje, o ne su kokiu nors kitu.
Trys politikos ir kuo jos skiriasi
DMARC įraše nurodoma viena iš trijų politikų. Jos sudaro natūralią seką nuo stebėjimo iki apsaugos.
Specifikacijoje ši seka aprašyta kaip laipsniško diegimo galimybė — būtent tam, kad siuntėjai galėtų pereiti prie griežtesnės politikos palaipsniui, o ne iš karto.
Ataskaitos — nematomiausia, bet naudingiausia dalis
Prieš kalbant apie politikos griežtinimą, verta suprasti, kodėl pirmasis žingsnis apskritai turi prasmę, nors ir nieko nekeičia gavėjams.
Apie DMARC dažniausiai kalbama kaip apie apsaugą, bet praktinė nauda pirmaisiais mėnesiais visai kita. DMARC generuoja dviejų tipų ataskaitas: apibendrintas, kuriose sudėti autentifikacijos rezultatai, ir detalias, aprašančias konkrečius nesėkmės atvejus.
Būtent apibendrintos ataskaitos atsako į klausimą, kurio kitaip niekaip nesužinotumėte: kas siunčia laiškus jūsų domeno vardu. Beveik kiekvienoje įmonėje šis sąrašas ilgesnis, nei manoma — rinkodaros platforma, buhalterinė programa, CRM, užsakymų sistema, kartais senas serveris, apie kurį visi pamiršo.
Šis sąrašas ir yra tikroji priežastis pradėti nuo stebėjimo. Kol nežinote visų teisėtų šaltinių, griežtinti politiką reiškia rizikuoti, kad kažkuris iš jų nustos veikti.
Kaip pereiti nuo stebėjimo iki apsaugos
Seka, kurios laikomės, paprasta ir sąmoningai lėta:
- Pirma — SPF ir DKIM. DMARC be jų neturi ko tikrinti. Kaip tai atrodo rinkodaros platformoje, aprašėme siuntimo domeno straipsnyje.
- Antra — stebėjimo politika. Įrašas su nurodytu ataskaitų adresu ir jokio poveikio laiškams.
- Trečia — ataskaitų skaitymas. Bent mėnuo, kad pamatytumėte ir retesnius šaltinius, pavyzdžiui, mėnesinių sąskaitų siuntimą.
- Ketvirta — trūkstamų šaltinių sutvarkymas. Kiekvienas teisėtas siuntėjas turi būti autentifikuotas.
- Penkta — karantinas, vėliau atmetimas. Tik tada, kai ataskaitose nebelieka nesutvarkytų teisėtų šaltinių.
Visas kelias didesnėje įmonėje paprastai užtrunka kelis mėnesius. Mažoje parduotuvėje, kur laiškus siunčia viena ar dvi sistemos, jis gali sutilpti į kelias savaites.
Kas yra atitikimas ir kodėl jis svarbus
Žodis, kurį DMARC prideda prie SPF ir DKIM, yra atitikimas. Be jo visa konstrukcija turėtų skylę.
Įsivaizduokite laišką, kurio matomas siuntėjo adresas yra jūsų domenas, bet SPF patikra sėkmingai praeina dėl visai kito domeno — to, kurį naudoja siuntimo serveris. Formaliai autentifikacija pavyko. Praktiškai gavėjas mato jūsų vardą laiške, kurio jūs nesiuntėte.
DMARC būtent tai ir sustabdo: jis reikalauja, kad autentifikacija būtų susieta su tuo domenu, kurį žmogus mato. Specifikacijoje tai apibūdinama kaip patikrinimas, ar žinutės identifikatoriai atitinka tai, ką gavėjas žino apie siuntėjo autentifikacijos infrastruktūrą.
Praktinė pasekmė rinkodarai tiesioginė. Jei siunčiate per platformą ir nesukonfigūravote savo siuntimo domeno, atitikimo gali nebūti — laiškai eina platformos infrastruktūra, o siuntėjo adresas rodo jūsų domeną. Todėl šie du darbai daromi kartu, ne atskirai.
Ką tai keičia el. pašto rinkodarai
Tiesioginio ryšio tarp DMARC ir atidarymo rodiklių nėra — tai ne rinkodaros, o saugumo priemonė. Bet netiesioginis poveikis realus dviem atžvilgiais.
Pirma, reikalavimai. Google siuntėjų gairėse nurodyta, kad siuntėjai, per parą siunčiantys daugiau nei 5 000 laiškų į Gmail adresus, privalo turėti DMARC įrašą siuntimo domenui. Tai jau ne rekomendacija.
Antra, apsauga nuo klastojimo. Jei kas nors siunčia sukčiavimo laiškus jūsų prekės ženklo vardu, nukenčia ne tik gavėjai — nukenčia ir jūsų domeno reputacija, o kartu ir teisėtų laiškų pristatomumas. Kaip tai susiję su visais kitais pristatomumo rodikliais, aprašėme pristatomumo straipsnyje.
Orientyrai vienoje vietoje
Klaidos, kurias matome audituose
- Iškart įjungiamas atmetimas. Perskaičius, kad tai „geriausia praktika“, praleidžiamas stebėjimo etapas ir sustoja dalis sistemų.
- Ataskaitų niekas neskaito. Įrašas yra, bet ataskaitos keliauja į niekieno nenaudojamą adresą.
- Pamirštami vidiniai siuntėjai. Sąskaitos ir vidinės sistemos dažnai sutvarkomos paskutinės, nes apie jas rinkodara nežino.
- Manoma, kad DMARC pakeičia SPF ir DKIM. Jis be jų neveikia — tai sluoksnis virš, ne vietoje.
- Įrašas pridėtas ir pamirštas. Pridėjus naują siuntimo sistemą, autentifikaciją reikia sutvarkyti ir jai.
Kodėl svarbu, kuriam domenui taikoma politika
DMARC politika taikoma domenui, o kartu ir jo subdomenams — nebent nurodyta kitaip. Tai turi tiesioginį poveikį rinkodarai, ir apie tai dažnai pamirštama.
Jei laiškus siunčiate per atskirą subdomeną, kaip aprašėme siuntimo domeno straipsnyje, jam galioja pagrindinio domeno politika. Vadinasi, įjungę griežtą politiką pagrindiniam domenui, ją įjungiate ir rinkodaros siuntimams — net jei apie tai negalvojote.
Specifikacijoje numatyta galimybė subdomenams nurodyti atskirą politiką. Praktiškai tai naudinga pereinamuoju laikotarpiu: pagrindiniam domenui galima įjungti griežtesnę apsaugą anksčiau, o subdomenui, per kurį eina rinkodara, kurį laiką palikti švelnesnę, kol įsitikinama, kad viskas autentifikuojasi tvarkingai.
Svarbu tai suderinti su tuo, kas tvarko įmonės DNS. Rinkodaros komanda dažnai nežino, kad IT ką tik sugriežtino politiką, o IT nežino, kad tai paveiks naujienlaiškius — ir problema pastebima tik tada, kai krenta pristatymo rodikliai.
Nuo ko pradėti
Jei DMARC įrašo dar neturite, pirmas žingsnis yra stebėjimo politika su veikiančiu ataskaitų adresu. Ji nieko nerizikuoja ir per savaitę parodo, kas realiai siunčia jūsų vardu — dažniausiai tai ir būna naudingiausias atradimas.
Jei įrašas yra, patikrinkite du dalykus: ar ataskaitos kur nors keliauja ir ar politika vis dar stebėjimo režime po dvejų metų. Antrasis atvejis reiškia, kad apsauga taip ir nebuvo įjungta. Kaip tai sutvarkome kartu su likusia pristatomumo dalimi, aprašome automatizacijų puslapyje.