Bezpečnost e-mailů

Bezpečnost e-mailů

Bezpečnost e-mailů stojí na kombinaci technických kontrol, které ověřují původ zprávy a zabraňují podvržení odesílatele (spoofing) a neautorizovanému použití domény. Tři klíčové technologie jsou SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) a DMARC (Domain-based Message Authentication, Reporting and Conformance). Společně vytvářejí rámec, který zvyšuje doručitelnost legitimní pošty a omezuje rizika phishingu i reputačních škod.

SPF – ověření IP adres odesílající poštu

Princip: SPF deklaruje, které servery (IP adresy či jiné domény) smějí odesílat poštu jménem dané domény. Příjemce kontroluje, zda IP odesílajícího serveru odpovídá pravidlům v TXT záznamu domény v DNS.

• Formát záznamu: TXT na úrovni domény, např. example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.provider.tld -all"
• Mechanismy: ip4/ip6, a, mx, include, exists, ptr (nedoporučeno), all s kvalifikátory +, ~ (softfail), - (fail), ? (neutral).
• Limity: max. 10 DNS lookupů (včetně include, a, mx, ptr, exists, redirect); velikost záznamu do ~255 znaků na řádek (DNS limit) – v praxi použijte rozumně krátké seznamy a konsolidaci.
• Slabá místa: SPF se ověřuje proti doméně v obálce (envelope-from/MAIL FROM) nebo HELO/EHLO, nikoli nutně proti From: v hlavičce viditelné uživateli. Při přeposílání (forwarding) se IP změní a SPF často selže; tento problém řeší DMARC a ARC.

DKIM – kryptografický podpis obsahu

Princip: Odesílatel podepíše vybrané části hlaviček a těla e-mailu privátním klíčem. Příjemce ověří podpis veřejným klíčem publikovaným v DNS. Tím se prokazuje, že zpráva nebyla cestou změněna a že podpis vygenerovala entita kontrolující DNS domény uvedené v podpisu (d=).

• Klíčové parametry hlavičky DKIM: d= (doména), s= (selektor, např. selector1), h= (seznam podepsaných hlaviček), bh= (hash těla), b= (vlastní podpis), a= (algoritmus, např. rsa-sha256), c= (kanonikalizace, např. relaxed/relaxed).
• DNS záznam: TXT na <selector>._domainkey.example.com, např. v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B...
• Doporučení: RSA 2048 bit (nebo ECDSA, dle podpory), podepisovat minimálně hlavičky From, Date, Subject, Message-ID a body; používat rotaci klíčů pomocí vícero selektorů (např. s=2025q4).
• Odolnost vůči úpravám: relaxed kanonikalizace toleruje whitespace změny a zlomky řádků; přesto může mailing list, který vkládá footery či mění Subject, podpis zneplatnit. Zde pomáhá ARC.

DMARC – politika, zarovnání identit a reporting

Princip: DMARC navazuje na SPF a DKIM a vyžaduje tzv. alignment (zarovnání) domény viditelné uživateli v hlavičce From: s doménami ověřenými SPF nebo DKIM. Pokud není splněno, příjemce uplatní politiku domény: monitorovat, označovat jako spam, nebo odmítnout.

• DNS záznam: TXT na _dmarc.example.com, např. v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; aspf=s; adkim=s; pct=100; sp=reject
• Politiky: p=none (monitoring), p=quarantine, p=reject; pct= umožní postupné nasazení (např. 25 %, 50 %…)
• Zarovnání: aspf/adkim mohou být r (relaxed – shoda na základní doméně) nebo s (strict – přesná shoda FQDN). Pro vyšší ochranu doporučeno strict.
• Reporty: rua (agregované XML denně), ruf (forenzní – jednotlivé selhané zprávy; méně používané kvůli ochraně soukromí). Parametr fo= (0/1/d/s) určuje, kdy generovat forenzní reporty.
• Subdomény: sp= nastavuje politiku pro subdomény, jinak dědí z p=. Vhodné při postupné migraci různých odesílacích systémů.

Vztah a spolupráce SPF, DKIM a DMARC

DMARC uzná zprávu, pokud alespoň jeden z mechanismů (SPF nebo DKIM) projde a je zarovnán s doménou ve From:. Proto je dobré mít obojí – SPF i DKIM – a zajistit jejich alignment. SPF řeší autorizaci odesílacích IP, DKIM přidává kryptografickou integritu a odolnost vůči přeposílání; DMARC sjednocuje rozhodnutí a reporting.

Postup implementace – doporučená roadmapa

1. Inventarizace odesílatelů: mapujte všechny systémy posílající poštu (MTA, CRM, newsletter, fakturační systémy, cloudové služby, helpdesk).
2. SPF návrh: konsolidujte IP a include mechanizmy. Omezte počet lookupů ≤ 10, eliminujte duplicitní záznamy a používejte -all až po plném pokrytí.
3. DKIM nasazení: generujte silné klíče, použijte jasné selektory a proces rotace. U SaaS aktivujte jejich DKIM (vlastní doména, ne jen default).
4. DMARC v režimu p=none: sbírejte rua reporty alespoň 2–4 týdny, analyzujte legitimní i nelegitimní zdroje.
5. Alignment a úpravy identit: sjednoťte doménu ve From: napříč systémy, nastavte aspf/adkim, opravte podpisy.
6. Zpřísnění politiky: postupně zvyšte pct a přejděte na quarantine, poté reject. Sledujte doručitelnost a reputační metriky.
7. Operativní režim: pravidelná analýza rua, rotace DKIM klíčů, revize SPF po změnách dodavatelů.

