Zabezpečení e-mailové komunikace

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žívejte 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 tělo; používat rotaci klíčů pomocí více selektorů (např. s=2025q4).
  • Odolnost vůči úpravám: relaxed kanonikalizace toleruje změny bílých znaků a rozdělení řádků; přesto může mailing list, který vkládá footery či mění Subject, podpis zneplatnit. V takových případech 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 zprávu.

  • 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žňuje 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 plně kvalifikované domény). Pro vyšší ochranu je 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 vhodné 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 odesílající poštu (MTA, CRM, newsletter, fakturační systémy, cloudové služby, helpdesk).
  2. SPF návrh: Konsolidujte IP adresy a include mechanismy. 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žívejte jasné selektory a nastavte proces rotace. U SaaS aktivujte jejich DKIM pro vaši doménu (ne pouze výchozí 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 a opravte podpisy.
  6. Zpřísnění politiky: Postupně navyšujte pct a přejděte na quarantine, následně na reject. Sledujte doručitelnost a reputační metriky.
  7. Operativní režim: Pravidelně analyzujte rua, provádějte rotaci DKIM klíčů, revidujte SPF po změnách dodavatelů.

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

  • Přeposílání (forwarding) a mailing listy: SPF často selhává, protože se změní IP adresa; DKIM může selhat kvůli úpravám obsahu. Řešení: klást důraz na DKIM, nasadit a respektovat ARC (Authenticated Received Chain) na přeposílacích bodech.
  • Překročení limitu SPF lookupů: Sloučit include, používat SPF „flattening“ s opatrností (zvýšená 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 sdílenou), 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 pouze na adresy s autorizačním záznamem ruf/rua (URI s mailto: a povolenou doménou).

ARC – Authenticated Received Chain

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

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

Brand Indicators for Message Identification umožňují zobrazovat u ověřených e-mailů logo značky. Technicky BIMI vyžaduje alespoň DMARC v režimu quarantine nebo reject a publikovanou SVG ikonu a volitelně ověřovací certifikát VMC. Nejedná se o bezpečnostní kontrolu samotnou, ale zvyšuje důvěryhodnost a konzistenci značky.

Doplňkové standardy transportní bezpečnosti

  • MTA-STS: Politika v DNS a na HTTPS, která určuje, že příjemce požaduje TLS pro SMTP a jaké jméno certifikátu přijímá. 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 je implementován 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ě kontrolujte propagaci, syntaktickou správnost a počet lookupů u SPF.
  • Ověření podpisů: Posílejte testovací zprávy na externí schránky a kontrolujte hlavičky Authentication-Results (spf=pass/fail, dkim=pass/fail, dmarc=pass/fail, alignment).
  • Analýza reportů: Automatizujte zpracování rua (nástroje/skripty), sledujte nové zdroje, podvržené kampaně a trendy doručitelnosti.
  • Rotace klíčů: Plánujte pravidelně (např. 6–12 měsíců), zavádějte více selektorů a grace periodu 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ů: Používejte 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 pouze 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řísněte p=, revokujte nebo rotujte DKIM selektory a informujte 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