Email Security Hardening – Deo 1: SPF, DKIM i DMARC

Ovim tekstom počinje nova serija posvećena email bezbednosti — počev od tri protokola koji čine osnovu email autentifikacije (SPF, DKIM, DMARC), preko anti-phishing i BEC zaštite, do konkretnih platformi (Exchange, Google Workspace) u kasnijim delovima. Email ostaje, i u 2026. godini, najčešći ulazni vektor za ozbiljne bezbednosne incidente — ne zato što su druge tehnike napredovale manje, već zato što email inherentno zahteva da čovek na drugom kraju donese odluku (kliknuti ili ne, verovati pošiljaocu ili ne), što ga čini metom koja zaobilazi tehničku odbranu direktnim ciljanjem ljudskog rasuđivanja.

Zašto ovo više nije opciono — regulatorni i tehnički pritisak istovremeno

Vredi otvoriti seriju konstatacijom koja je bila diskutabilna pre par godina, a danas nije: email autentifikacija prestala je da bude preporuka i postala tehnički i, u sve više jurisdikcija i industrija, regulatorni zahtev. Najveći mailbox provajderi (Google, Yahoo, Microsoft) sprovode zahteve za autentifikacijom prema domenima koji šalju u većem obimu, sa direktnom, merljivom posledicom za organizacije koje to ne ispune — email jednostavno ne stiže do inbox-a, ili biva odbačen u celini.

Realno stanje adoptiranja, ipak, pokazuje veliki jaz između svesti o problemu i stvarne primene: istraživanja koja prate više od milion domena globalno pokazuju da tek nešto preko desetine domena ima punu zaštitu sa strogom politikom odbijanja na punoj primeni, dok značajna većina i dalje nema efektivnu DMARC zaštitu uopšte. Ovaj tekst ima za cilj da objasni ne samo šta svaki od tri protokola radi, već i zašto je tako čest slučaj da organizacija "ima" SPF/DKIM/DMARC formalno postavljene, a i dalje ostaje ranjiva na spoofing napade zbog nepotpune ili pogrešne konfiguracije.

SPF — ko sme da šalje u ime vašeg domena

Sender Policy Framework je najstariji i konceptualno najjednostavniji od tri protokola: DNS TXT zapis koji eksplicitno navodi koji mejl serveri (po IP adresi ili referenci na drugi domen) imaju ovlašćenje da šalju mejlove u ime vašeg domena. Server koji prima mejl proverava IP adresu sa koje je poruka stigla protiv ove liste — ako se IP adresa ne poklapa sa dozvoljenim opsegom, SPF provera ne prolazi.

Ovde vredi objasniti tehničko ograničenje koje je čest, konkretan izvor grešaka u praksi: SPF standard postavlja tvrd limit od deset DNS lookup operacija po proveri (svaki "include" mehanizam koji upućuje na drugi domen troši jedan od tih deset). Organizacije koje koriste više od pet različitih servisa za slanje mejlova (marketing platforma, CRM, transakcioni mejl provajder, interni server, i tako dalje) često nesvesno pređu ovaj limit, što rezultuje u tihom, potpunom neuspehu SPF provere za sav njihov mejl — ne samo za onaj deo koji premašuje limit.

Šta treba uraditi

• Popisati svaki servis koji legitimno šalje mejlove u ime organizacionog domena (interni mejl server, marketing platforma, CRM, sistemi za fakturisanje, treće-stranački alati) pre pisanja SPF zapisa, ne dodavati servise ad-hoc kako se pojave
• Brojati DNS lookup operacije koje SPF zapis stvarno generiše (svaki include, a, mx, ptr, exists mehanizam) i proveriti da ukupan broj ostaje ispod deset — besplatni online alati za proveru SPF zapisa ovo direktno prikazuju
• Za organizacije koje premaše limit, koristiti SPF flattening — tehniku koja rešava include lance direktno na IP adrese i ugrađuje ih u sam zapis, eliminišući dodatne lookup operacije po cenu potrebe za redovnim, automatizovanim ažuriranjem kad se IP adrese davalaca usluga promene
• Postaviti SPF zapis i za EHLO/HELO domen i za RFC5321.MailFrom (envelope sender) domen, ne samo za vidljivi From domen — oba su relevantna za potpunu, ispravnu proveru
• Završiti SPF zapis sa -all (strogo odbijanje, hard fail) kao dugoročni cilj, ne sa ~all (blago odbijanje, soft fail) trajno — ~all je razuman privremeni korak tokom testiranja, ali ne konačno stanje za domen koji šalje stvarnu poslovnu poštu

