Zašto mailovi idu u spam — i kako to trajno riješiti

Zato što primatelj ne može potvrditi da je poruka doista Vaša — a ne zato što ste negdje u tekstu napisali „gratis“. Filtri velikih primatelja prvo provjeravaju identitet pošiljatelja, pa tek onda sadržaj.

Uzroci se svode na tri skupine, i gotovo uvijek se rješavaju tim redom:

1. Autentikacija domene. SPF, DKIM i DMARC govore tuđem poslužitelju smijete li Vi slati u ime svoje domene. Google izrijekom navodi da poruke koje nisu autentificirane tim metodama mogu biti označene kao neželjene ili odbijene s greškom 5.7.26.

2. Ugled domene i IP adrese. Domena i IP adresa s koje šaljete nose povijest. Stopa prijava spama, količina koja skoči preko noći i dijeljena IP adresa na hosting paketu ulaze u istu ocjenu.

3. Higijena i pristanak. Stare adrese, kupljene liste, odjava koju je teško naći. To je dio koji filtar ne vidi u DNS-u nego u ponašanju primatelja.

Postoji i četvrti pojam, bez vlastite kratice, a ruši najviše legitimne pošte: poravnanje. Zbog njega poruka pada i onda kad i SPF i DKIM pišu pass. Razložili smo ga u zasebnom odjeljku niže.

Ostalo — slike, prilozi, duljina teksta — utječe tek na rubu, i gotovo nikad prije nego se prve dvije skupine srede. Stručni naziv za cijelu temu je isporučivost, a pojam je objašnjen i u pojmovniku.

Ako želite vidjeti gdje ste sada, ne morate čitati dalje da biste počeli: provjerite svoju domenu u 30 sekundi, bez registracije.

Ako Vam treba samo popis za provjeru, on je niže u tekstu — petnaest stavki s odgovorom da ili ne, prije nego pošaljete iduću kampanju.

Širi okvir teme — od dolazne zaštite do rezervnih kopija — pokriva krovni vodič o email sigurnosti za tvrtke.

To su dva različita problema i rješavaju se s dvije različite strane. Isti upit u tražilicu upisuju i oni kojima poruke padaju u tuđi spam i oni kojima u vlastiti sandučić stiže previše neželjene pošte.

Ako Vaše poruke ne stižu drugima, problem je u tome kako Vas vidi tuđi poslužitelj: SPF, DKIM, DMARC, poravnanje i ugled domene. O tome je ostatak ovog teksta.

Ako Vama stiže neželjena pošta, problem je u zaštiti dolazne pošte — filtriranju, analizi priloga i phishingu. To je drugi smjer i drugi alat; pokriva ga usluga e-mail sigurnosti.

Ta dva smjera dijele samo naziv. Zapisi u DNS-u ne mijenjaju ništa u onome što Vama dolazi, a filtar dolazne pošte ne mijenja ništa u tome kako Vaše poruke izgledaju Gmailu.

Postoji jedna točka u kojoj se dodiruju: preuzet sandučić. Račun koji tjedan dana šalje spam u Vaše ime ruši ugled domene brže od bilo koje greške u zapisima — i tada oba smjera postaju isti problem.

Sva četiri velika primatelja traže istu jezgru — SPF, DKIM i DMARC s poravnanjem — a Gmail i Outlook.com to od 2024. odnosno 2025. i naplaćuju odbijanjem poruka. Uvjeti su javni; mijenja se strogoća provođenja, ne sadržaj.

Primatelj	Prag za stroži skup	Što traži od svih	Od kada
Gmail	5.000 poruka dnevno prema privatnim računima	SPF ili DKIM, PTR, TLS, RFC 5322, prijave spama ispod 0,30 %	1. 2. 2024.
Yahoo	prag se izrijekom ne objavljuje	SPF ili DKIM, PTR, prijave ispod 0,3 %	2/2024., odjava 6/2024.
Outlook.com, Hotmail, Live	5.000 poruka dnevno s istom domenom u 5322.From	SPF i DKIM koji prolaze, DMARC uz poravnanje	5. 5. 2025.
iCloud Mail	prag se ne objavljuje	SPF, DKIM, objavljena DMARC politika, obrnuti DNS	bez javnog datuma

Gmail

Za sve pošiljatelje prema privatnim Gmail računima, od 1. veljače 2024.: postaviti SPF ili DKIM, imati ispravne forward i reverse DNS zapise (PTR), koristiti TLS za prijenos, držati stopu prijava spama u Postmaster Toolsu ispod 0,30 %, oblikovati poruke po RFC-u 5322 i ne lažirati Gmail From zaglavlja.

Za 5.000 i više poruka dnevno prema privatnim Gmail računima dodatno: i SPF i DKIM, DMARC (Google izrijekom dopušta da politika bude none), poravnanje — domena iz From: zaglavlja mora biti poravnata sa SPF ili DKIM domenom — te odjava u jednom kliku uz jasno vidljivu poveznicu u tijelu poruke.

Uz zahtjeve stoji i preporuka koja je stroža od praga: stopu prijava spama držati ispod 0,10 % i nikada ne dosegnuti 0,30 % ili više.

