SPF, DKIM a DMARC pro firemní e-mail: co nastavit a v jakém pořadí

Po založení schránky může e-mail z nové domény bez problémů odejít, ale adresát jej najde ve spamu nebo jej jeho server odmítne. Tři DNS mechanismy pomáhají příjemci ověřit, zda zpráva skutečně smí vystupovat vaším jménem: SPF, DKIM a DMARC. Nejsou to náhrady za bezpečné heslo ani za dobrý obsah zpráv. Jsou však základní součástí spolehlivého odesílání.

Pokud teprve vybíráte službu, začněte u založení e-mailu na vlastní doméně. Zde vysvětlujeme technickou část s příklady principu; konkrétní DNS hodnoty vždy převezměte od svého poskytovatele, protože se liší podle poštovní služby i odesílajících systémů.

Co jednotlivé záznamy ověřují

SPF se kontroluje proti technické adrese odesílatele, která se může lišit od adresy viditelné v poli „Od“. DKIM používá podpis zprávy. DMARC přidává požadavek na shodu domény s viditelným odesílatelem. Proto může zpráva projít SPF, a přesto neprojít DMARC, pokud ji odeslal cizí systém s vlastní obálkovou doménou a bez odpovídajícího DKIM podpisu.

Nejprve inventura skutečných odesílatelů

Malá firma často posílá poštu z více míst, aniž o tom správce domény ví. Vedle běžných schránek může odesílat fakturační aplikace, formulář na webu, CRM, e-shop, rezervační systém či marketingový nástroj. Před změnou DNS si udělejte přehled:

• Seznam všech aplikací, které posílají z adres na vaší doméně.
• Kdo spravuje jejich přístup a zda podporují vlastní DKIM.
• Jakou doménu používají jako viditelného odesílatele a pro technickou obálku.
• Zda jsou transakční zprávy oddělené od newsletterů.

WordPress přes REST API může zveřejňovat články, ale jeho pluginy a formuláře mohou samostatně posílat notifikace. Nepředpokládejte, že nastavení pošty pro redaktora automaticky ověří i poštu z webu. Pokud systém odesílá přes autentizované SMTP či specializovanou transakční službu, musí být do pravidel zapojen správným způsobem.

Bezpečné pořadí nastavení

1. V DNS domény ověřte, že je přesně jeden platný SPF záznam. Doplňte do něj odesílatele podle návodu jejich provozovatele; nepřidávejte druhý samostatný SPF.
2. U každé služby zapněte DKIM podpis a vložte její předepsaný veřejný klíč nebo CNAME. Odešlete testovací zprávu a zkontrolujte skutečný výsledek ověření v hlavičce.
3. DMARC začněte monitorovací politikou p=none a nastavte schránku pro souhrnné reporty, pokud je budete umět vyhodnocovat.
4. Podle reportů opravte legitimní zdroje, které neprocházejí. Teprve pak postupně přejděte na quarantine a případně reject.
5. Po každé změně znovu vyzkoušejte faktury, formuláře, běžné zprávy a případné kampaně.

Ukázkové řetězce z internetu nekopírujte bez úprav. SPF musí vyjmenovat vaše skutečné odesílatele, DKIM selektory závisejí na službě a příliš brzy zapnuté DMARC p=reject může odmítat i vaše vlastní faktury. Microsoft doporučuje monitorovat a zpřísňovat politiku postupně.

Co skutečně vyžaduje Gmail

Google pro běžné odesílatele do osobních účtů Gmail požaduje SPF nebo DKIM, platné dopředné a zpětné DNS pro odesílající IP a TLS. Pro hromadné odesílatele nad 5 000 zpráv denně do osobního Gmailu jsou pravidla přísnější: SPF i DKIM, DMARC, shoda domény a další požadavky včetně snadného odhlášení u marketingové pošty. Tuto hranici nepřenášejte mechanicky na každou malou firmu. V praxi se ale vyplatí nastavit všechny tři mechanismy i při malém objemu, protože sníží riziko podvržení a usnadní diagnostiku.

