Prestanite nagađati svoj DNS: razvojnom timu prilagođen vodič kroz MX, SPF, DKIM i DMARC

Zašto su DNS zapisi za e-poštu danas važni

Autentikacija e-pošte nekad je bila opcionalna. U 2026. to je osnovni preduvjet. Gmail i Outlook provode SPF i DKIM za masovne pošiljatelje, a DMARC brzo postaje obavezan za svaku domenu koja šalje transakcijsku e-poštu. Ako su vaši DNS zapisi pogrešni, vaše poruke ne stižu — nema odbijanja, nema upozorenja, samo tišina.

Problem je u tome što su ti zapisi dokumentirani kao RFC-ovi, a ne kao alati. Većina developera kopira primjere iz vodiča za postavljanje svog pružatelja e-pošte i nada se najboljem. To funkcionira dok ne trebate otklanjati poteškoće, dodati drugu uslugu slanja ili objasniti klijentu zašto poruke s njihova kontakt obrasca završavaju u neželjenoj pošti.

Ovaj vodič prolazi kroz MX, SPF, DKIM i DMARC redoslijedom kojim ćete ih stvarno susretati, s dovoljno detalja da ih ispravno konfigurirate i dovoljno konteksta da ih možete debugirati kad se pokvare.

MX zapisi: kamo ide dolazna e-pošta

MX zapisi govore internetu koji poslužitelji pošte prihvaćaju e-poštu za vašu domenu. Najjednostavniji su od ova četiri tipa zapisa, ali ih je ujedno najlakše pogrešno konfigurirati.

MX zapis ima dva dijela: broj prioriteta i naziv hosta. Niži brojevi prioriteta pokušavaju se prvi. Ako koristite Google Workspace, vaši MX zapisi mogli bi izgledati ovako:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Završne točke su važne — označavaju da je naziv hosta potpuno kvalificiran. Većina DNS pružatelja dodaje ih automatski, ali ne svi.

Česte pogreške: usmjeravanje MX zapisa na A zapis umjesto na naziv hosta, postavljanje svih prioriteta na isti broj (što poništava svrhu rezervnih poslužitelja) ili zaboravljanje uklanjanja starih MX zapisa pri migraciji pružatelja. Zastarjeli MX zapisi ne stoje ondje bezopasno — mogu uzrokovati petlje pošte ili podijeliti isporuku između dva sandučića.

Ako pokrećete vlastiti kontakt obrazac i želite izbjeći spam bez oslanjanja na usluge trećih strana, razumijevanje načina na koji obrasci postaju vektori spama korisna je početna točka.

SPF: koji poslužitelji smiju slati u vaše ime

SPF (Sender Policy Framework) je TXT zapis koji navodi IP adrese i domene ovlaštene za slanje e-pošte u ime vaše domene. To je prva provjera koju većina poslužitelja pošte izvodi kad primi poruku koja tvrdi da dolazi od vas.

Osnovni SPF zapis izgleda ovako:

v=spf1 include:_spf.google.com ~all

Raščlamba:

• v=spf1 deklarira verziju SPF-a
• include:_spf.google.com delegira na Googleov SPF zapis
• ~all je blagi neuspjeh — odbijte poštu iz nenavedenih izvora, ali nemojte biti prestrogi

Možete koristiti i ip4: ili ip6: za dodavanje određenih adresa na popis dopuštenih, ili a i mx za referenciranje A i MX zapisa svoje domene. Mehanizam all na kraju kontrolira što se događa s poštom iz izvora koje niste naveli: -all je strogi neuspjeh (odbij), ~all je blagi neuspjeh (označi kao sumnjivo), ?all je neutralno (bez stava), a +all je potpuno otvoreno (nemojte to koristiti).

SPF ima dvije oštre rubne točke. Prvo, puca kad se e-pošta prosljeđuje, jer poslužitelj za prosljeđivanje nije u vašem SPF zapisu. Drugo, SPF zapisi imaju ograničenje od deset DNS upita. Ako uključite previše usluga trećih strana, premašit ćete ograničenje i SPF će prestati raditi. Rješenje je izravnati SPF zapis — zamijeniti direktive include: stvarnim IP rasponima — ali to zahtijeva održavanje kad pružatelji promijene svoje IP adrese.

DKIM: kriptografski dokaz identiteta pošiljatelja

DKIM (DomainKeys Identified Mail) dodaje digitalni potpis vašoj odlaznoj e-pošti. Poslužitelj primatelja provjerava potpis prema javnom ključu objavljenom u vašem DNS-u. Ako je potpis valjan i poruka nije mijenjana, DKIM prolazi.

Za razliku od SPF-a, DKIM preživljava prosljeđivanje, jer potpis putuje s porukom. Također je fleksibilniji — možete imati više DKIM ključeva za različite usluge slanja, svaki sa svojim selektorom.