Novo je provođenje. Google u čestim pitanjima navodi da od studenoga 2025. pojačava postupanje prema nesukladnom prometu te da poruke koje ne ispunjavaju uvjete nailaze na smetnje, uključujući privremena i trajna odbijanja.

Yahoo

Yahoo je s provođenjem krenuo u veljači 2024., a s pravilom o zaglavlju za odjavu u lipnju 2024. Za sve pošiljatelje traži barem SPF ili DKIM, ispravan forward i reverse DNS zapis za IP adrese s kojih se šalje, usklađenost s RFC-ovima 5321 i 5322 te stopu prijava ispod 0,3 %.

Za masovne pošiljatelje traži i SPF i DKIM, valjanu DMARC politiku barem p=none koja prolazi, poravnanje From domene sa SPF ili DKIM domenom, zaglavlje za odjavu u jednom kliku, vidljivu poveznicu za odjavu i izvršenu odjavu u roku od dva dana.

Jedan detalj vrijedi zapamtiti: Yahoo u čestim pitanjima izrijekom kaže da neće navesti prag količine. Računica „mi smo maleni, nas se ne tiče“ kod Yahooa dakle nema uporište.

Outlook.com, Hotmail i Live

Microsoft za domene koje šalju 5.000 i više poruka dnevno prema svojim potrošačkim servisima, i to s istom domenom u adresi 5322.From, traži da SPF prođe, da DKIM prođe i da postoji DMARC zapis (primjer u dokumentaciji je p=none) poravnat sa SPF-om ili DKIM-om.

Prema Microsoftovoj najavi za visokovolumne pošiljatelje, od 5. svibnja 2025. nesukladne se poruke odbijaju. Odbijena poruka nosi oznaku 550 5.7.515 Access denied, sending domain … does not meet the required authentication level.

Jedna ograda o samom izvoru, prema dokumentaciji pročitanoj 5. rujna 2026.: ista Microsoftova objava uz odluku o odbijanju i dalje nosi i stariji odlomak po kojem se poruke od istog datuma najprije usmjeravaju u neželjenu poštu. Mjerodavna je novija odluka.

To je jedini zahtjev velikog primatelja kod kojeg posljedica nije mapa neželjene pošte nego tvrdo odbijanje na SMTP razini — i zato jedini koji klijent primijeti isti dan.

Uz to Microsoft navodi i higijenu koja nije DNS: valjanu From odnosno Reply-To adresu koja može primiti odgovor, funkcionalnu poveznicu za odjavu, čišćenje liste i upravljanje odbijenim adresama te točne naslove i stvaran pristanak primatelja.

I jedna rečenica koju vrijedi izrezati i zalijepiti iznad stola: popis sigurnih pošiljatelja neće biti uvažen. Ako poruka ne prolazi autentikaciju, to što Vas je primatelj dodao među sigurne pošiljatelje neće je spasiti.

iCloud Mail

Apple na stranici za pošiljatelje traži SPF, DKIM po RFC-u 6376 i objavljenu DMARC politiku, uz obrnuti DNS zapis koji povezuje IP adrese s Vašom domenom. U uzorku od 38 hrvatskih stranica o ovoj temi koji smo pregledali iCloud ne spominje nijedna; uzorak je popis pročitanih sadržaja, a ne mjerenje pozicija u tražilici.

Dvije rečenice s te stranice vrijede više od cijelog poglavlja o sadržaju. Prva: iCloud poštuje politiku koju domena objavi — dakle Vaš p=reject ondje doista djeluje. Druga: Apple nema popis dopuštenih pošiljatelja, nego prati ugled IP adrese i domene.

Apple izrijekom traži i higijenu liste: povremeno uklanjanje neaktivnih primatelja, poštovanje odjava i uklanjanje adresa koje se stalno odbijaju.

Da — šest Gmailovih zahtjeva vrijedi za svakog pošiljatelja, a prag od 5.000 dodaje samo tri obveze. To je najčešći nesporazum kod hrvatskih tvrtki koje dnevno pošalju dvadesetak ponuda i računa.

Vrijedi za sve, bez obzira na količinu:

1. SPF ili DKIM za domenu s koje se šalje — barem jedno, ne nužno oboje.
2. Valjani forward i reverse DNS zapisi (PTR) za domene odnosno IP adrese.
3. TLS veza pri prijenosu poruke.
4. Stopa prijava spama u Postmaster Toolsu ispod 0,30 %.
5. Oblikovanje poruka po standardu RFC 5322.
6. Zabrana lažnog predstavljanja u Gmailovim From: zaglavljima.

Prag od 5.000 dodaje tri stvari: DMARC zapis (politika smije biti none), poravnanje domene iz From: sa SPF ili DKIM domenom te odjavu u jednom kliku uz vidljivu poveznicu.

Kako se prag broji, važno je koliko i sam broj. Poruke s poddomena zbrajaju se s glavnom domenom, a prag se odnosi na privatne račune na gmail.com — ne na tvrtke koje poštu primaju na Google Workspaceu.