Autentizace není záruka doručení do hlavní složky. Příjemce posuzuje i reputaci, stížnosti, obsah a chování adresátů. Podrobný kontrolní postup najdete v článku proč firemní zprávy končí ve spamu.

Jak ověřit výsledek

Pošlete test z každého skutečného odesílacího systému na schránky u různých příjemců. V detailu přijaté zprávy zkontrolujte hlavičky Authentication-Results: SPF, DKIM a DMARC mají ukazovat úspěch ve správné doméně. Otestujte rovněž odpověď a zprávu odeslanou z mobilu. Když ověřením neprojde jen fakturační aplikace, neopravujte naslepo základní poštu; řešte konkrétní zdroj.

Časté otázky

Je DMARC povinný pro každý firemní e-mail?

Nejde o univerzální podmínku pro všechny malé odesílatele. Google však u velkých hromadných odesílatelů DMARC vyžaduje a pro ostatní jej doporučuje. Pro ochranu značky je vhodné jej zavést po inventuře odesílání.

Vyřeší SPF přeposílání zpráv?

Přeposílání může změnit cestu zprávy a SPF ověření zkomplikovat. DKIM podpis, pokud zůstane neporušený a doména odpovídá, může v takové situaci pomoci. Výsledek vždy ověřte testem.

Mohu mít pro jednu doménu dva samostatné SPF záznamy?

Ne pro stejné jméno domény. Více SPF politik v samostatných TXT záznamech může kontrolu zneplatnit; oprávněné odesílatele slučte do jedné politiky podle podkladů všech používaných služeb. Ostatní TXT záznamy pro jiné účely tím nejsou zakázány.

Kdy zpřísnit DMARC z režimu monitorování?

Až ověříte, že legitimní pošta ze všech používaných systémů prochází správně a že hlášení neukazují opomenutého odesílatele. Zpřísňujte postupně a po každé změně otestujte běžné zprávy, faktury i webové formuláře.

Ukázková firma: pošta funguje, ale faktury neprojdou

Modelová firma má zaměstnance ve službě pro běžnou poštu a faktury odesílá účetní aplikace. Zprávy od zaměstnanců procházejí DKIM, ale faktury se tváří jako faktury@firma.cz a aplikace je posílá ze svého serveru. Příjemce v hlavičkách vidí SPF pro jinou technickou doménu a DKIM podpis, který není ve shodě s firma.cz. Pokud je DMARC nastaven příliš přísně, faktura může být odmítnuta či přesunuta do karantény.

Správný postup není bez rozmyslu přidat obrovský seznam serverů do SPF. V účetní aplikaci zjistěte možnosti ověření vlastní domény, zejména DKIM podpis, případně vlastní obálkovou doménu. Pak odešlete testovací fakturu a ověřte v přijaté zprávě, která cesta prošla DMARC. Stejně projděte formulář webu, CRM a newsletter. Každý systém otestujte samostatně; jedna úspěšná zpráva z Outlooku neprokazuje, že doména jako celek je správně nastavena.

Jak číst DNS záznamy bez kopírování cizích hodnot

V DNS správě domény sledujte tři údaje: název záznamu, typ a hodnotu. SPF je textový záznam na doméně používané pro odesílání; pro jednu doménu nemají současně existovat dva nezávislé SPF záznamy. DKIM se obvykle publikuje pod selektorem ve větvi _domainkey, jako TXT nebo CNAME podle poskytovatele. DMARC je TXT pod _dmarc. Konkrétní selektor, hodnotu a syntaxi získáte ze správy používané služby. Pokud si nejste jisti samotnou správou zóny, začněte u srozumitelného vysvětlení DNS.

Na počítači lze veřejné hodnoty orientačně číst například příkazy nslookup -type=mx firma.cz, nslookup -type=txt firma.cz a nslookup -type=txt _dmarc.firma.cz. Místo „firma.cz“ vložte vlastní doménu. Tyto příkazy jen čtou DNS; neukážou, zda se konkrétní zpráva skutečně podepsala. DKIM selektor bývá různý podle služby, proto jej hledejte v její administraci a kontrolujte na odpovídajícím názvu. Při rozdílných výsledcích z různých resolverů počkejte na propagaci a zkontrolujte aktivní nameservery.