Typické problémy a jejich řešení

• Přeposílání (forwarding) a mailing listy: SPF často selže, protože IP se změní; DKIM může selhat kvůli úpravám obsahu. Řešení: důraz na DKIM, nasadit a respektovat ARC (Authenticated Received Chain) u přeposílacích bodů.
• Překročení SPF lookup limitu: sloučit include, používat SPF „flattening“ s opatrností (režie údržby); preferovat poskytovatele s minimem zanořených include.
• Více odesílacích platforem: sjednotit From: doménu, všude aktivovat DKIM s vaší doménou (ne shared), zajistit alignment.
• Chybné TTL a propagace DNS: plánovat změny s nižším TTL; testovat nástroji (dig/nslookup, validátory).
• Filtrované reporty DMARC: rua musí být doručitelná; některé organizace akceptují reporty jen na adresy s autorizačním záznamem ruf/rua (URI s mailto: a povolenou doménou).

ARC – Authenticated Received Chain

ARC umožňuje, aby přeposílací server „přenášel“ informaci o původním ověření SPF/DKIM/DMARC dál v řetězci. Přijímající MTA pak může důvěryhodně vyhodnotit zprávu i po úpravách (např. vložení footera). ARC nechrání doménu sama o sobě, ale zlepšuje doručitelnost legitimně přeposlané pošty.

BIMI – vizuální identita v doručené poště

Brand Indicators for Message Identification dovolují zobrazovat u ověřených e-mailů logo značky. Technicky BIMI vyžaduje přinejmenším DMARC v režimu quarantine/reject a publikovaný SVG a volitelně ověřovací certifikát VMC. Nejde o bezpečnostní kontrolu samotnou, ale zvyšuje důvěru a konzistenci značky.

Doplňkové standardy transportní bezpečnosti

• MTA-STS: politika v DNS a na HTTPS, která říká, že příjemce vyžaduje TLS pro SMTP a jaké jméno certifikátu akceptuje. Snižuje riziko downgrade útoků na STARTTLS.
• SMTP TLS Reporting (TLS-RPT): agregované reporty o problémech s TLS při doručování (_smtp._tls TXT).
• DANE pro SMTP (TLSA): svazuje certifikát s DNSSEC – silná, ale náročnější varianta, pokud máte DNSSEC.

Příklady vzorových DNS záznamů

• SPF (konsolidovaný): example.com. TXT "v=spf1 ip4:198.51.100.0/24 include:_spf.mailer.tld include:_spf.crm.tld -all"
• DKIM (selektor 2025q4): 2025q4._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA..."
• DMARC (strict, karanténa, reporty): _dmarc.example.com. TXT "v=DMARC1; p=quarantine; sp=reject; adkim=s; aspf=s; pct=100; rua=mailto:dmarc-rua@example.com"
• MTA-STS: _mta-sts.example.com. TXT "v=STSv1; id=20251025" a politika na https://mta-sts.example.com/.well-known/mta-sts.txt
• TLS-RPT: _smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Metodika testování a monitoringu

• Validace DNS: po každé změně kontrola propagace, syntaktické korektnosti a počtu lookupů u SPF.
• Ověření podpisů: poslat testovací zprávy na externí schránky a zkontrolovat hlavičky Authentication-Results (spf=pass/fail, dkim=pass/fail, dmarc=pass/fail, alignment).
• Analýza reportů: automatizovat zpracování rua (nástroje/skripty), sledovat nové zdroje, podvržené kampaně a trendy doručitelnosti.
• Rotace klíčů: plánovat periodicky (např. 6–12 měsíců), zavést více selektorů a grace period pro přechod.

Bezpečnostní a provozní doporučení

• Jedna „From“ doména napříč systémy: zjednoduší alignment a řízení reputace.
• Oddělení transakčních a marketingových toků: samostatné subdomény (např. notify.example.com, news.example.com) s vlastními klíči a politikami.
• Minimální oprávnění: SaaS službám delegujte jen nezbytné DNS záznamy (DKIM selektory), spravujte privátní klíče mimo veřejná repozitáře.
• Incident response: při zjištění zneužití domény rychle zpřísnit p=, revokovat/rotovat DKIM selektory, informovat partnery.
• Dokumentace: udržujte katalog odesílatelů, klíčů, selektorů, TTL, odpovědných osob a plánů rotace.

Časté mýty

• „SPF stačí.“ Nestačí – nechrání hlavičku From a selhává při přeposílání.
• „DKIM zajišťuje doručitelnost.“ Pomáhá reputaci, ale bez správného DMARC a reputační hygieny (obsah, bounce rate) není zárukou.
• „DMARC reject zablokuje veškerý phishing.“ Výrazně sníží spoofing vaší domény, ale nechrání proti vizuálně podvrženým doménám (look-alike); nutná je i ochrana značky a uživatelské vzdělávání.

Metriky úspěšnosti a KPI

Závěr

SPF, DKIM a DMARC tvoří základní pilíře identity a integrity e-mailu. Správně navržené a udržované záznamy v DNS, doplněné o ARC pro přeposílání, MTA-STS/TLS-RPT a případně DANE, výrazně snižují rizika spoofingu a zlepšují doručitelnost. Klíčem k úspěchu je inventarizace všech odesílacích zdrojů, postupné zpřísňování politik DMARC, průběžná analýza reportů a disciplinovaná rotace DKIM klíčů. Organizace, které tyto principy zavedou a pravidelně auditují, chrání nejen své uživatele a zákazníky, ale i reputaci své značky v dlouhodobém horizontu.