E-mail na vlastní doméně: hosting, DNS a doručitelnost

Schránku na vlastní doméně si dnes zřídíš za deset minut. Zbylých devadesát procent práce je jinde — ve čtyřech DNS záznamech, které příjemcům říkají, kam poštu doručit a jestli jí mají věřit. Když je nemáš nebo je máš špatně, faktura klientovi skončí ve spamu a ty se to dozvíš až týden po splatnosti. Projdeme si je po řadě, včetně přesné syntaxe, protože špatný příklad DMARC záznamu nadělá víc škody než žádný.

Co si vlastně kupuješ, když kupuješ e-mail hosting

E-mail hosting je služba, která za tebe provozuje příchozí server (přijímá poštu podle MX záznamu a ukládá ji do schránek), odchozí server (SMTP, přes který posíláš) a přístup ke schránkám přes IMAP nebo webmail. K tomu obvykle antispam, antivirus a nějaká forma administrace uživatelů.

Nejčastější rozcestí je mezi samostatným mailhostingem u českého poskytovatele a produktivní sadou typu Google Workspace nebo Microsoft 365. Rozdíl není v doručitelnosti — tu si stejně řídíš sám přes DNS. Rozdíl je v tom, co dostaneš navíc: kalendáře, sdílené dokumenty, správu zařízení a jednotné přihlašování. Konkrétní služby a kapacity si srovnej v kategorii e-mail hostingu; jako příklad samostatného mailhostingu jsem rozebral WEDOS Mailhosting.

Pozor na jednu věc, která lidi překvapuje pravidelně: e-mail nemusí běžet u stejného poskytovatele jako web. MX záznam ukazuje jinam než A záznam a je úplně v pořádku mít web na webhostingu a poštu jinde.

MX záznam: kam se pošta doručuje

MX (Mail Exchanger) je DNS záznam, který odesílajícímu serveru řekne, na jaký stroj má poštu pro tvou doménu předat. Číslo před názvem je priorita — nižší číslo znamená vyšší přednost, ne naopak.

Odesílatel zkusí nejdřív mx1, a když neodpovídá, sáhne po mx2. Hodnotou MX musí být hostname, nikdy IP adresa — to je chyba, kterou v konfiguracích vídám dost často. Druhý klasický průšvih: nechat po migraci starý MX záznam vedle nového. Pošta se pak rozdělí mezi dvě schránky podle toho, který server zrovna odpoví, a ty půl dne hledáš „ztracené" zprávy.

SPF: kdo smí odesílat za tvou doménu

SPF (Sender Policy Framework, RFC 7208) je TXT záznam na kořeni domény, ve kterém vyjmenuješ servery oprávněné odesílat poštu s tvou adresou v obálce.

Tři pravidla, která musíš dodržet:

1. Jeden SPF záznam na doménu. Dva záznamy v=spf1 znamenají trvalou chybu a kontrola selže — víc odesílatelů se skládá do jednoho záznamu přes další include:.
2. Maximálně 10 DNS dotazů. RFC 7208 omezuje počet mechanismů, které vyžadují DNS dotaz (include, a, mx, ptr, exists a modifikátor redirect), na deset na jednu kontrolu. Mechanismy ip4, ip6 a all se do limitu nepočítají. Při překročení dostaneš PermError a DMARC to vyhodnotí jako neúspěch — pro všechny zprávy, ne jen pro některé.
3. Zvol si závěrečný mechanismus vědomě. ~all je softfail (zpráva projde, ale je označená), -all je hardfail (zpráva se má odmítnout). Začni na ~all, a teprve když máš v reportech jistotu, že jsi na nic nezapomněl, přitvrď na -all.

Nejčastější příčina překročení limitu je „ještě jeden nástroj": e-mail hosting, fakturační systém, newsletterový nástroj, CRM a helpdesk, každý s vlastním include:. Než přidáš pátý, zkontroluj si počet dotazů.

DKIM: podpis, který zprávu spojí s doménou

DKIM (DomainKeys Identified Mail, RFC 6376) přidává do hlavičky každé odchozí zprávy kryptografický podpis. Veřejný klíč k jeho ověření zveřejníš v DNS na adrese <selektor>._domainkey.<doména>. Selektor si volí odesílající služba, takže jich můžeš mít vedle sebe víc — jeden pro mailhosting, jeden pro newsletter.

Klíčový pár ti vygeneruje poskytovatel, ty jen zkopíruješ hodnotu p=. Na velikosti klíče záleží: RFC 8301 říká, že podepisující strana musí použít RSA klíč alespoň 1024 bitů a měla by použít alespoň 2048 bitů, a zároveň zakazuje algoritmus rsa-sha1.

Poznámka z provozu: 2048bitový klíč se do jednoho DNS řetězce nevejde a musí se rozdělit do víc částí v rámci jednoho TXT záznamu. Většina DNS rozhraní to udělá sama, některá ne — a pak podpis neověří nikdo. Po nastavení si vždy ověř, že se záznam z internetu čte celý.

DMARC: co se má stát, když kontrola selže

SPF a DKIM samy o sobě nikomu neříkají, jak se zachovat při selhání. Od toho je DMARC — TXT záznam na _dmarc.<doména>, který stanoví politiku a adresu pro reporty.

Tag v=DMARC1 musí být první, jinak je záznam neplatný. p= nabývá hodnot none (jen sleduj a reportuj), quarantine (do spamu) a reject (odmítnout). rua= je adresa pro souhrnné reporty a prefix mailto: je povinný.

Podstatné je, jak se DMARC vyhodnocuje: projde tehdy, když uspěje SPF nebo DKIM a zároveň je ověřená doména zarovnaná s doménou v hlavičce From:, kterou vidí příjemce. Proto může zpráva mít platný SPF a přesto DMARC neprojde — typicky u přeposílaných zpráv nebo když newsletterový nástroj odesílá z vlastní obálkové domény.