I jedna posljedica koju malo tko očekuje: status masovnog pošiljatelja, jednom dodijeljen, nema rok trajanja. Tko prag prijeđe jednom, za Google ostaje masovni pošiljatelj.

Yahoo prag uopće ne objavljuje i izrijekom kaže da ga neće odrediti. Microsoft navodi da provođenje prvo cilja velike pošiljatelje, ali da snažna autentikacija štiti ugled svakog pošiljatelja.

Za malu tvrtku razlika je praktična, ne teorijska. Vaših dvadeset poruka nosi ponude, račune i odgovore na upite. Kod velikog pošiljatelja pad se vidi u statistici; kod Vas se vidi tako da klijent kaže da nije dobio ponudu.

Zato je odgovor na pitanje „trebamo li mi DMARC“ isti bez obzira na količinu: trebate, ali iz drugog razloga — DMARC je kontrola tko smije slati u ime Vaše domene, a uredna isporuka je nuspojava koja dođe uz to.

Zato što DMARC ne pita je li SPF prošao, nego je li prošao za istu domenu koja piše u From: zaglavlju. Taj uvjet zove se poravnanje i on je razlog zbog kojeg poruka s dva pass retka svejedno završi u neželjenoj pošti.

RFC 7489 to definira izravno: kad se domena iz From: zaglavlja podudara s domenom koju je potvrdio SPF ili DKIM, postoji poravnanje identifikatora. Ako se ne podudara, DMARC pada bez obzira na to koliko je provjera prošlo.

Poravnanje ima dvije strogoće. Opušteno traži istu organizacijsku domenu, pa se newsletter.tvrtka.hr i tvrtka.hr poravnavaju. Strogo traži identičnu domenu. Zadano je opušteno (aspf=r, adkim=r).

Tu razliku hrvatski vodiči praktički ne objašnjavaju, a upravo ona odlučuje hoće li Vaša poddomena za novosti proći ili pasti.

Kako to izgleda u praksi: šaljete kroz vanjski servis, on poruku šalje sa svoje omotnice i potpisuje je svojom domenom. SPF prolazi za njegovu domenu, DKIM prolazi za njegovu domenu, a u From: stoji Vaša — dakle nijedan potvrđeni identitet nije Vaš.

Zato Gmail i Microsoft ne traže puki pass nego poravnanje. Google to kaže jednom rečenicom: domena iz From: zaglavlja mora biti poravnata sa SPF domenom ili s DKIM domenom.

Rješenje nije mijenjati sadržaj nego natjerati servis da potpisuje Vašom domenom, s Vašim DKIM ključem, i da za povratnu adresu koristi Vašu poddomenu. Kako se to točno traži po platformi, u odjeljku o najčešćim greškama.

Jest — od svibnja 2026. DMARC je RFC 9989, dokument s oznakom Standards Track, koji zamjenjuje dosadašnji RFC 7489. Do tada je bio informativni dokument; sada je standard.

Zapisi koje već imate i dalje rade. Oblik v=DMARC1; p=none; rua=… nije se promijenio, pa nema ničega što biste morali prepisati preko noći.

Promijenio se popis oznaka. Izbačene su tri: pct, rf i ri — dodatak A.6 novog dokumenta nosi naslov o uklanjanju oznake pct.

Dodane su tri: np za politiku prema nepostojećim poddomenama, psd za domene javnog sufiksa i t za testni način rada.

Treća promjena je tiha, a mijenja postupak: organizacijska domena više se ne traži u Public Suffix Listu nego obilaskom DNS stabla. Za većinu hrvatskih domena ishod je isti, ali više ne ovisi o popisu koji održava netko treći.

Praktična posljedica za Vas: savjet „stavite oznaku pct na deset posto pa polako dižite“ — do jučer standardna preporuka, i još posvuda po internetu — više nije dio specifikacije.

Postupnost se sada izražava drukčije: kroz t za testni način i kroz sp odnosno np za poddomene. Tko danas piše vodič s postotkom, piše po dokumentu koji je zamijenjen.

Ako Vam je netko postavio DMARC prije 2026., vrijedi otvoriti zapis i vidjeti sadrži li još izbačene oznake. Nisu opasne, ali su znak da ga nitko nije dirao otkako je postavljen.

Dublje o zapisu i o tome kako se politika steže bez gubitka pošte: DMARC u Hrvatskoj, a sloj iznad njega pokriva vodič kroz MTA-STS, TLS-RPT i BIMI.

Počnite od zapisa u DNS-u, jer se ondje vidi većina uzroka, a provjera traje kraće od minute. Tek ako je DNS uredan, ima smisla kopati po sadržaju i listi.

1. Provjerite domenu. Naš besplatni alat prolazi trinaest provjera — DMARC, SPF, DKIM, MX, MTA-STS, TLS-RPT, DNSSEC i ostale — i objašnjava svaki nalaz na hrvatskom, bez žargona. Provjerite svoju domenu u 30 sekundi, bez registracije; domena se pritom ne sprema, a kako se ocjenjuje piše u metodologiji.

