Běžíme v testovacím provozu, prosíme o shovívavost a zpětnou vazbu.
DNS záznamy pro e-mail — kompletní průvodce

DNS záznamy pro e-mail — kompletní průvodce

· 9 min čtení · Tomas Hojgr · dns

Proč jsou DNS záznamy klíčové pro e-mail

Každý e-mail, který odešlete nebo přijmete, závisí na DNS záznamech vaší domény. DNS záznamy určují, kam se e-maily doručují, kdo je smí odesílat a jak se ověřuje identita odesílatele. Špatně nastavený DNS znamená nedoručené e-maily, odmítnuté zprávy nebo zneužití vaší domény k phishingu.

Tento článek pokrývá všechny typy DNS záznamů relevantní pro e-mail — od MX záznamů přes autentizační TXT záznamy až po reverzní DNS. Ke každému typu najdete vysvětlení, příklad a konkrétní doporučení.

MX záznamy — kam se doručují e-maily

MX záznam (Mail Exchange) říká odesílajícím serverům, na který mailový server mají doručit e-mail pro vaši doménu. Bez MX záznamu nelze na vaši doménu přijímat e-maily.

Jak MX záznam funguje

Když někdo pošle e-mail na info@vasedomena.cz, odesílající server se dotáže DNS na MX záznamy domény vasedomena.cz. DNS vrátí jeden nebo více mailových serverů s prioritou. Server s nejnižší hodnotou priority (= nejvyšší priorita) se použije jako první.

Příklad MX záznamu

vasedomena.cz.  3600  IN  MX  10 mx1.mailserver.cz.
vasedomena.cz.  3600  IN  MX  20 mx2.mailserver.cz.
  • Priorita 10 — primární server (mx1.mailserver.cz)
  • Priorita 20 — záložní server (mx2.mailserver.cz), použije se při nedostupnosti primárního

MX záznamy běžných služeb

Služba MX záznam Priorita
Google Workspace aspmx.l.google.com 1
Microsoft 365 <tenant>.mail.protection.outlook.com 0
Seznam.cz (firemní) smtpx.seznam.cz 10

Google Workspace od roku 2023 vyžaduje pouze 1 MX záznam (smtp.google.com s prioritou 1). Starší konfigurace s 5 MX záznamy stále funguje — podrobnosti v dokumentaci Google Workspace.

Pravidla pro MX záznamy

  • MX záznam musí ukazovat na doménové jméno (hostname), nikoli na IP adresu — RFC 5321, sekce 5.1
  • Cílový hostname musí mít vlastní A záznam (nebo AAAA pro IPv6)
  • MX záznam nesmí ukazovat na CNAME — to je porušení RFC 2181
  • Pokud doménu nepoužíváte pro e-mail, nastavte null MX: priorita 0, cíl . (tečka)

TXT záznamy — autentizace a ověřování

TXT záznam je univerzální typ DNS záznamu, který uchovává textová data. Pro e-mail se TXT záznamy používají k publikaci autentizačních politik — SPF, DMARC a ověřování vlastnictví domény.

SPF záznam

SPF (Sender Policy Framework) definuje, které servery smějí odesílat e-maily z vaší domény. Publikuje se jako TXT záznam na kořenové doméně.

vasedomena.cz.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Tento záznam povoluje odesílání přes Google Workspace a SendGrid. Vše ostatní bude odmítnuto (-all).

Zásadní pravidla:

DMARC záznam

DMARC (Domain-based Message Authentication, Reporting, and Conformance) propojuje SPF a DKIM s adresou v hlavičce From a definuje, co dělat s neověřenými e-maily. Publikuje se jako TXT záznam na subdoméně _dmarc.

_dmarc.vasedomena.cz.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:vasedomena.cz@rua.spfmonitor.com; pct=100"
Parametr Význam
p=quarantine Neověřené e-maily označit jako podezřelé (spam)
rua=mailto:... Adresa pro příjem souhrnných DMARC reportů
pct=100 Politiku aplikovat na 100 % e-mailů

