Zašto DMARC odbija vaše poruke i kako to popraviti

Kad DMARC izvještaj pokaže failure, to obično znači da poštanski poslužitelj primatelja ne može potvrditi da poruka doista dolazi s vaše domene – čak i ako je legitimna. Za tvrtke koje šalju ciljani cold email B2B poslovnim kontaktima to je ozbiljan problem jer poruke počinju padati u spam ili se odbijaju bez upozorenja. Ovaj vodič objašnjava dmarc failure meaning u praksi, pokazuje kako pročitati izvještaje pomoću alata poput dmarcian tool i daje konkretne korake za popravak prije sljedeće kampanje.

Što zapravo znači DMARC failure

DMARC (Domain-based Message Authentication, Reporting and Conformance) provjerava dvije stvari: je li poruka prošla SPF i je li domena u tim provjerama poravnata (aligned) s domenom u vidljivom From polju. Kad se to poklopi, poruka prolazi DMARC. Kad ne, prima primatelj bilježi dmarc failure i primjenjuje politiku koju ste postavili u DNS zapisu – ništa ne radi (none), stavlja u karantenu (quarantine) ili odbija poruku (reject).

Ključna zabuna: DMARC failure ne znači nužno da je SPF ili DKIM potpuno pokvaren. Poruka može uredno proći SPF provjeru domene poslužitelja koji šalje, ali DMARC svejedno padne jer ta domena nije ista kao domena u From polju. To se u B2B cold email infrastrukturi događa vrlo često – kad se poruke šalju kroz CRM, plaćeni SMTP relay ili alat za automatizaciju koji koristi vlastitu povratnu (envelope-from) domenu.

Za tvrtke koje grade sender reputation postupno, kroz male dnevne volumene personaliziranih poruka konkretnim kontaktima, DMARC failure je posebno bolan jer se šteta ne vidi odmah – Gmail i Outlook tiho snižavaju reputaciju domene prije nego što se pojavi vidljiv pad u open rateu.

Tri najčešća uzroka DMARC failurea

U praksi se gotovo svaki dmarc failure svodi na jedan od sljedeća tri razloga. Prepoznavanje pravog uzroka skraćuje popravak s tjedana na sate.

• SPF misalignment – envelope-from domena (koju vidi poštanski poslužitelj primatelja tijekom SMTP transakcije) razlikuje se od domene u From polju, npr. poruka izgleda kao da dolazi s tvrtka.hr, ali stvarni pošiljatelj je relay.espprovider.com.
• DKIM misalignment ili slomljen potpis – DKIM d= tag ne odgovara domeni u From polju, ili je potpis pokvaren jer je neki posrednik (mailing lista, forward, gateway) izmijenio zaglavlje ili tijelo poruke nakon potpisivanja.
• Nedostajući ili zastarjeli DNS zapisi – DKIM selector nikad nije objavljen u DNS-u, ili je ključ rotiran u alatu za slanje, ali stari TXT zapis nije obrisan pa provjera pada na neispravnom paru ključeva.
• SPF zapis premašuje limit od 10 DNS lookupa – česta posljedica nagomilanih include: direktiva (ESP, CRM, verifikacijski alat, marketing platforma) što uzrokuje permerror i automatski failure bez obzira na sadržaj poruke.

Kako dijagnosticirati uzrok pomoću DMARC izvještaja

DMARC DNS zapis definira i adresu na koju primatelji šalju agregatne izvještaje (rua) – svakodnevni XML sažetak tko je slao u vaše ime i je li prošao provjeru. Ti su XML-ovi nečitljivi golim okom, pa se u praksi koristi alat poput dmarcian koji ih automatski parsira i prikaže po izvornom IP-u, domeni pošiljatelja i rezultatu SPF/DKIM alignmenta. Besplatna razina dmarcian toola dovoljna je za jednu do dvije domene manjeg B2B pošiljatelja i pokriva osnovnu dijagnostiku bez ručnog čitanja XML-a.

Kad izvještaj otvorite, tražite retke gdje je disposition različit od none za izvor koji prepoznajete kao svoj – to je znak da legitimna infrastruktura pada na alignmentu, a ne da je netko zloupotrebljava domenu. Retci s nepoznatim IP adresama i visokim volumenom obično znače spoofing pokušaj, što je zapravo razlog zašto DMARC uopće postoji.

Koliko brzo se DMARC stanje popravlja

Nakon što ispravite SPF include liste i poravnate DKIM domenu, DMARC pass rate se ne popravlja preko noći. DNS promjene se propagiraju, a poštanski poslužitelji (Gmail, Microsoft) trebaju vremena da ažuriraju internu reputaciju domene na temelju novih, urednih izvještaja.

Realan tempo oporavka za manju do srednju cold email infrastrukturu izgleda otprilike ovako, računajući od trenutka kad su DNS zapisi ispravno objavljeni.

Greške koje produljuju popravak

Najskuplja greška je preskakanje faze promatranja – prelazak izravno na p=reject prije nego što se kroz p=none potvrdi da svi legitimni izvori (CRM, transakcijski mailovi, fakture, cold email alat) prolaze alignment. To zna blokirati čak i regularnu poslovnu korespondenciju.

Druga česta greška je pokušaj rješavanja DMARC failurea samo dodavanjem još jednog SPF include zapisa, umjesto konsolidacije postojećih – to lako gurne domenu preko limita od 10 lookupa i failure postane trajan, bez obzira na to koliko je DKIM ispravan.

• Ne testirajte novu politiku samo na jednoj kampanji – pratite izvještaje minimalno dva do tri tjedna prije prelaska na sljedeću razinu politike.
• Nemojte koristiti glavnu domenu tvrtke (npr. onu s koje idu fakture i ugovori) za testiranje novih cold email alata dok DMARC alignment nije potvrđen.
• Provjerite je li DKIM selector koji alat trenutno koristi doista objavljen u DNS-u, ne samo onaj koji je bio aktivan prije migracije.
• Ne postavljajte sp= (subdomain policy) strože od glavne politike prije nego provjerite alignment i za poddomene koje se koriste za cold email.

Kako LDM drži DMARC pod kontrolom prije lansiranja kampanje

Za ciljani B2B cold email LDM prije svakog lansiranja provjerava alignment SPF i DKIM domene sa stvarnom domenom pošiljatelja te po potrebi izdvaja slanje na dediciranu poddomenu s vlastitim, čistim DNS zapisima – tako se glavna korporativna domena, na kojoj ovise fakture i ugovori, nikad ne izlaže riziku dok se reputacija nove poddomene tek gradi.

Politika ide postupno (none → quarantine → reject) uz tjedno praćenje agregatnih izvještaja, a volumen slanja raste sporo, u skladu s dobi domene i dosadašnjom poviješću – isti princip koji drži i open rate i broj odgovora stabilnima, a ne samo DMARC pass rate.

Česta pitanja