2. Otvorite zaglavlje jedne poruke koja je pala. U retku Authentication-Results piše spf=, dkim= i dmarc=. Tri puta pass znači da uzrok nije autentikacija; bilo koji fail ili none pokazuje točno gdje pukne. Kako se taj redak čita polje po polje, u sljedećem je odjeljku.

3. Uključite Postmaster Tools. Google ondje prikazuje stopu prijava spama, reputaciju domene i IP adrese te nadzornu ploču sukladnosti sa zahtjevima za pošiljatelje. Bez toga o stopi prijava samo nagađate.

4. Čitajte DMARC izvještaje. Izvještaji koje šalju tuđi poslužitelji jedini su izvor koji pokazuje tko stvarno šalje u ime Vaše domene — uključujući alate za koje ste zaboravili da postoje.

5. Pročitajte kod odbijanja. 5.7.26 kod Gmaila i 550 5.7.515 kod Outlooka nisu tehnička sitnica nego izravan odgovor: poruka je odbijena zbog autentikacije domene iz From: zaglavlja.

Otvorite izvornik poruke i pronađite redak Authentication-Results — ondje piše ishod svake provjere i, još važnije, za koju je domenu ta provjera prošla. To je jedini odgovor koji ne ovisi ni o čijem mišljenju.

Zaglavlje definira RFC 8601. Do njega se dolazi u dva klika: u Gmailu kroz tri točkice i Prikaži izvornik, u Outlooku kroz Datoteka → Svojstva → Internetska zaglavlja.

Ovako izgleda redak kad poruku šalje vanjski servis — primjer je konstruiran radi objašnjenja, nije stvarna poruka:

Authentication-Results: mx.google.com;
  spf=pass [email protected];
  dkim=pass header.d=servis.example;
  dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=tvrtka.hr

SPF piše pass, DKIM piše pass, a DMARC svejedno pada. Razlog je vidljiv golim okom: obje provjere pripadaju domeni servisa, a header.from je Vaša domena.

Tri polja koja se čitaju: smtp.mailfrom je domena s omotnice, header.d je onaj tko je poruku potpisao, a header.from je ono što čitatelj vidi.

Ako se header.d i header.from ne poklapaju u organizacijskoj domeni, DMARC pada bez obzira na dva pass retka. To je poravnanje iz prethodnog odjeljka, vidljivo u jednom retku teksta.

Vrijednosti nisu samo pass i fail. Za SPF su moguće i softfail, neutral, none, temperror te permerror — a permerror gotovo uvijek znači prekoračenih deset DNS upita ili dva zapisa na istoj domeni.

Provjerite na dvije strane: pošaljite si poruku na Gmail i na Outlook.com. Primatelji se razlikuju u strogoći, pa se razlikuje i ono što ćete pročitati.

U uzorku od 38 hrvatskih stranica o ovoj temi koji smo pregledali čitanje zaglavlja objašnjava jedna. Uzorak je popis sadržaja koje smo otvorili i pročitali, a ne mjerenje pozicija u tražilici.

SPF je popis poslužitelja koji smiju slati u Vaše ime, DKIM je potpis na poruci, a DMARC je pravilo što učiniti kad prvo dvoje ne prođe. Sve troje su zapisi u DNS-u Vaše domene i sve troje postavlja onaj tko upravlja domenom.

SPF govori primatelju s kojih poslužitelja smije stići pošta Vaše domene. Ako alat koji šalje u Vaše ime nije na tom popisu, poruka je za primatelja sumnjiva.

DKIM je kriptografski potpis kojim primatelj provjerava da potpisani dijelovi poruke nisu mijenjani na putu i da domena stoji iza nje.

DMARC spaja to dvoje i daje uputu: p=none samo prijavljuje, p=quarantine šalje sumnjive poruke u neželjenu poštu, p=reject ih odbija.

Četvrti pojam nema svoju kraticu, a ruši najviše legitimne pošte: poravnanje. Google to kaže izravno — domena iz From: zaglavlja mora se podudarati sa SPF ili DKIM domenom. Zato poruka može imati i SPF i DKIM koji prolaze, a DMARC svejedno pada.

U praksi se to događa kad alat šalje s vlastite domene, a u From: stavi Vašu. Potpis postoji, ali nije Vaš.

Detaljnije o svakom zapisu, i o tome kako se politika steže bez gubitka pošte: što je DMARC i DMARC u Hrvatskoj. Sloj iznad toga — MTA-STS, TLS-RPT i BIMI — pokriva zaseban vodič.

SPF gotovo uvijek padne, jer poruku dalje šalje tuđi poslužitelj sa svojom omotnicom — a DKIM preživi, pod uvjetom da poruka nije mijenjana. Zato se DKIM postavlja uvijek, a ne samo kad je obavezan.

Google to kaže izravno: prosljeđivanje utječe na autentikaciju, a proslijeđene poruke redovito padaju na SPF-u. Isto vrijedi za mailing liste koje poruci dodaju potpis u podnožju ili mijenjaju naslov — tada padne i DKIM.