Postup je vždycky stejný: nasaď p=none, nech si pár týdnů chodit reporty, dohledej všechny legitimní odesílatele, a teprve pak přitvrzuj na quarantine a reject. Kdo skočí rovnou na p=reject, obvykle si sám zablokuje fakturační systém.

Ke specifikaci jen na okraj: v květnu 2026 nahradila původní RFC 7489 trojice RFC 9989, 9990 a 9991 a posunula DMARC mezi standardy IETF. Záznamy s v=DMARC1 fungují dál beze změny; přibyl mimo jiné tag np pro neexistující subdomény.

Přehled záznamů

Co po tobě chtějí velcí příjemci

Gmail rozděluje odesílatele do dvou skupin. Po všech chce alespoň SPF nebo DKIM, šifrované TLS spojení a platné dopředné i zpětné DNS záznamy (PTR), přičemž odesílající IP adresa musí odpovídat hostname z PTR záznamu. Po hromadných odesílatelích od 5 000 zpráv denně navíc SPF i DKIM, nastavený DMARC (stačí p=none), míru stížností na spam pod 0,3 % v Postmaster Tools a jednoklikové odhlášení u marketingových zpráv (pokyny pro odesílatele, Google).

Pro malou firmu, která pošle padesát mailů denně, z toho plyne jednoduchý závěr: povinné minimum je nízké, ale nastavit všechny čtyři záznamy se vyplatí tak jako tak. Cloudflare ve svém přehledu roku 2025 uvádí, že přes 5 % analyzovaných zpráv bylo vyhodnoceno jako škodlivých, přičemž mezi nejčastější techniky patřilo vydávání se za cizí identitu a napodobování značek (Cloudflare Radar 2025 Year in Review). DMARC s vynucovací politikou je jediná věc, která někomu zabrání posílat podvodné faktury jménem tvojí domény.

Migrace schránek bez ztracené pošty

1. Založ schránky u nového poskytovatele a nastav SPF, DKIM i DMARC dřív, než sáhneš na MX.
2. Přenes obsah přes IMAP synchronizaci (většina poskytovatelů má nástroj, jinak imapsync). První běh nech doběhnout celý.
3. Sniž TTL u MX záznamu na 300 sekund a počkej, až se stará hodnota vyexpiruje.
4. Přepni MX na nového poskytovatele.
5. Nech starou schránku aktivní ještě 7–14 dní a spusť dosynchronizaci — chytíš tím poštu, která dorazila během přepínání.
6. Zkontroluj odesílání i příjem z externí adresy a projdi si první DMARC reporty.

Časté chyby v DNS

• Dva v=spf1 záznamy na jedné doméně po přidání druhého odesílatele.
• IP adresa místo hostname v MX záznamu.
• Starý MX záznam ponechaný vedle nového po migraci.
• DKIM klíč zkopírovaný jen zčásti nebo s vloženými zalomeními řádků.
• p=reject nasazené hned první den, bez období sledování.
• Chybějící mailto: v tagu rua.
• Změny prováděné u registrátora, zatímco doména používá DNS servery někoho jiného.

Pokud DNS pro doménu teprve skládáš, projdi si při té příležitosti i DNSSEC u .cz domén — chrání odpovědi včetně MX záznamu před podvržením.

FAQ

Stačí mi jen SPF, nebo potřebuju i DKIM?

Pro základní doručitelnost stačí jedno z toho. Pro DMARC potřebuješ obojí prakticky vždy, protože SPF se při přeposílání zprávy rozpadne a DKIM podpis přežije. Nastav obojí.

Můžu mít dva SPF záznamy?

Ne. Doména smí mít jediný TXT záznam začínající v=spf1. Další odesílatele přidáváš do stejného záznamu dalším include:.

Co je selektor u DKIM?

Jmenný prefix, který určuje, ve kterém DNS záznamu se hledá veřejný klíč. Díky němu můžeš mít pro jednu doménu víc podpisových klíčů — každá odesílající služba dostane svůj.

Proč mi maily padají do spamu, i když mám SPF, DKIM i DMARC?

Ověření je jen vstupenka, ne garance. Rozhoduje i reputace odesílající IP a domény, poměr stížností, obsah zprávy a to, jestli příjemci tvoje maily otevírají. Řeš seznam příjemců, ne další DNS záznam.

Jak dlouho trvá, než se změna projeví?

Podle TTL záznamu — obvykle jednotky hodin, po snížení TTL na 300 sekund pár minut. Před plánovanou změnou TTL sniž s předstihem.

Mám nasadit rovnou p=reject?

Ne. Začni na p=none, nech si měsíc chodit reporty, dohledej všechny legitimní odesílatele a teprve pak přejdi na quarantine a reject.

Musím to řešit, když posílám dvacet e-mailů denně?

Ano. Limit 5 000 zpráv denně se týká jen přísnějších pravidel pro hromadné odesílatele. Bez ověření hrozí spam složka i u jediné zprávy — a bez DMARC se za tvou doménu může vydávat kdokoli.

Závěr

E-mail na vlastní doméně je ze dvou třetin DNS. MX říká, kam poštu doručit, SPF a DKIM dokazují, že zpráva je opravdu od tebe, a DMARC určuje, co se stane, když důkaz chybí. Nastav je v tomhle pořadí, začni na p=none a nech si chodit reporty — během měsíce budeš mít o odchozí poště víc informací než většina firem.

Vybíráš teprve poskytovatele? Kapacity schránek, počty aliasů a ceny máš vedle sebe v porovnávači e-mail hostingu.