DKIM — kriptografski potpis koji dokazuje da sadržaj nije menjan

DomainKeys Identified Mail radi na suštinski drugačijem principu od SPF-a: umesto proveravanja odakle je mejl stigao, DKIM kriptografski potpisuje sadržaj same poruke prilikom slanja, koristeći privatni ključ koji poseduje samo pošiljalac, i taj potpis se proverava javnim ključem objavljenim u DNS zapisu. Ako je bilo šta u potpisanom sadržaju (uključujući ključna zaglavlja poput From) izmenjeno nakon potpisivanja, provera potpisa neće proći — DKIM tako dokazuje i poreklo i integritet, ne samo poreklo kao SPF.

DKIM koristi koncept selektora — DNS zapis se objavljuje na putanji poput selector._domainkey.domen.com, gde selektor omogućava da isti domen ima više aktivnih ključeva istovremeno, što je ključno za bezbednu rotaciju ključeva bez prekida u isporuci mejlova.

Šta treba uraditi

• Koristiti isključivo 2048-bitne RSA ključeve kao standard za 2026. godinu — stariji, 1024-bitni ključevi se smatraju slabim i pojedini mailbox provajderi ih već odbijaju ili planiraju odbijati
• Rotirati DKIM ključeve redovno, sa razumnim polaznim intervalom od šest do dvanaest meseci za većinu organizacija, češće za visoko-osetljive ili regulisane sektore (finansije, zdravstvo)
• Sprovesti rotaciju kroz dual-selector period preklapanja — objaviti novi ključ pod novim selektorom uz zadržavanje starog selektora i ključa aktivnim, prebaciti stvarno potpisivanje na novi selektor, i tek nakon perioda od jedne do dve nedelje (dovoljno da se pokriju mejlovi koji su možda bili u tranzitu, odloženi, ili prosleđeni) ukloniti stari zapis
• Nikad ne brisati stari DKIM DNS zapis odmah po prebacivanju na novi ključ — ovo je najčešća, praktična greška koja izaziva neuspešnu proveru za mejlove koji su potpisani starim ključem, a stignu na odredište nakon što je stari javni ključ već uklonjen iz DNS-a
• Koristiti odvojene selektore za različite tokove pošte (npr. transakcioni mejl nasuprot marketinškim kampanjama) gde se koriste različiti sistemi za slanje — ovo olakšava izolovano rešavanje problema ako jedan tok počne da ima probleme sa autentifikacijom, bez uticaja na ostale
• Čuvati privatni ključ u bezbednom skladištu (namenski keystore ili HSM za organizacije sa višim zahtevima), sa ograničenim pristupom i dokumentovanim vlasništvom, po istom principu čuvanja kritičnih kredencijala koji se provlači kroz svaku seriju na ovom blogu

DMARC — politika koja povezuje SPF i DKIM sa onim što korisnik stvarno vidi

Ovo je koncept vredan najdetaljnijeg objašnjenja u celom tekstu, jer je izvor najvećeg broja pogrešnih pretpostavki u praksi. DMARC nije treći, nezavisan mehanizam autentifikacije — to je sloj politike koji sedi iznad SPF-a i DKIM-a i rešava problem koji nijedan od njih sam po sebi ne rešava: poravnanje (alignment) sa domenom koji korisnik stvarno vidi u polju "od" (From header).

Bez DMARC-a, napadač može poslati mejl koji uspešno prolazi i SPF i DKIM proveru — ali koristeći sopstvenu infrastrukturu i sopstveni domen za tehničke provere, dok istovremeno u vidljivom From polju prikazuje ime žrtvinog, poverljivog domena. Tehnička autentifikacija "prolazi", ali za pogrešan, napadačev domen — korisnik i dalje vidi ono što izgleda kao legitiman pošiljalac. DMARC zatvara ovu rupu zahtevajući da domen koji je prošao SPF i/ili DKIM proveru bude poravnat (identičan ili u odgovarajućem odnosu poddomena) sa domenom koji se vidi u From polju.

Druga, podjednako bitna zabluda: mnoge organizacije objave DMARC zapis sa politikom p=none i smatraju da su time "zaštićene". p=none znači isključivo monitoring — DMARC prikuplja izveštaje o tome ko šalje mejl u ime domena i da li prolazi proveru, ali ne preduzima nikakvu akciju protiv mejlova koji ne prolaze. Ovo je legitiman, čak neophodan prvi korak, ali sam po sebi ne pruža nikakvu stvarnu zaštitu od spoofing napada — zaštita počinje tek sa p=quarantine ili p=reject.

Šta treba uraditi

