Prestaňte hádať pri DNS: vývojársky sprievodca záznamami MX, SPF, DKIM a DMARC

Prečo dnes záleží na DNS záznamoch pre e-mail

Autentifikácia e-mailov bola kedysi voliteľná. V roku 2026 je to základná podmienka. Gmail aj Outlook vynucujú SPF a DKIM pre hromadných odosielateľov a DMARC sa rýchlo stáva povinným pre každú doménu, ktorá odosiela transakčné e-maily. Ak sú vaše DNS záznamy nesprávne, vaše e-maily neprídu — žiadny bounce, žiadne upozornenie, iba ticho.

Problém je v tom, že tieto záznamy sú zdokumentované ako RFC, nie ako nástroje. Väčšina vývojárov skopíruje príklady z inštalačnej príručky svojho poskytovateľa e-mailu a dúfa, že to bude stačiť. Funguje to, kým nepotrebujete riešiť problém, pridať druhú odosielaciu službu alebo vysvetliť klientovi, prečo e-maily z jeho kontaktného formulára končia v spame.

Táto príručka prechádza záznamy MX, SPF, DKIM a DMARC v poradí, v akom sa s nimi v praxi stretnete, s dostatkom detailov na ich správnu konfiguráciu a s dostatkom kontextu na ladenie, keď sa pokazia.

MX záznamy: kam smeruje prichádzajúca pošta

MX záznamy hovoria internetu, ktoré poštové servery prijímajú e-mail pre vašu doménu. Sú najjednoduchšie zo všetkých štyroch, no zároveň sa najľahšie zle nakonfigurujú.

MX záznam má dve časti: číslo priority a názov hostiteľa. Nižšie čísla priority sa skúšajú ako prvé. Ak používate Google Workspace, vaše MX záznamy môžu vyzerať takto:

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.

Koncové bodky sú dôležité — signalizujú, že názov hostiteľa je plne kvalifikovaný. Väčšina poskytovateľov DNS ich pridáva automaticky, ale nie všetci.

Bežné chyby: smerovanie MX záznamov na A záznam namiesto názvu hostiteľa, nastavenie všetkých priorít na rovnaké číslo (čím sa stráca zmysel záloh) alebo zabudnutie odstrániť staré MX záznamy pri migrácii poskytovateľov. Zastarané MX záznamy tam nesedia neškodne — môžu spôsobiť poštové slučky alebo rozdelené doručovanie medzi dve schránky.

Ak prevádzkujete vlastný kontaktný formulár a chcete sa vyhnúť spamu bez spoliehania sa na služby tretích strán, pochopenie toho, ako sa formuláre stávajú vektormi spamu, je užitočný východiskový bod.

SPF: ktoré servery môžu odosielať ako vy

SPF (Sender Policy Framework) je TXT záznam, ktorý uvádza IP adresy a domény oprávnené odosielať e-maily v mene vašej domény. Je to prvá kontrola, ktorú väčšina poštových serverov vykoná, keď dostane správu tvrdiacu, že je od vás.

Základný SPF záznam vyzerá takto:

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

Rozklad:

• v=spf1 deklaruje verziu SPF
• include:_spf.google.com deleguje na SPF záznam Google
• ~all je mäkké zlyhanie — odmietnuť poštu z neuvedených zdrojov, ale nebyť príliš prísny

Môžete použiť aj ip4: alebo ip6: na povolenie konkrétnych adries, prípadne a a mx na odkazovanie na A a MX záznamy vašej domény. Mechanizmus all na konci určuje, čo sa stane s poštou zo zdrojov, ktoré ste neuviedli: -all je tvrdé zlyhanie (odmietnuť), ~all je mäkké zlyhanie (označiť ako podozrivé), ?all je neutrálne (bez stanoviska) a +all je voľný priechod pre všetkých (nepoužívajte to).