DKIM DNS zapis izgleda ovako:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Selektor (default u ovom primjeru) proizvoljan je — odabire ga vaš pružatelj e-pošte. Vrijednost p= je javni ključ, obično dugačak base64-kodirani niz. Vaš pružatelj e-pošte generira privatni ključ i koristi ga za potpisivanje odlaznih poruka.

Postavljanje DKIM-a gotovo uvijek obavlja vaš pružatelj e-pošte. Vaš je posao kopirati TXT zapis koji vam daju i zalijepiti ga u svoj DNS. Nezgodan dio je to što neki DNS pružatelji ne obrađuju dobro dugačke TXT zapise — ili ih skraćuju ili zahtijevaju da vrijednost podijelite u više navedenih nizova.

Da biste provjerili radi li DKIM, pošaljite testnu poruku na Gmail adresu i provjerite zaglavlja. Potražite dkim=pass u zaglavlju Authentication-Results.

DMARC: provedba pravila i izvještavanje

DMARC (Domain-based Message Authentication, Reporting and Conformance) povezuje SPF i DKIM i govori poslužiteljima primatelja što učiniti kad autentikacija ne uspije. Omogućuje i izvještavanje, tako da možete vidjeti tko šalje e-poštu kao vaša domena — i legitimne pošiljatelje i lažirane.

Minimalni DMARC zapis izgleda ovako:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none znači samo nadzor — nemojte odbijati ni stavljati u karantenu poruke koje ne prođu provjeru
• rua=mailto:[email protected] određuje kamo slati agregirana izvješća

Kad ste sigurni da SPF i DKIM rade, pravilo možete postrožiti na p=quarantine (slati neuspjele poruke u spam) ili p=reject (odmah ih odbiti). Također možete postaviti pravilo za poddomenu s sp= i odrediti postotak poruka na koje se pravilo primjenjuje s pct=.

DMARC izvješća su XML datoteke koje veliki primatelji šalju svakodnevno. Opširna su i teško ih je čitati u sirovom obliku, ali govore točno koje su poruke prošle ili pale autentikaciju i zašto. Ako vidite da se legitimna pošta odbija, izvješća će pokazati koja SPF ili DKIM provjera ne uspijeva.

Jedna zamka: DMARC zahtijeva poravnanje. Za SPF, domena u zaglavlju Return-Path mora odgovarati domeni u zaglavlju From (ili biti poddomena). Za DKIM, domena d= u DKIM potpisu mora odgovarati domeni From. Ako koristite uslugu slanja treće strane, ona mora podržavati prilagođene povratne putanje ili DKIM potpisivanje vašom domenom, a ne svojom.

Kako napraviti reviziju trenutačne konfiguracije

Većina DNS problema nevidljiva je dok ne uzrokuje problem. Evo kako provjeriti zapise prije nego što nešto pukne:

1. Upitajte svoje MX zapise: dig MX example.com trebao bi vratiti nazive hostova i prioritete vaših poslužitelja pošte. Provjerite odgovaraju li dokumentaciji vašeg pružatelja e-pošte.

1. Provjerite SPF sintaksu: dig TXT example.com i potražite zapis v=spf1. Provucite ga kroz SPF validator kako biste uhvatili sintaksne pogreške i kršenja ograničenja broja upita.

1. Provjerite DKIM ključeve: Pošaljite testnu poruku i pregledajte zaglavlje DKIM-Signature. Izdvojite selektor i domenu, zatim upitajte dig TXT selector._domainkey.example.com kako biste potvrdili da javni ključ postoji.

1. Validirajte DMARC pravilo: dig TXT _dmarc.example.com trebao bi vratiti vaš DMARC zapis. Provjerite pokazuje li rua= na adresu koju doista nadzirete.

1. Testirajte od kraja do kraja: Upotrijebite uslugu poput mail-tester.com ili pošaljite poruku na Gmail adresu i provjerite potpuna zaglavlja. Potražite spf=pass, dkim=pass i dmarc=pass u zaglavlju Authentication-Results.

Ako debugirate zašto poruke ne stižu, zaglavlja su vaš najbolji alat. Većina klijenata e-pošte omogućuje prikaz sirovih zaglavlja — u Gmailu otvorite poruku, kliknite tri točke i odaberite 'Show original'. Zaglavlje Authentication-Results reći će vam točno koja provjera nije uspjela i zašto.

Kada koristiti pravila za poddomene

Ako šaljete e-poštu s više poddomena — recimo, newsletter.example.com za marketing i app.example.com za transakcijsku poštu — možete postaviti DMARC pravila po poddomeni. To vam omogućuje provedbu strogih pravila na poddomenama koje kontrolirate, dok na glavnoj domeni zadržavate blaže pravilo.

Kompromis je složenost. Svaka poddomena treba vlastite SPF, DKIM i DMARC zapise, a vi morate pratiti koje su usluge slanja ovlaštene za koje poddomene. Za većinu malih timova jedna dobro konfigurirana domena jednostavnija je i jednako sigurna.

Što učiniti kad autentikacija pukne