• Objaviti DMARC zapis sa p=none i uključenim agregatnim izveštavanjem (rua= tag koji usmerava izveštaje na email adresu ili servis za analizu) kao prvi, obavezan korak — ovo daje vidljivost u to ko trenutno šalje mejl u ime domena, uključujući legitimne, možda zaboravljene servise, pre nego što se bilo šta blokira
• Pregledati agregatne izveštaje redovno (nedeljno tokom perioda monitoringa) i identifikovati sve legitimne izvore slanja koji ne prolaze autentifikaciju, ispravljajući njihov SPF/DKIM pre prelaska na strožu politiku
• Postaviti konkretan, vremenski ograničen plan progresije — razuman polazni obrazac je cilj od 90 dana za prelazak na p=quarantine (sumnjivi mejlovi se šalju u spam/karantin, ne odbacuju u potpunosti) i dodatnih 90 dana (ukupno oko 180) za prelazak na p=reject (potpuno odbijanje) — ne ostavljati domen trajno na p=none
• Osigurati poravnanje i za SPF (envelope sender domen mora odgovarati From domenu, ili biti njegov poddomen pod strict modom) i za DKIM (d= vrednost u DKIM potpisu mora odgovarati From domenu) — DMARC prolazi ako bar jedan od ta dva ispravno poravnat mehanizam uspe, ali oba zaslužuju proveru
• Primeniti DMARC i na poddomene koji ne šalju mejl uopšte (parkirani poddomeni) — ovo sprečava napadača da iskoristi baš takav, naizgled neaktivan poddomen za spoofing, jer bez eksplicitne DMARC politike, poddomen po difoltu nasleđuje slabiju, podrazumevanu zaštitu
• Pratiti noviju DMARCbis specifikaciju (RFC 9989, objavljenu u maju 2026. godine) za izmene u tome kako se novi zapisi treba da budu strukturirani, budući da se standard i dalje razvija

Napomena o riziku: prelazak direktno na p=reject bez prethodnog, dovoljno dugog perioda monitoringa na p=none nosi realan rizik blokiranja legitimne poslovne pošte — zaboravljen ili nepoznat servis koji šalje u ime domena (stari marketing alat, sistem za fakturisanje koji je neko davno podesio i zaboravio) biće u potpunosti odbačen čim se stroga politika uključi, često bez ikakvog jasnog upozorenja korisniku ili pošiljaocu da se to dešava. Sprovesti progresiju postepeno, sa stvarnim pregledom izveštaja u svakoj fazi, po istom principu faznog uvođenja koji se provlači kroz svaku operativno osetljivu promenu opisanu kroz celu ovu seriju blogova.

Zajednička disciplina — email autentifikacija nije jednokratan projekat

Isti princip koji se ponavlja kroz svaku seriju na ovom blogu ima ovde direktnu primenu: SPF, DKIM i DMARC zahtevaju kontinuirano održavanje, ne jednokratno podešavanje. Novi servis koji počne da šalje mejlove u ime domena, a nije dodat u SPF zapis, tiho počinje da ne prolazi autentifikaciju. Ključ koji istekne bez rotacije postaje slabija karika. DMARC izveštaji koji se prestanu pratiti prestaju da pružaju ranu vidljivost u nove, nastale probleme.

Šta treba uraditi

• Voditi dokumentovan popis svih servisa ovlašćenih da šalju mejl u ime organizacionog domena, ažuriran kad god se novi servis uvede ili stari ukine — isti princip dokumentacije koji se provlači kroz svaku seriju na ovom blogu
• Sprovoditi kombinovanu, redovnu reviziju SPF i DKIM konfiguracije (kvartalno ili godišnje, u zavisnosti od bezbednosnog apetita organizacije) — rotacija DKIM ključa je prirodan trenutak da se istovremeno proveri i SPF lookup broj, budući da oba imaju tendenciju da vremenom "driftuju" od ispravnog stanja
• Nastaviti da prati DMARC agregatne izveštaje i nakon dostizanja p=reject, ne samo tokom perioda monitoringa — novi anomalni izvor slanja koji se pojavi nakon što je politika već stroga i dalje zaslužuje istragu, jer može ukazivati na pokušaj spoofing napada koji je DMARC uspešno blokirao, ali čije postojanje vredi razumeti

Sledeći deo serije prelazi na anti-phishing i Business Email Compromise (BEC) zaštitu — principe koji dopunjuju tehničku autentifikaciju obrađenu u ovom delu, usmerene na scenarije gde napadač uspešno prođe kroz tehničke provere (ili ih zaobiđe kroz kompromitovan legitiman nalog) i osloni se umesto toga na ubeđivanje čoveka na drugom kraju.