SPF má dve ostré hrany. Po prvé, pokazí sa pri preposielaní e-mailu, pretože preposielajúci server nie je vo vašom SPF zázname. Po druhé, SPF záznamy majú limit desiatich DNS dotazov. Ak zahrniete príliš veľa služieb tretích strán, prekročíte limit a SPF prestane fungovať. Riešením je sploštiť SPF záznam — nahradiť direktívy include: skutočnými rozsahmi IP adries — ale vyžaduje si to údržbu, keď poskytovatelia menia svoje IP adresy.

DKIM: kryptografický dôkaz identity odosielateľa

DKIM (DomainKeys Identified Mail) pridáva k vašim odchádzajúcim e-mailom digitálny podpis. Prijímajúci server skontroluje podpis voči verejnému kľúču publikovanému vo vašom DNS. Ak je podpis platný a správa nebola pozmenená, DKIM prejde.

Na rozdiel od SPF DKIM prežije preposielanie, pretože podpis cestuje spolu so správou. Je tiež flexibilnejší — môžete mať viac DKIM kľúčov pre rôzne odosielacie služby, každý s vlastným selektorom.

DNS záznam DKIM vyzerá takto:

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

Selektor (default v tomto príklade) je ľubovoľný — vyberá ho váš poskytovateľ e-mailu. Hodnota p= je verejný kľúč, zvyčajne dlhý reťazec kódovaný v base64. Váš poskytovateľ e-mailu vygeneruje súkromný kľúč a používa ho na podpisovanie odchádzajúcich správ.

Nastavenie DKIM takmer vždy rieši váš poskytovateľ e-mailu. Vašou úlohou je skopírovať TXT záznam, ktorý vám dá, a vložiť ho do DNS. Záludné je, že niektorí poskytovatelia DNS nezvládajú dlhé TXT záznamy dobre — buď ich skrátia, alebo vyžadujú rozdelenie hodnoty do viacerých reťazcov v úvodzovkách.

Ak chcete overiť, že DKIM funguje, pošlite testovací e-mail na adresu Gmail a skontrolujte hlavičky. V hlavičke Authentication-Results hľadajte dkim=pass.

DMARC: vynucovanie politiky a reportovanie

DMARC (Domain-based Message Authentication, Reporting and Conformance) spája SPF a DKIM a hovorí prijímajúcim serverom, čo majú robiť, keď autentifikácia zlyhá. Zároveň zapína reportovanie, takže vidíte, kto odosiela e-maily ako vaša doména — legitímne aj spoofované.

Minimálny DMARC záznam vyzerá takto:

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

• p=none znamená iba monitorovať — neodmietať ani nedávať do karantény neúspešné správy
• rua=mailto:[email protected] určuje, kam posielať agregované reporty

Keď ste si istí, že SPF a DKIM fungujú, môžete politiku sprísniť na p=quarantine (posielať zlyhania do spamu) alebo p=reject (rovno ich odmietnuť). Môžete nastaviť aj politiku pre subdomény pomocou sp= a určiť percento správ, na ktoré sa má politika aplikovať, pomocou pct=.

DMARC reporty sú XML súbory, ktoré veľkí prijímatelia posielajú denne. V surovej podobe sú rozvláčne a ťažko čitateľné, ale presne vám povedia, ktoré správy autentifikáciou prešli alebo neprešli a prečo. Ak sa vám odmieta legitímna pošta, reporty ukážu, ktorá kontrola SPF alebo DKIM zlyháva.

Jedna záludnosť: DMARC vyžaduje zarovnanie. Pri SPF sa doména v hlavičke Return-Path musí zhodovať s doménou v hlavičke From (alebo byť jej subdoménou). Pri DKIM sa doména d= v podpise DKIM musí zhodovať s doménou From. Ak používate odosielaciu službu tretej strany, musí podporovať vlastné návratové cesty alebo podpisovanie DKIM vašou doménou, nie svojou.