Podrobný návod: Jak nastavit DMARC záznam

Ověřování vlastnictví domény

Mnoho služeb (Google Workspace, Microsoft 365, marketingové platformy) vyžaduje ověření vlastnictví domény přidáním specifického TXT záznamu. Tyto záznamy mají typicky formu:

vasedomena.cz.  3600  IN  TXT  "google-site-verification=AbCdEf123456"

Na rozdíl od SPF můžete mít na doméně více TXT záznamů pro různé účely — verifikační záznamy, SPF a další existují vedle sebe bez konfliktu.

CNAME záznamy — DKIM a delegace

CNAME (Canonical Name) záznamy vytváří alias jednoho doménového jména na jiné. Pro e-mail se CNAME používají primárně pro DKIM podpisy.

DKIM záznamy

DKIM (DomainKeys Identified Mail) přidává ke každému e-mailu kryptografický podpis. Příjemce ověří podpis pomocí veřejného klíče publikovaného v DNS. DKIM záznamy se umísťují na subdoménu ve formátu {selektor}._domainkey.vasedomena.cz.

Většina e-mailových služeb vyžaduje přidání CNAME záznamu, který deleguje DKIM na jejich infrastrukturu:

selector1._domainkey.vasedomena.cz.  3600  IN  CNAME  selector1-vasedomena-cz._domainkey.vasedomena.onmicrosoft.com.

Tento příklad ukazuje DKIM delegaci pro Microsoft 365 — CNAME odkazuje na klíč spravovaný Microsoftem.

Některé služby vyžadují přímý TXT záznam s veřejným klíčem:

mail._domainkey.vasedomena.cz.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Podrobný návod: Jak nastavit DKIM záznam

BIMI záznam

BIMI (Brand Indicators for Message Identification) umožňuje zobrazit logo odesílatele v e-mailovém klientu příjemce. Publikuje se jako TXT záznam na subdoméně default._bimi:

default._bimi.vasedomena.cz.  3600  IN  TXT  "v=BIMI1; l=https://vasedomena.cz/logo.svg"

BIMI vyžaduje funkční DMARC s politikou quarantine nebo reject.

PTR záznamy — reverzní DNS

PTR záznam (Pointer) je reverzní DNS záznam — mapuje IP adresu zpět na doménové jméno. Přijímající mailové servery používají PTR k ověření, že odesílající server má platný reverzní záznam.

Proč na PTR záleží

Mnoho mailových serverů (včetně Gmailu) odmítne nebo penalizuje e-maily ze serverů bez platného PTR záznamu. PTR záznam by měl odpovídat HELO/EHLO hostname (pozdravení, kterým se mailový server identifikuje při navázání spojení) odesílajícího serveru.

Kdo PTR nastavuje

PTR záznamy nespravuje vlastník domény, ale provozovatel IP adresy (hosting, ISP nebo cloudový provider). Pokud provozujete vlastní mailový server:

  1. Kontaktujte poskytovatele IP adresy
  2. Požádejte o nastavení PTR záznamu pro IP vašeho serveru
  3. PTR by měl ukazovat na hostname, který má zpětně A záznam na stejnou IP (forward-confirmed reverse DNS — zpětně potvrzený reverzní záznam)

Pokud používáte službu jako Google Workspace nebo Microsoft 365, PTR záznamy spravuje poskytovatel — nemusíte řešit.

Jak DNS záznamy spolupracují

Při doručení e-mailu přijímající server provede sérii kontrol, které závisí na různých DNS záznamech:

  1. MX lookup — odesílající server zjistí, kam doručit e-mail
  2. SPF kontrola — přijímající server ověří, zda je odesílající IP povolená v SPF záznamu domény z envelope sender
  3. DKIM ověření — přijímající server stáhne veřejný klíč z DNS a ověří podpis v hlavičce e-mailu
  4. DMARC vyhodnocení — přijímající server zkontroluje alignment (shodu domén) a aplikuje politiku z DMARC záznamu
  5. PTR kontrola — přijímající server ověří reverzní DNS odesílajícího serveru