U hrvatskoj praksi to izgleda ovako: klijent Vašu ponudu proslijedi kolegi, kolega je ne dobije, a Vi tražite grešku u svojoj poruci koje ondje nema.

Za tu rupu postoji mehanizam — ARC (RFC 8617). Posrednik koji poruku prosljeđuje u tri zaglavlja zapiše kakvo je stanje autentikacije bilo prije nego ju je primio, i to potpiše.

Ovdje je ograda važnija od mehanizma. RFC 8617 je eksperimentalan dokument, ne standard, i primatelj taj lanac smije uzeti kao jedan ulaz u odluku — ne mora.

Pošteno je, dakle, reći ovo: ARC daje primatelju dokaz o stanju autentikacije prije prosljeđivanja, a hoće li ga uvažiti, njegova je politika. Tvrdnja da „ARC rješava prosljeđivanje“ nije točna.

Zaključak za Vas nije ARC nego DKIM. On je jedina noga autentikacije koja preživi put kroz tuđi poslužitelj — domena bez njega gubi svaku proslijeđenu poruku.

U uzorku od 38 hrvatskih stranica koji smo pregledali ARC ne spominje nijedna.

Često jest, i to na dva načina: ugled dijelite s nepoznatim susjedima, a obrnuti DNS zapis nije Vaš nego hosterov. Ni jedno ni drugo ne popravlja se u tekstu poruke.

Google izrijekom navodi da aktivnost bilo kojeg pošiljatelja s dijeljene IP adrese utječe na ugled svih koji je koriste. Na hosting paketu ne znate ni tko još šalje s te adrese ni što šalje.

Drugi dio je PTR. Google i Yahoo traže valjan forward i reverse DNS zapis za IP adrese s kojih se šalje, a Apple traži objavljen obrnuti DNS koji povezuje IP adrese s Vašom domenom.

Operativni naziv za ispravan par je FCrDNS: PTR zapis IP adrese daje ime, a A ili AAAA zapis tog imena vraća istu IP adresu. To nije zaseban standard nego praksa koju primatelji provjeravaju.

Na dijeljenom hostingu PTR pokazuje na hosterovo ime i Vi ga ne možete promijeniti. Samo po sebi to nije greška — ali znači da ugled tog imena ne gradite Vi.

Kad se selidba isplati: kad poruke padaju iako su zapisi uredni, ili kad ne možete dobiti odgovor tko još šalje s iste adrese. Što se točno mijenja, razložili smo u usporedbi hostinga s Microsoftom 365 i Google Workspaceom.

Postavke na strani sandučića — tko smije slati, čime se potpisuje i što se bilježi — pokriva Microsoft 365 sigurnost, a Google stranu zaseban vodič kroz Workspace zapise.

U uzorku od 38 hrvatskih stranica koji smo pregledali PTR spominje jedna.

Sedam grešaka koje u našim mjerenjima izlaze uvijek iznova — i nijedna nema veze sa sadržajem poruke. U vlastitom mjerenju hrvatskih domena čak 68,3 % onih koje primaju poštu nema DMARC koji stvarno blokira: 31,9 % ga nema uopće, a 36,4 % ima p=none koji samo prijavljuje.

1. Pošta ostaje na hosting paketu s dijeljenom IP adresom. Google izrijekom navodi da aktivnost bilo kojeg pošiljatelja s dijeljene IP adrese utječe na reputaciju svih koji je koriste. Vi ne kontrolirate tko još šalje s te adrese.

2. SPF preko deset DNS upita. Standard (RFC 7208) ograničava provjeru na deset upita; iznad toga provjera završava greškom i SPF praktički ne postoji. Microsoft na isti problem upozorava u svojim čestim pitanjima. Nastaje tiho — svaki novi alat doda svoj include.

3. DKIM se nikad nije uključio. U našem mjerenju gotovo trećina domena koje primaju poštu nema DKIM. Bez potpisa ostaje samo SPF, koji pri prosljeđivanju poruke redovito pada.

4. Godine na p=none. Zapis postoji, izvještaji nikamo ne stižu, politika se nikad ne steže. Domena izgleda zaštićeno, a nije — i za primatelja se ništa ne mijenja.

5. Mekši ~all umjesto -all. Među hrvatskim domenama koje SPF imaju, 48,1 % koristi ~all. Hrvatske tehničke preporuke traže -all, uz upozorenje da pogrešno postavljen zapis s -all može odbaciti legitimnu poštu — zato se prvo popisuju pošiljatelji, pa tek onda steže.

6. Alat koji šalje u Vaše ime nitko nije prijavio. Webshop, CRM, alat za novosti, sustav za e-račune, obrazac na stranici. Svaki od njih mora biti u SPF-u i potpisivati DKIM-om za Vašu domenu, inače poravnanje pada.

7. Liste bez pristanka. Google izrijekom savjetuje da se adrese ne kupuju i da se ne šalje ljudima koji se nisu prijavili. Prijave spama su najskuplja valuta koju imate jer se ne resetiraju odlukom.