Co znamená DMARC politika v praxi

p=none žádá příjemce o reportování, ale samo jim nepřikazuje podezřelé zprávy karanténovat či odmítat. p=quarantine je doporučení takové zprávy oddělit a p=reject doporučení odmítnout. Přechod na přísnější politiku má smysl, když víte, odkud všechna legitimní pošta odchází a reporty neukazují vlastní systémy mezi selháními. Příjemci politiky vyhodnocují ve svém prostředí; jeden záznam neslibuje stejné chování všech schránek.

• Začněte inventurou systémů a testovacími zprávami ze všech zdrojů.
• U DMARC reportů rozlišujte cizí pokusy o podvržení od vlastních aplikací, které mají chybnou shodu.
• Pokud zprávy z důležité aplikace selhávají, opravte její autorizaci či podpis dřív než zpřísníte politiku.
• Po změně monitorujte faktury, formuláře a odpovědi zákazníkům; jednoduchá pošta pracovníků nestačí.

Jak přečíst hlavičku jedné testovací zprávy

Pošlete zprávu z konkrétní služby na externí schránku a otevřete zobrazení úplných hlaviček nebo původní zprávy. Hledejte řádek Authentication-Results a v něm výsledky spf=, dkim= a dmarc=. U úspěšného DMARC zkontrolujte také doménu viditelnou v From:. Pouhé spf=pass neznamená automaticky dmarc=pass; obálková doména může patřit dodavateli aplikace.

Připravte si jednoduchý protokol: datum, odesílací systém, viditelná adresa, příjemce, výsledky ověření a složka, v níž se zpráva objevila. U služby, která selhává, jej pošlete podpoře bez hesel a bez obsahu citlivých zpráv. Tento postup je mnohem přesnější než věta „SPF máme nastavené a stejně to padá do spamu“.

Časté chyby před ostrým spuštěním

Nejčastější technické omyly jsou dva oddělené SPF záznamy, DKIM klíč vložený pod špatný selektor, zapnutý DMARC p=reject před inventurou odesílatelů a webový formulář odesílající „Od“ z domény návštěvníka. Dalším problémem je úprava DNS u registrátora, ačkoli doména používá jiné nameservery. Kontrola musí vždy skončit testem skutečné zprávy, nikoli jen kontrolou uloženého formuláře v administraci.

Kontrola po změně poskytovatele nebo pluginu

Nastavení není hotové navždy. Při změně e-mailové služby přidejte nového odesílatele do SPF nebo jej nahraďte podle nové architektury, zapněte nový DKIM podpis a teprve potom odstraňte staré hodnoty, které už nikdo nepoužívá. Podobně aktualizace formulářového pluginu může změnit způsob odesílání z WordPressu. Po takové změně pošlete test z každé důležité cesty a znovu zkontrolujte hlavičky. V evidenci si ponechte vlastníka systému, kdo DNS změnu provedl, kdy ji provedl a jaká testovací zpráva potvrdila výsledek. Pokud se doručování později zhorší, budete vědět, kterou změnu porovnat s posledním funkčním stavem. Pořadí přípravy schránek, změny záznamů a následného testu rozvádí postup migrace firemní pošty.

V týmu určete člověka, který tyto kontroly zopakuje po přidání nového CRM nebo rozesílací služby. Dodavatel aplikace může tvrdit, že pošta odchází správně, ale příjemcův výsledek SPF, DKIM a DMARC ukáže skutečné doručení. Ukládejte jen technické důkazy potřebné k diagnostice.

Zdroje

• Google: Email sender guidelines, pravidla pro běžné a hromadné odesílatele ověřena 21. 10. 2026.
• Microsoft Learn: Configure DMARC, význam shody a postupné politiky ověřen 21. 10. 2026.