Najčešći način kvara jest dodavanje nove usluge slanja bez ažuriranja DNS-a. Ako počnete koristiti novog pružatelja transakcijske e-pošte, trebate dodati njihov SPF include ili IP raspon, konfigurirati DKIM potpisivanje svojom domenom i provjeriti DMARC poravnanje.

Drugi najčešći problem je prosljeđivanje. Ako korisnici proslijede vašu e-poštu na drugu adresu, SPF neće uspjeti jer poslužitelj za prosljeđivanje nije u vašem SPF zapisu. DKIM obično preživljava prosljeđivanje, pa bi se poruka i dalje trebala isporučiti sve dok DKIM prolazi i vaše DMARC pravilo dopušta djelomično poravnanje. Ako vidite da se proslijeđena pošta odbija, provjerite DMARC pravilo — p=reject sa strogim poravnanjem pokvarit će prosljeđivanje.

Treći problem je propagacija DNS-a. Promjenama DNS zapisa mogu trebati sati da se propagiraju, a različiti poslužitelji pošte predmemoriraju zapise različito dugo. Ako ste upravo ažurirali zapis i ne radi, pričekajte nekoliko sati i ponovno testirajte. Propagaciju možete provjeriti alatom poput whatsmydns.net.

Ključne poruke

• MX zapisi usmjeravaju dolaznu poštu; SPF, DKIM i DMARC autentificiraju odlaznu poštu. Rješavaju različite probleme i trebaju vam sva četiri.
• SPF puca pri prosljeđivanju i ima ograničenje od deset upita. DKIM preživljava prosljeđivanje, ali zahtijeva konfiguraciju po usluzi. DMARC ih povezuje i omogućuje izvještavanje.
• Počnite s p=none u DMARC-u, pratite izvješća nekoliko tjedana, zatim postrožite na p=quarantine ili p=reject kad budete sigurni da legitimna pošta prolazi.
• DNS pogreške su tihe. Testirajte konfiguraciju stvarnom e-poštom i pregledajte zaglavlja kako biste potvrdili da SPF, DKIM i DMARC prolaze.
• Ako autentikacija pukne nakon dodavanja nove usluge slanja, provjerite SPF include direktive, DKIM selektore i DMARC poravnanje. Zaglavlja će vam reći koja provjera nije uspjela.

FAQ

Q: Mogu li imati više SPF zapisa?

A: Ne. Više SPF zapisa uzrokovat će da se svi ignoriraju. Ako trebate ovlastiti više usluga, koristite direktive include: unutar jednog SPF zapisa ili izravno navedite IP raspone. Pazite na ograničenje od deset upita.

Q: Treba li mi DMARC ako šaljem samo nekoliko poruka dnevno?

A: Da. DMARC nije stvar volumena — nego dokazivanja da ste ono za što se predstavljate. Čak i male domene imaju koristi od DMARC-a jer sprječava lažiranje i daje vam uvid u probleme s isporukom. Počnite s p=none i adresom za izvješća.

Q: Što se događa ako DKIM i SPF oboje ne uspiju, ali e-pošta izgleda legitimno?

A: Ovisi o vašem DMARC pravilu. Ako je p=none, pošta se isporučuje s upozorenjem. Ako je p=quarantine, ide u spam. Ako je p=reject, odbija se. Zato biste trebali pratiti DMARC izvješća prije provedbe strogog pravila — možda imate legitimne pošiljatelje za koje niste znali.

Q: Mogu li koristiti isti DKIM ključ za više domena?

A: Tehnički da, ali nemojte. Svaka domena trebala bi imati vlastiti par DKIM ključeva. Dijeljenje ključeva otežava rotaciju i povećava opseg štete ako privatni ključ bude kompromitiran.

Q: Koliko često trebam rotirati DKIM ključeve?

A: Ne postoji univerzalno pravilo, ali jednom godišnje razumno je za većinu domena. Ako sumnjate da je ključ kompromitiran, rotirajte ga odmah. Obavezno objavite novi javni ključ u DNS-u prije nego što počnete potpisivati novim privatnim ključem i ostavite stari ključ u DNS-u nekoliko dana nakon rotacije kako biste obradili zakašnjelu poštu.

<!-- tool-cta:start -->

💡 Isprobajte ovo: Pregledajte objavljenu politiku bilo koje domene pomoću DMARC Lookup kako biste vidjeli kako se MX, SPF i DMARC zapisi uklapaju u praksi.

<!-- tool-cta:end -->

Izvori

• RFC 7208: Sender Policy Framework (SPF) — SPF specifikacija, uključujući pravila sintakse i ograničenje od deset upita.
• RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM specifikacija, koja pokriva generiranje i provjeru potpisa.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — DMARC specifikacija, uključujući sintaksu pravila i format agregiranog izvještavanja.
• Google Workspace: Prevent spoofing and spam — Praktične smjernice za konfiguraciju SPF-a, DKIM-a i DMARC-a za Google Workspace domene.