Ako auditovať aktuálne nastavenie

Väčšina DNS problémov je neviditeľná, kým nespôsobí problém. Tu je postup, ako skontrolovať záznamy skôr, než sa niečo pokazí:

1. Dotazujte svoje MX záznamy: dig MX example.com by mal vrátiť názvy hostiteľov vašich poštových serverov a priority. Overte, že zodpovedajú dokumentácii vášho poskytovateľa e-mailu.

1. Skontrolujte syntax SPF: dig TXT example.com a vyhľadajte záznam v=spf1. Prežeňte ho SPF validátorom, aby ste zachytili syntaktické chyby a porušenia limitu dotazov.

1. Overte DKIM kľúče: Pošlite testovací e-mail a preskúmajte hlavičku DKIM-Signature. Vyberte selektor a doménu, potom spustite dotaz dig TXT selector._domainkey.example.com, aby ste potvrdili, že verejný kľúč existuje.

1. Validujte politiku DMARC: dig TXT _dmarc.example.com by mal vrátiť váš DMARC záznam. Uistite sa, že rua= smeruje na adresu, ktorú skutočne monitorujete.

1. Otestujte celý tok: Použite službu ako mail-tester.com alebo pošlite správu na adresu Gmail a skontrolujte úplné hlavičky. V hlavičke Authentication-Results hľadajte spf=pass, dkim=pass a dmarc=pass.

Ak ladíte, prečo e-maily neprichádzajú, hlavičky sú váš najlepší nástroj. Väčšina e-mailových klientov umožňuje zobraziť surové hlavičky — v Gmail otvorte správu, kliknite na tri bodky a vyberte „Zobraziť originál“. Hlavička Authentication-Results vám presne povie, ktorá kontrola zlyhala a prečo.

Kedy používať politiky pre subdomény

Ak odosielate e-maily z viacerých subdomén — napríklad newsletter.example.com pre marketing a app.example.com pre transakčnú poštu — môžete nastaviť DMARC politiky pre jednotlivé subdomény. Umožní vám to vynucovať prísne politiky na subdoménach, ktoré kontrolujete, a zároveň ponechať voľnejšiu politiku na hlavnej doméne.

Kompromisom je zložitosť. Každá subdoména potrebuje vlastné záznamy SPF, DKIM a DMARC a musíte sledovať, ktoré odosielacie služby sú oprávnené pre ktoré subdomény. Pre väčšinu malých tímov je jedna dobre nakonfigurovaná doména jednoduchšia a rovnako bezpečná.

Čo robiť, keď sa autentifikácia pokazí

Najbežnejší režim zlyhania je pridanie novej odosielacej služby bez aktualizácie DNS. Ak začnete používať nového poskytovateľa transakčných e-mailov, musíte pridať jeho SPF include alebo rozsah IP adries, nakonfigurovať podpisovanie DKIM vašou doménou a overiť zarovnanie DMARC.

Druhým najčastejším problémom je preposielanie. Ak používatelia prepošlú váš e-mail na inú adresu, SPF zlyhá, pretože preposielajúci server nie je vo vašom SPF zázname. DKIM zvyčajne preposielanie prežije, takže pokiaľ DKIM prejde a vaša politika DMARC umožňuje čiastočné zarovnanie, správa by mala byť doručená. Ak vidíte, že preposlaná pošta sa odmieta, skontrolujte svoju politiku DMARC — p=reject s prísnym zarovnaním preposielanie pokazí.

Tretím problémom je propagácia DNS. Zmeny DNS záznamov sa môžu šíriť celé hodiny a rôzne poštové servery ukladajú záznamy do cache na rôzne dlhý čas. Ak ste práve aktualizovali záznam a nefunguje, počkajte niekoľko hodín a otestujte ho znova. Propagáciu môžete skontrolovať nástrojom ako whatsmydns.net.

Kľúčové zistenia