Kako to izgleda na razini cijelog tržišta, s brojkama i metodologijom: stanje email sigurnosti u Hrvatskoj i koliko se poštuju hrvatske službene preporuke.

U našem mjerenju od 31. svibnja 2026. njih 2.613 od 6.259 provjerenih .hr domena (41,7 %) nema nijedan DMARC zapis — a 2.087 od tih domena ipak prima poštu. Dakle nisu parkirane; u njihovo se ime može slati.

Prag je ovdje važan koliko i brojka. MX zapis tražili smo na tri razlučivača i priznali ga kad ga potvrdi većina njih. Na barem jednom razlučivaču MX ima 2.184 domene, pa je stvarni raspon 2.087 do 2.184 — kao verdikt uzimamo stroži, većinski broj.

Brojke su prebrojani zapisi iz javnog DNS-a, ne procjena. Cijelo mjerenje s metodologijom i CSV datotekom pod licencijom CC BY 4.0 stoji na stranici stanje email sigurnosti u Hrvatskoj 2026.

Uz široki sken ide i uži, dubinski presjek: 555 domena koje primaju poštu i kod kojih smo gledali politiku, SPF i DKIM. Nazivnici se razlikuju, pa se postotak iz jednog skupa ne smije čitati s brojem drugoga.

DMARC politika (n = 555)	Broj	Udio
p=reject — stvarno blokira	67	12,1 %
p=quarantine — šalje u neželjenu poštu	109	19,6 %
p=none — samo prijavljuje	202	36,4 %
nema DMARC zapisa	177	31,9 %

Zbroj zadnja dva retka je brojka koju vrijedi zapamtiti: 68,3 % domena koje primaju poštu nema DMARC koji išta blokira.

SPF stoji bolje — ima ga 503 od 555 domena (90,6 %). Ali od tih 503 njih 242 (48,1 %) završava mekim ~all, a 251 (49,9 %) strogim -all.

DKIM ima 377 domena (67,9 %), što znači da gotovo trećina nema jedinu nogu autentikacije koja preživi prosljeđivanje.

Kako to čitati bez dramatiziranja: brojke ne kažu da tim tvrtkama pošta pada. Kažu da im se u ime domene može slati i da o tome nemaju nikakav izvještaj. Prvo je rizik, drugo je sljepoća.

Gdje ste Vi u toj slici, vidi se u pola minute: provjerite svoju domenu, bez registracije, a način ocjenjivanja opisan je u metodologiji.

Savjeti koji kruže po forumima uglavnom liječe simptom, a dio njih aktivno šteti. Evo onih koje čujemo najčešće, i što o njima kažu sami primatelji.

Mit: „Izbjegavajte riječi poput GRATIS i AKCIJA.“ Javno objavljenog popisa zabranjenih riječi nema. Ono što Google navodi kao problem sadržaja je obmana — zavaravajuća zaglavlja, lažni Re: i Fwd: naslovi, emoji u prikazanom imenu, sadržaj skriven CSS-om.

Mit: „Neka nas primatelj doda u sigurne pošiljatelje.“ Microsoft izrijekom navodi da popis sigurnih pošiljatelja neće biti uvažen kad poruka ne prolazi tražene provjere. Kod Gmaila to pomaže za taj jedan sandučić, ali uzrok ostaje za sve ostale.

Mit: „Kupit ćemo bazu adresa i poslati više.“ Google izrijekom savjetuje da se adrese ne kupuju od drugih tvrtki i da se ne šalje onima koji se nisu prijavili. Veći volumen na hladnu listu ne popravlja reputaciju nego je najbrže ruši.

Mit: „Uzet ćemo novu domenu i krenuti ispočetka.“ Nova domena nema povijest, što nije prednost — Google preporučuje postupno povećavanje količine upravo zato što se povjerenje gradi kroz vrijeme. Uvjeti su ionako identični na novoj domeni.

Mit: „Stavimo odmah p=reject i gotovo.“ Bez popisa legitimnih pošiljatelja to odbacuje i vlastitu poštu. Hrvatske preporuke govore o tri do dvanaest mjeseci čitanja izvještaja prije stezanja politike.

Mit: „Imamo antispam filter, pokriveni smo.“ Filtar štiti ono što Vama dolazi. Na to kako Vaše poruke izgledaju tuđem poslužitelju ne utječe nimalo — to su dva odvojena problema koja se rješavaju odvojeno.

Mit: „To će riješiti hosting.“ Ponekad hoće, ali autentikacija je vezana uz Vašu domenu, ne uz pružatelja. Microsoft to formulira jasno: i kad slanje prepustite trećoj strani, zapisi moraju stajati u Vašem DNS-u.

To je par zaglavlja koja primateljev sustav izvrši sam, bez ijednog dodatnog koraka za korisnika — pa poveznica koja vodi na stranicu s gumbom „Potvrdi odjavu“ taj uvjet ne ispunjava.

RFC 8058 traži dvoje. Zaglavlje List-Unsubscribe mora sadržavati jednu HTTPS adresu, a zaglavlje List-Unsubscribe-Post točno jedan par vrijednosti: List-Unsubscribe=One-Click.

