Přestaňte hádat DNS: vývojářsky přívětivý průvodce MX, SPF, DKIM a DMARC

Proč dnes záleží na DNS záznamech pro e-mail

Ověřování e-mailů bývalo volitelné. V roce 2026 je to základní předpoklad. Gmail i Outlook vynucují SPF a DKIM u hromadných odesílatelů a DMARC se rychle stává povinným pro každou doménu, která odesílá transakční e-maily. Pokud máte DNS záznamy špatně, vaše e-maily nedorazí — žádný bounce, žádné varování, jen ticho.

Problém je v tom, že tyto záznamy jsou dokumentované jako RFC, ne jako nástroje. Většina vývojářů zkopíruje příklady z instalační příručky svého poskytovatele e-mailu a doufá, že to bude stačit. Funguje to do chvíle, než potřebujete řešit problém, přidat druhou službu pro odesílání nebo klientovi vysvětlit, proč e-maily z jeho kontaktního formuláře končí ve spamu.

Tento průvodce prochází MX, SPF, DKIM a DMARC v pořadí, ve kterém se s nimi skutečně setkáte, s dostatkem detailů pro správné nastavení a dostatkem kontextu pro ladění, když se něco rozbije.

MX záznamy: kam chodí příchozí e-mail

MX záznamy říkají internetu, které poštovní servery přijímají e-mail pro vaši doménu. Jsou nejjednodušší ze všech čtyř, ale také se nejsnáze nastaví špatně.

MX záznam má dvě části: číslo priority a název hostitele. Nižší čísla priority se zkoušejí jako první. Pokud používáte Google Workspace, vaše MX záznamy mohou vypadat 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.

Tečky na konci jsou důležité — signalizují, že název hostitele je plně kvalifikovaný. Většina poskytovatelů DNS je přidává automaticky, ale ne všichni.

Časté chyby: směrování MX záznamů na A záznam místo na název hostitele, nastavení všech priorit na stejné číslo (což popírá smysl záložních serverů) nebo zapomenutí odstranit staré MX záznamy při migraci k jinému poskytovateli. Zastaralé MX záznamy tam nesedí neškodně — mohou způsobit poštovní smyčky nebo rozdělené doručování do dvou schránek.

Pokud provozujete vlastní kontaktní formulář a chcete se vyhnout spamu bez spoléhání na služby třetích stran, užitečným výchozím bodem je pochopit, jak se formuláře stávají vektory spamu.

SPF: které servery smějí odesílat jako vy

SPF (Sender Policy Framework) je TXT záznam, který uvádí IP adresy a domény oprávněné odesílat e-mail jménem vaší domény. Je to první kontrola, kterou většina poštovních serverů provádí, když obdrží zprávu tvrdící, že je od vás.

Základní SPF záznam vypadá takto:

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

Rozklad:

• v=spf1 deklaruje verzi SPF
• include:_spf.google.com deleguje na SPF záznam Google
• ~all je soft fail — poštu z neuvedených zdrojů označí jako podezřelou, ale není příliš přísný

Můžete také použít ip4: nebo ip6: pro povolení konkrétních adres, případně a a mx pro odkaz na A a MX záznamy vaší domény. Mechanismus all na konci řídí, co se stane s poštou ze zdrojů, které jste neuvedli: -all je hard fail (odmítnout), ~all je soft fail (označit jako podezřelé), ?all je neutrální (bez názoru) a +all je volný průchod pro všechny (to nepoužívejte).

SPF má dvě ostré hrany. Zaprvé se rozbije při přeposílání e-mailů, protože přeposílající server není ve vašem SPF záznamu. Zadruhé mají SPF záznamy limit deseti DNS dotazů. Pokud zahrnete příliš mnoho služeb třetích stran, limit překročíte a SPF přestane fungovat. Řešením je SPF záznam zploštit — nahradit direktivy include: skutečnými rozsahy IP adres — ale to vyžaduje údržbu, když poskytovatelé mění své IP adresy.

DKIM: kryptografický důkaz identity odesílatele

DKIM (DomainKeys Identified Mail) přidává k vašemu odchozímu e-mailu digitální podpis. Přijímající server ověří podpis proti veřejnému klíči publikovanému ve vašem DNS. Pokud je podpis platný a se zprávou nebylo manipulováno, DKIM projde.

Na rozdíl od SPF přežije DKIM přeposílání, protože podpis cestuje se zprávou. Je také flexibilnější — můžete mít více DKIM klíčů pro různé odesílací služby, každý s vlastním selektorem.

DKIM DNS záznam vypadá takto:

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

Selektor (default v tomto příkladu) je libovolný — vybírá ho váš poskytovatel e-mailu. Hodnota p= je veřejný klíč, obvykle dlouhý řetězec kódovaný v base64. Váš poskytovatel e-mailu vygeneruje soukromý klíč a používá ho k podepisování odchozích zpráv.