Každý chybějící nebo špatně nastavený záznam může vést k nedoručení e-mailu nebo jeho označení jako spam.

Kontrolní seznam DNS záznamů pro e-mail

Použijte tento seznam pro audit DNS konfigurace vaší domény:

  • MX záznamy — ukazují na správné mailové servery, cíl má platný A záznam
  • SPF záznam — jeden TXT záznam v=spf1, zahrnuje všechny legitimní odesílatele, nepřekračuje 10 DNS dotazů
  • DKIM záznamy — CNAME nebo TXT záznamy pro každou odesílající službu s odpovídajícím selektorem
  • DMARC záznam — TXT záznam na _dmarc subdoméně s definovanou politikou a adresou pro reporty
  • PTR záznam — pokud provozujete vlastní server, reverzní DNS odpovídá hostname serveru
  • Žádné konflikty — neexistují duplicitní SPF záznamy, CNAME není na kořenové doméně s MX

Časté chyby v DNS záznamech pro e-mail

Chybějící MX záznam

Bez MX záznamu se e-maily pokusí doručit na A záznam domény (fallback podle RFC 5321). To funguje jen pokud na dané IP běží mailový server — což u většiny webových serverů neplatí.

Duplicitní SPF záznamy

Druhý nejčastější problém. Administrátor přidá nový SPF záznam místo úpravy stávajícího. Výsledek: PermError, SPF kontrola selže pro všechny e-maily.

CNAME na kořenové doméně

CNAME záznam na kořenové doméně (vasedomena.cz) je technicky neplatný a může kolidovat s MX a TXT záznamy. Některé DNS providery to umožňují přes proprietární řešení (Cloudflare CNAME flattening, Route 53 alias), ale pro e-mailové záznamy se tomu vyhněte.

Nízké TTL u stabilních záznamů

MX záznamy a autentizační záznamy se mění výjimečně. TTL nastavené na 300 sekund (5 minut) zbytečně zvyšuje DNS provoz. Pro stabilní záznamy použijte TTL 3600 (1 hodina) nebo vyšší.

Zapomenutý DKIM po migraci

Při přechodu na novou e-mailovou službu administrátoři často nastaví nové MX záznamy, ale zapomenou aktualizovat DKIM záznamy. Starý DKIM klíč přestane fungovat a DKIM kontrola začne selhávat.

DNS záznamy nejsou jednorázové nastavení

DNS konfigurace se mění — přidáváte služby, měníte providery, rotujete DKIM klíče. Jednorázová kontrola nestačí. Pravidelný monitoring DNS záznamů odhalí problémy dříve, než ovlivní doručitelnost vašich e-mailů.

Ověřte si kompletní DNS konfiguraci vaší domény analyzérem SPFmonitor — zkontroluje MX, SPF, DKIM, DMARC i další záznamy na jednom místě.

Číst v jiném jazyce: English

Související články

Jak vytvořit SPF záznam krok za krokem
spf

Jak vytvořit SPF záznam krok za krokem

Praktický návod na vytvoření SPF záznamu pro vaši doménu. Od mapování odesílatelů přes sestavení záznamu až po ověření a hlídání limitu DNS dotazů.

· 6 min čtení
Jak nastavit DMARC záznam pro vaši doménu

Jak nastavit DMARC záznam pro vaši doménu

Praktický návod na nastavení DMARC záznamu krok za krokem. Od prvního záznamu s p=none přes analýzu reportů až po plnou ochranu s p=reject.

· 10 min čtení
Jak nastavit DKIM záznam krok za krokem

Jak nastavit DKIM záznam krok za krokem

Praktický návod na nastavení DKIM záznamu. Od generování klíčů přes DNS publikaci po konfiguraci Google Workspace, Microsoft 365 a vlastního serveru.

· 9 min čtení