Primatelj odjavu tada izvodi kao HTTPS POST zahtjev, bez daljnje interakcije korisnika — bez stranice za potvrdu i bez prijave u račun.

Treći uvjet se najčešće previdi: oba zaglavlja moraju biti pokrivena DKIM potpisom. Ako nisu, primatelj nema razloga vjerovati da ih je ondje stavio pošiljatelj.

Uz zaglavlja i dalje mora postojati vidljiva poveznica za odjavu u tijelu poruke. Zaglavlje je za primateljev sustav, poveznica je za čovjeka — Gmail traži oboje.

Yahoo dodaje rok: odjava mora biti izvršena u roku od dva dana. Nije dovoljno da je zaprimljena i stavljena u red čekanja.

Najčešća hrvatska greška izgleda ispravno na prvi pogled. Poveznica „Odjavi se“ vodi na stranicu s potvrdom ili s prijavom u račun — to nije odjava u jednom kliku, iako se u sučelju alata tako zove.

Obveza je vezana uz prag: Gmail je traži iznad 5.000 poruka dnevno prema privatnim računima, Yahoo od masovnih pošiljatelja. Ispod praga nije obvezna — ali prijava spama je za ugled domene skuplja od odjave.

U uzorku od 38 hrvatskih stranica koji smo pregledali o tome piše jedna.

Prema fizičkim osobama treba prethodna privola; prema pravnim osobama po ZEK-u ne treba — ali obveza točnog identiteta pošiljatelja i mogućnosti odjave vrijedi u oba slučaja. Podlogu daje čl. 50. Zakona o elektroničkim komunikacijama (NN 76/2022).

Stavak 1. dopušta izravnu promidžbu elektroničkom poštom, SMS-om i MMS-om „samo uz prethodno pribavljenu privolu krajnjeg korisnika“. To je pravilo, ne preporuka.

Stavak 2. nosi iznimku poznatiju kao meki pristanak. Trgovac smije koristiti adrese koje je dobio od svojih kupaca, ali samo za vlastite slične proizvode ili usluge, i uz jasnu mogućnost besplatnog prigovora — i pri prikupljanju i u svakoj poruci.

Stavak 3. zabranjuje poruke u kojima se pogrešno prikazuje ili prikriva identitet pošiljatelja u čije se ime šalje pošta, kao i poruke bez ispravne adrese na koju se može poslati zahtjev za prestanak komunikacije.

Taj je stavak hrvatska pravna podloga za dvoje o čemu cijeli ovaj tekst govori — za odjavu i za zabranu lažnog predstavljanja. Kako krivotvorenje izgleda u praksi, opisali smo na primjeru BEC prijevare s lažnim računima.

Stavak 4. je najmanje poznat: stavci 1. i 2. ne primjenjuju se na komunikaciju prema pravnim osobama u svrhu izravne promidžbe i prodaje. Prema tvrtkama, dakle, ZEK ne traži prethodnu privolu.

Polovična tvrdnja je ovdje opasna, pa idu obje rečenice zajedno. Iznimka iz stavka 4. ne ukida GDPR — kontakt-osoba u tvrtki i dalje je fizička osoba s osobnim podacima — niti ukida obveze iz stavka 3.

GDPR privolu definira kao dobrovoljan, poseban, informiran i nedvosmislen pristanak (čl. 4. t. 11.), a uvodna izjava 47. dopušta izravni marketing kao mogući legitiman interes. To je osnova po GDPR-u; privolu koju ZEK traži za fizičke osobe ne zamjenjuje.

Zamka pri prepisivanju: AZOP-ova stranica o marketingu poziva se na čl. 107. Zakona o elektroničkim komunikacijama — a to je stari ZEK iz 2008., stavljen izvan snage. Današnja je odredba čl. 50. ZEK-a iz 2022.

Tko danas u pravilima privatnosti citira čl. 107., citira propis koji više ne vrijedi. Hrvatski tehnički okvir za samu zaštitu pošte pokriva pregled preporuka Zavoda za sigurnost informacijskih sustava.

Ovo je opis odredbe s poveznicom na izvorni tekst, a ne pravni savjet — za konkretan slučaj odgovor daje pravnik. U uzorku od 38 hrvatskih stranica koji smo pregledali ZEK ne spominje nijedna.

Redoslijedom: prvo popis svih koji šalju u Vaše ime, pa SPF i DKIM za svakoga, pa DMARC na p=none s izvještajima, pa postupno stezanje politike, i tek onda higijena liste i nadzor. Preskakanje koraka je razlog zbog kojeg većina pokušaja stane na pola.