Nastavení DKIM téměř vždy zajišťuje váš poskytovatel e-mailu. Vaším úkolem je zkopírovat TXT záznam, který vám dá, a vložit ho do DNS. Záludné je, že někteří poskytovatelé DNS nezvládají dlouhé TXT záznamy dobře — buď je zkrátí, nebo vyžadují rozdělení hodnoty do více řetězců v uvozovkách.

Chcete-li ověřit, že DKIM funguje, pošlete testovací e-mail na adresu Gmail a zkontrolujte hlavičky. V hlavičce Authentication-Results hledejte dkim=pass.

DMARC: vynucování politik a reporting

DMARC (Domain-based Message Authentication, Reporting and Conformance) propojuje SPF a DKIM a říká přijímajícím serverům, co mají dělat, když ověření selže. Zároveň zapíná reporting, takže vidíte, kdo odesílá e-mail jako vaše doména — legitimně i podvrženě.

Minimální DMARC záznam vypadá takto:

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

• p=none znamená pouze monitorování — neodmítat ani nedávat do karantény neúspěšné zprávy
• rua=mailto:[email protected] určuje, kam posílat agregované reporty

Jakmile máte jistotu, že SPF a DKIM fungují, můžete politiku zpřísnit na p=quarantine (posílat selhání do spamu) nebo p=reject (rovnou je vracet). Můžete také nastavit politiku pro subdomény pomocí sp= a pomocí pct= určit procento zpráv, na které se má politika aplikovat.

DMARC reporty jsou XML soubory posílané denně hlavními přijímači. V syrové podobě jsou podrobné a špatně čitelné, ale přesně vám řeknou, které zprávy ověřením prošly nebo neprošly a proč. Pokud vidíte odmítání legitimní pošty, reporty ukážou, která kontrola SPF nebo DKIM selhává.

Jedna záludnost: DMARC vyžaduje alignment, tedy shodu domén. U SPF se doména v hlavičce Return-Path musí shodovat s doménou v hlavičce From (nebo musí být její subdoménou). U DKIM se doména d= v podpisu DKIM musí shodovat s doménou From. Pokud používáte odesílací službu třetí strany, musí podporovat vlastní return paths nebo podepisování DKIM vaší doménou, ne svou.

Jak auditovat aktuální nastavení

Většina DNS problémů je neviditelná, dokud něco nerozbije. Tady je, jak zkontrolovat záznamy dřív, než se něco pokazí:

1. Dotázat se na MX záznamy: dig MX example.com by měl vrátit názvy hostitelů vašich poštovních serverů a jejich priority. Ověřte, že odpovídají dokumentaci vašeho poskytovatele e-mailu.

1. Zkontrolovat syntaxi SPF: dig TXT example.com a najděte záznam v=spf1. Prožeňte ho validátorem SPF, abyste zachytili syntaktické chyby a překročení limitu dotazů.

1. Ověřit DKIM klíče: Pošlete testovací e-mail a zkontrolujte hlavičku DKIM-Signature. Vytáhněte selektor a doménu a potom se dotazem dig TXT selector._domainkey.example.com ujistěte, že veřejný klíč existuje.

1. Validovat politiku DMARC: dig TXT _dmarc.example.com by měl vrátit váš DMARC záznam. Ujistěte se, že rua= směřuje na adresu, kterou skutečně sledujete.

1. Otestovat vše od začátku do konce: Použijte službu jako mail-tester.com nebo pošlete e-mail na adresu Gmail a zkontrolujte celé hlavičky. V hlavičce Authentication-Results hledejte spf=pass, dkim=pass a dmarc=pass.

Pokud ladíte, proč e-maily nedorážejí, hlavičky jsou váš nejlepší nástroj. Většina e-mailových klientů umožňuje zobrazit syrové hlavičky — v Gmail otevřete zprávu, klikněte na tři tečky a vyberte „Show original“. Hlavička Authentication-Results vám přesně řekne, která kontrola selhala a proč.

Kdy používat politiky pro subdomény

Pokud odesíláte e-mail z více subdomén — řekněme newsletter.example.com pro marketing a app.example.com pro transakční poštu — můžete nastavit samostatné DMARC politiky pro jednotlivé subdomény. To vám umožní vynucovat přísné politiky na subdoménách, které kontrolujete, a zároveň držet volnější politiku na hlavní doméně.

Nevýhodou je složitost. Každá subdoména potřebuje vlastní SPF, DKIM a DMARC záznamy a musíte sledovat, které odesílací služby jsou oprávněné pro které subdomény. Pro většinu malých týmů je jedna dobře nastavená doména jednodušší a stejně bezpečná.

