Zašto poslovna pošta
završava u spamu

Poslužitelj primatelja mora odlučiti vjeruje li vam

Kad vaša poruka stigne na poslužitelj primatelja, on u djeliću sekunde odlučuje hoće li je isporučiti u pretinac, gurnuti u spam ili odbiti. Na tu odluku utječe više signala. Autentikacija domene jedan je od najvažnijih tehničkih temelja jer primatelju pomaže provjeriti tko smije slati u ime vaše domene. Na isporučivost ipak utječu i reputacija pošiljatelja, DNS postavke, način slanja, prijave korisnika na spam i drugi signali.

Poslati e-mail u tuđe ime tehnički je trivijalno — adresa pošiljatelja je samo tekst koji se upiše. Zato su nastala tri zapisa u DNS-u vaše domene koji tu tvrdnju čine provjerljivom. Ako ih nemate ili su pogrešni, poslužitelj primatelja nema način da vas razlikuje od nekoga tko se lažno predstavlja, pa se osigurava na vaš račun.

SPF

Popis poslužitelja koji smiju slati poštu u ime vaše domene. Primatelj usporedi adresu s koje je poruka stvarno stigla s tim popisom.

DKIM

Kriptografski potpis koji vaš poslužitelj dodaje svakoj poruci. Primatelj ga provjeri javnim ključem objavljenim u vašem DNS-u i tako zna da poruka nije mijenjana putem i da je potpisana vašom domenom.

DMARC

Uputa primatelju što učiniti kad SPF i DKIM ne prođu — ništa, u spam, ili odbiti — i adresa na koju šalje izvještaje o tome tko sve šalje u vaše ime.

Gdje to najčešće pukne

Rijetko je problem u tome da zapisi uopće ne postoje. Češće postoje, ali su tiho neispravni.

Novi alat koji nitko nije dodao u SPF

Uveli ste alat za newsletter, sustav za izdavanje računa ili CRM koji šalje potvrde. Svaki od njih šalje s vlastitih poslužitelja. Ako ih nema u SPF zapisu, njihova pošta pada na provjeri — i to su najčešće upravo poruke koje je najvažnije da stignu.

Dva SPF zapisa

Domena smije imati točno jedan SPF zapis. Kad se doda drugi, umjesto da se popis proširi, provjera postane neispravna i obično padne cijela. To se dogodi kad dvije osobe u razmaku od godinu dana svaka doda svoj zapis.

Prekoračeno ograničenje od deset upita

Specifikacija SPF-a dopušta najviše deset DNS upita pri provjeri jednog zapisa. Svaki include za vanjski servis troši barem jedan. S četiri ili pet uključenih servisa granica se dosegne neprimjetno, a rezultat je trajna pogreška koja se nigdje ne prijavljuje.

DKIM koji nikad nije uključen

Kod mnogih davatelja DKIM treba zasebno uključiti ili barem provjeriti da je ispravno konfiguriran. Treba objaviti ključ u DNS-u i uključiti potpisivanje na strani poslužitelja. Ako je jedno napravljeno, a drugo nije, potpis ne postoji ili ne prolazi.

DMARC postavljen na odbijanje prerano

Obrnuti problem: netko odmah postavi najstrožu politiku, a jedan legitiman servis nije uredno posložen. Njegova pošta prestane stizati, a nitko ne poveže dvije stvari jer nema poruke o pogrešci — poruka jednostavno nestane.

Kojim redom to posložiti

1. Popišite tko sve šalje u vaše ime. Poslužitelj pošte, alat za newsletter, sustav za račune, obrasci sa stranice, servisna obavještenja. Ovaj korak preskoči se najčešće, a bez njega su svi sljedeći nagađanje.
2. Složite jedan SPF zapis koji pokriva sve s popisa i ostaje ispod deset upita. Ako ne stane, postoje načini da se broj upita smanji — ali prvo treba znati da je granica dosegnuta.
3. Uključite DKIM na svakom pošiljatelju, ne samo na glavnom poslužitelju pošte.
4. Objavite DMARC u načinu promatranja i s adresom za izvještaje. U tom stanju ništa se ne odbacuje, ali počinjete dobivati podatke.
5. Čitajte izvještaje nekoliko tjedana. Oni pokažu i pošiljatelje za koje niste znali — vlastite i tuđe.
6. Postupno pooštrite politiku na karantenu pa na odbijanje, tek kad su svi legitimni pošiljatelji uredni.

Stroža DMARC politika može pomoći primateljima da odbiju dio poruka koje neovlašteno koriste vašu domenu. Ne štiti od svih oblika phishinga, primjerice sličnih domena ili lažnog prikaznog imena.

Što možete provjeriti sami, danas

Pošaljite poruku sa svoje poslovne adrese na bilo koji Gmail račun. Otvorite je, u izborniku poruke odaberite prikaz izvornika i pogledajte redove SPF, DKIM i DMARC na vrhu. Uz svaki piše prolazi li provjeru.

Ako sva tri prolaze, osnovna autentikacija je postavljena, ali uzrok problema i dalje može biti u drugim signalima isporučivosti. Ako neki od njih ne prolazi, pronašli ste konkretan tehnički problem koji treba ispraviti.

Kad zapisi nisu uzrok

Rjeđe, ali se događa. Vrijedi provjeriti i sljedeće.

• Reputacija zajedničke adrese. Na dijeljenom hostingu pošta može izlaziti preko IP adrese koju koriste i drugi korisnici. U tom slučaju reputacija te zajedničke izlazne adrese može utjecati i na vašu isporučivost.
• Nova domena. Domena bez povijesti slanja u početku se tretira opreznije. To prolazi samo od sebe ako se šalje uredno.
• Nedostaje obrnuti DNS zapis za poslužitelj koji šalje. Neki primatelji na tome inzistiraju.
• Sadržaj koji izgleda kao masovna pošta: poruka koja je jedna velika slika bez teksta, ili poveznice skraćene kroz servis loše reputacije.
• Pravilo kod primatelja. Ponekad je filter podešen kod klijenta, a ne kod vas. Zato je provjera na neutralnom računu prvi korak.

Zašto se isplati riješiti

Pošta koja ne stiže ne javlja se kao kvar. Nema poruke o pogrešci, nema prijave, nema traga — samo ponuda na koju nitko nije odgovorio i račun koji nitko nije platio jer ga nitko nije vidio. Zato je to problem koji zna trajati mjesecima prije nego ga netko poveže s postavkama domene.

Opseg posla ovisi o broju sustava koji šalju u ime domene i o trenutnom stanju DNS-a, autentikacije i reputacije. Nakon početnog uređenja postavke treba povremeno ponovno provjeriti, posebno kada se uvodi novi servis za slanje pošte.

Izvori i dodatna dokumentacija

• Google — Smjernice za pošiljatelje e-pošte Službeni zahtjevi i preporuke za autentikaciju pošte, DNS, TLS, spam-rate i druge signale koji utječu na dostavu poruka prema Gmailu.
• RFC 7208 — Sender Policy Framework (SPF) Službena specifikacija SPF-a, uključujući način autorizacije poslužitelja koji smiju slati poštu u ime domene.
• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures Službena specifikacija DKIM potpisa i provjere autentičnosti poruka pomoću ključeva objavljenih u DNS-u.
• RFC 9989 — Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aktualna standardna specifikacija DMARC-a za provjeru uporabe domene, politike obrade neautentificirane pošte i izvještavanje.