1. Popis pošiljatelja. Sandučići, webshop, CRM, alat za novosti, sustav za račune, obrasci, praćenje pošiljaka. Ako se nešto šalje s Vaše adrese, mora biti na popisu.
2. SPF koji stane u deset upita. Jedan zapis po domeni, bez naslijeđenih include unosa za servise koje više ne koristite.
3. DKIM za svaki izvor. Zaseban selektor po sustavu — tako se reputacija i problemi izoliraju umjesto da se miješaju.
4. DMARC p=none s adresom za izvještaje. Od tog trenutka prvi put vidite tko sve šalje u Vaše ime.
5. Čitanje izvještaja i ispravci. Ovdje se otkriva ono što nitko nije znao — i ovdje se troši najviše vremena.
6. Stezanje na quarantine pa reject. Tek kad su svi legitimni izvori poravnati. Ne prije.
7. Higijena i nadzor. Odjava u jednom kliku ondje gdje se šalju novosti, uklanjanje adresa koje se odbijaju, praćenje stope prijava i upozorenje kad se pojavi nov izvor.

Infrastruktura je poseban korak. Ako pošta i dalje živi na hosting paketu s dijeljenom IP adresom, dio ovoga nećete moći dokazati ni popraviti — što točno mijenja prelazak na Microsoft 365 ili Google Workspace, razložili smo u zasebnoj usporedbi.

Kad je sve postavljeno, ostaje nadzor: zapisi se s vremenom mijenjaju, alati se dodaju, a jedini način da to primijetite prije klijenta je da netko čita izvještaje.

Petnaest provjera koje imaju odgovor da ili ne — bez mišljenja i bez procjene. Ako sve prolazi, uzrok pada gotovo sigurno nije autentikacija nego ugled ili lista.

Autentikacija

1. Domena ima točno jedan v=spf1 TXT zapis — dva daju permerror i ruše cijeli SPF.
2. SPF troši manje od deset DNS upita, uključujući ugniježđene include unose.
3. SPF završava s -all, ili je svjesno ostavljen na ~all uz postavljen DKIM.
4. DKIM potpisuje Vaša domena (header.d je Vaša domena), i to zasebno za svaki vanjski servis.
5. DMARC zapis postoji na _dmarc.vasadomena.hr i sadrži adresu za izvještaje (rua).

Poravnanje i pošiljatelji

6. Popisani su svi sustavi koji šalju u ime domene: ERP, webshop, obrasci, CRM, novosti, rezervacije.
7. Svaki vanjski servis šalje s Vaše domene ili poddomene, s povratnom adresom na Vašoj poddomeni — ne s vlastite.
8. Web-obrasci šalju s From: adrese Vaše domene, a adresa posjetitelja stoji u Reply-To:.

Infrastruktura

9. Izlazni IP ima valjan PTR koji se razrješava natrag na isto ime (FCrDNS) — ili znate da je hosterov i to prihvaćate.
10. Slanje ide preko TLS-a.
11. Poruka ima ispravan Message-ID, Date i From po RFC-u 5322; provjerava se tako da si pošaljete poruku i otvorite izvornik.

Lista i pristanak

12. Za fizičke osobe postoji privola (ZEK čl. 50. st. 1.), ili je riječ o vlastitim kupcima i vlastitim sličnim proizvodima uz mogućnost prigovora u svakoj poruci (st. 2.).
13. Promidžbena poruka ima List-Unsubscribe i List-Unsubscribe-Post, odjavu bez potvrde i izvršenje u roku od dva dana.

Mjerenje

14. Otvorili ste izvornik poruke na Gmailu i na Outlook.com i pročitali redak Authentication-Results.
15. Postavljen je Google Postmaster Tools — uz svijest da se pri malom volumenu podaci možda uopće neće prikazati.

Prvih pet stavki i dio infrastrukturnih naša provjera prolazi umjesto Vas: provjerite domenu u 30 sekundi. Ostatak je posao koji netko mora obaviti u sustavima iz kojih se šalje.

Mi radimo snimku stanja, popis pošiljatelja, zapise i vođeno stezanje politike; na Vama ostaje odluka koji se alati smiju koristiti i tko ih smije uvoditi. Ta granica nije formalnost — najviše problema nastaje kad netko u tvrtki spoji nov alat na domenu bez znanja onoga tko vodi DNS.

Otvorite provjeru domene, pročitajte nalaz i krenite od prve stavke koja pada — to je cijeli prvi korak. Ako iz teksta pamtite jedno: poruka ne pada zbog riječi u naslovu nego zato što primatelj ne može potvrditi da je Vaša.

To je popravljivo, i popravlja se u DNS-u — ne u naslovu poruke i ne u omjeru teksta i slika.

Poredak je uvijek isti: prvo popis pošiljatelja, pa SPF i DKIM za svakoga, pa DMARC na p=none s izvještajima, i tek onda stezanje politike. Preskakanje koraka košta izgubljenom legitimnom poštom.

Prije iduće kampanje prođite petnaest stavki iz ček-liste, a ako šaljete novosti fizičkim osobama, provjerite i pravni dio — čl. 50. ZEK-a traži privolu, a ne samo urednu odjavu.

Prvi korak je besplatan i traje manje od minute: provjerite svoju domenu, bez registracije — nalaz pokazuje što nedostaje i što napraviti prije nego se politika pooštri.

Ako to želite predati nekome tko je to već radio: e-mail sigurnost je usluga, ostale usluge stoje uz nju, a razgovor počinje jednim nalazom.

Zatražite nalaz i plan za svoju domenu →