Co dělat, když se ověřování rozbije

Nejčastější režim selhání je přidání nové odesílací služby bez aktualizace DNS. Pokud začnete používat nového poskytovatele transakčních e-mailů, musíte přidat jeho SPF include nebo rozsah IP adres, nastavit podepisování DKIM vaší doménou a ověřit alignment DMARC.

Druhým nejčastějším problémem je přeposílání. Pokud uživatelé přeposílají váš e-mail na jinou adresu, SPF selže, protože přeposílající server není ve vašem SPF záznamu. DKIM přeposílání obvykle přežije, takže pokud DKIM projde a vaše politika DMARC umožňuje částečnou shodu, zpráva by měla být stále doručena. Pokud vidíte odmítání přeposílané pošty, zkontrolujte politiku DMARC — p=reject se strict alignment rozbije přeposílání.

Třetím problémem je propagace DNS. Změny DNS záznamů se mohou šířit hodiny a různé poštovní servery cachují záznamy po různě dlouhou dobu. Pokud jste právě aktualizovali záznam a nefunguje, počkejte několik hodin a otestujte to znovu. Propagaci můžete zkontrolovat nástrojem jako whatsmydns.net.

Klíčové poznatky

• MX záznamy směrují příchozí poštu; SPF, DKIM a DMARC ověřují odchozí poštu. Řeší různé problémy a potřebujete všechny čtyři.
• SPF se rozbíjí při přeposílání a má limit deseti dotazů. DKIM přeposílání přežije, ale vyžaduje konfiguraci pro každou službu. DMARC je propojuje a umožňuje reporting.
• Začněte v DMARC s p=none, několik týdnů sledujte reporty a potom zpřísněte na p=quarantine nebo p=reject, jakmile máte jistotu, že legitimní pošta prochází.
• Chyby v DNS jsou tiché. Otestujte konfiguraci skutečným e-mailem a zkontrolujte hlavičky, abyste potvrdili, že SPF, DKIM a DMARC procházejí.
• Pokud se ověřování rozbije po přidání nové odesílací služby, zkontrolujte SPF includes, DKIM selektory a alignment DMARC. Hlavičky vám řeknou, která kontrola selhala.

FAQ

Q: Mohu mít více SPF záznamů?

A: Ne. Více SPF záznamů způsobí, že budou ignorovány všechny. Pokud potřebujete autorizovat více služeb, použijte direktivy include: v rámci jednoho SPF záznamu nebo uveďte rozsahy IP adres přímo. Hlídejte limit deseti dotazů.

Q: Potřebuji DMARC, když posílám jen pár e-mailů denně?

A: Ano. DMARC není o objemu — je o prokázání, že jste tím, za koho se vydáváte. I malé domény z DMARC těží, protože brání spoofingu a dává vám přehled o problémech s doručováním. Začněte s p=none a adresou pro reporty.

Q: Co se stane, když DKIM i SPF selžou, ale e-mail vypadá legitimně?

A: Záleží na vaší politice DMARC. Pokud je p=none, pošta se doručí s varováním. Pokud je p=quarantine, skončí ve spamu. Pokud je p=reject, vrátí se. Proto byste měli sledovat DMARC reporty před vynucením přísné politiky — možná máte legitimní odesílatele, o kterých nevíte.

Q: Mohu použít stejný DKIM klíč pro více domén?

A: Technicky ano, ale nedělejte to. Každá doména by měla mít vlastní pár DKIM klíčů. Sdílení klíčů ztěžuje rotaci a zvyšuje dopad, pokud dojde ke kompromitaci soukromého klíče.

Q: Jak často mám rotovat DKIM klíče?

A: Univerzální pravidlo neexistuje, ale jednou ročně je pro většinu domén rozumné. Pokud máte podezření, že klíč byl kompromitován, rotujte okamžitě. Než začnete podepisovat novým soukromým klíčem, publikujte nový veřejný klíč v DNS a starý klíč ponechte v DNS ještě několik dní po rotaci kvůli zpožděné poště.

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

💡 Vyzkoušejte toto: Prozkoumejte zveřejněné zásady libovolné domény pomocí DMARC Lookup, abyste viděli, jak záznamy MX, SPF a DMARC v praxi spolu souvisejí.

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

Zdroje

• RFC 7208: Sender Policy Framework (SPF) — Specifikace SPF včetně pravidel syntaxe a limitu deseti dotazů.
• RFC 6376: DomainKeys Identified Mail (DKIM) — Specifikace DKIM pokrývající generování a ověřování podpisů.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Specifikace DMARC včetně syntaxe politik a formátu agregovaných reportů.
• Google Workspace: Prevent spoofing and spam — Praktické pokyny ke konfiguraci SPF, DKIM a DMARC pro domény Google Workspace.