• MX záznamy smerujú prichádzajúcu poštu; SPF, DKIM a DMARC autentifikujú odchádzajúcu poštu. Riešia rôzne problémy a potrebujete všetky štyri.
• SPF sa pokazí pri preposielaní a má limit desiatich dotazov. DKIM prežije preposielanie, ale vyžaduje konfiguráciu pre každú službu. DMARC ich spája a umožňuje reportovanie.
• Začnite s p=none v DMARC, niekoľko týždňov monitorujte reporty a potom sprísnite na p=quarantine alebo p=reject, keď si budete istí, že legitímna pošta prechádza.
• Chyby DNS sú tiché. Otestujte svoju konfiguráciu reálnym e-mailom a preskúmajte hlavičky, aby ste potvrdili, že SPF, DKIM a DMARC prechádzajú.
• Ak sa autentifikácia pokazí po pridaní novej odosielacej služby, skontrolujte SPF include, DKIM selektory a zarovnanie DMARC. Hlavičky vám povedia, ktorá kontrola zlyhala.

FAQ

Q: Môžem mať viacero SPF záznamov?

A: Nie. Viacero SPF záznamov spôsobí, že sa budú ignorovať všetky. Ak potrebujete autorizovať viacero služieb, použite direktívy include: v rámci jedného SPF záznamu alebo uveďte rozsahy IP adries priamo. Sledujte limit desiatich dotazov.

Q: Potrebujem DMARC, ak odosielam iba pár e-mailov denne?

A: Áno. DMARC nie je o objeme — je o dokazovaní, že ste tým, za koho sa vydávate. Aj malé domény ťažia z DMARC, pretože zabraňuje spoofingu a dáva vám prehľad o problémoch s doručovaním. Začnite s p=none a reportovacou adresou.

Q: Čo sa stane, ak DKIM aj SPF zlyhajú, ale e-mail vyzerá legitímne?

A: Závisí to od vašej politiky DMARC. Ak je p=none, pošta sa doručí s upozornením. Ak je p=quarantine, skončí v spame. Ak je p=reject, bude odmietnutá. Preto by ste mali monitorovať DMARC reporty pred vynútením prísnej politiky — môžete mať legitímnych odosielateľov, o ktorých ste nevedeli.

Q: Môžem použiť rovnaký DKIM kľúč pre viacero domén?

A: Technicky áno, ale nerobte to. Každá doména by mala mať vlastný pár DKIM kľúčov. Zdieľanie kľúčov sťažuje rotáciu a zväčšuje dosah škôd, ak je súkromný kľúč kompromitovaný.

Q: Ako často by som mal rotovať DKIM kľúče?

A: Neexistuje univerzálne pravidlo, ale raz ročne je pre väčšinu domén rozumné. Ak máte podozrenie, že kľúč bol kompromitovaný, rotujte ho okamžite. Uistite sa, že nový verejný kľúč publikujete v DNS skôr, než začnete podpisovať novým súkromným kľúčom, a starý kľúč ponechajte v DNS ešte niekoľko dní po rotácii, aby ste pokryli oneskorenú poštu.

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

💡 Vyskúšajte toto: Preskúmajte zverejnenú politiku ľubovoľnej domény pomocou DMARC Lookup, aby ste videli, ako záznamy MX, SPF a DMARC v praxi spolu súvisia.

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

Zdroje

• RFC 7208: Sender Policy Framework (SPF) — Špecifikácia SPF vrátane pravidiel syntaxe a limitu desiatich dotazov.
• RFC 6376: DomainKeys Identified Mail (DKIM) — Špecifikácia DKIM pokrývajúca generovanie a overovanie podpisov.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Špecifikácia DMARC vrátane syntaxe politiky a formátu agregovaných reportov.
• Google Workspace: Prevent spoofing and spam — Praktické odporúčania ku konfigurácii SPF, DKIM a DMARC pre domény Google Workspace.