Bezpečnosť e-mailu: Ako zaviesť SPF, DKIM a DMARC

01Určite, pred čím má autentizácia chrániť

Zobrazené meno odosielateľa, adresa a skutočný spôsob odoslania sú odlišné veci. Útočník môže napísať meno vášho riaditeľa alebo skúsiť použiť firemnú doménu v adrese From. Autentizácia pomáha prijímajúcemu systému posúdiť doménu spojenú so správou. Nedokazuje, že konkrétny človek schválil faktúru, ani že je obsah správy pravdivý.

DMARC neodstráni podvody z podobne vyzerajúcich domén. Ak si niekto zaregistruje inú adresu a správne ju autentizuje, jeho správa môže technickou kontrolou prejsť. Rovnako môže prejsť správa odoslaná z napadnutého skutočného účtu. Overovanie zmien bankových údajov a ochranu prihlasovania preto zachovajte aj po zavedení všetkých troch mechanizmov.

Praktický cieľ zapíšte presne: obmedziť neoprávnené používanie vlastnej domény, objaviť neznáme odosielacie služby a udržať prehľad o doručovaní legitímnej pošty. Úspešný DMARC nie je certifikát bezpečnosti celej firmy. Ochranu účtov riešte súbežne, napríklad podľa nášho sprievodcu zavedením MFA a passkeys.

02Spíšte všetky systémy, ktoré posielajú vo vašom mene

Začnite inventúrou, nie prísnejšou politikou. Poštu často neposiela iba Microsoft 365 alebo Google Workspace. Odosiela aj e-shop, CRM, fakturačný nástroj, helpdesk, formulár na webe a marketingová platforma. Zabudnutá služba môže fungovať iba pri mesačnej uzávierke. Týždeň bez chýb preto nemusí pokrývať bežnú prevádzku.

Pri každej položke určite, kto ju smie zmeniť a kto rozhodne o vypnutí. Oddeľte produkciu od testovacieho prostredia. Neznámu IP adresu z reportu nepovoľujte iba preto, aby zmizla červená kontrolka. Najprv ju spojte s konkrétnou službou a jej vlastníkom. Návrh jednotlivých tokov dopĺňa článok o notifikáciách a e-mailoch v aplikácii.

03Rozlišujte obálku, viditeľnú adresu a podpis

Adresa vo viditeľnej hlavičke From, technicky RFC5322.From, je to, čo poštový klient zvyčajne ukazuje ako odosielateľa. SMTP obálka používa inú adresu, MAIL FROM alebo RFC5321.MailFrom, spojenú okrem iného s vracaním nedoručenej pošty. Domény môžu byť oprávnene rôzne, napríklad keď newsletter posiela externá platforma.

SPF bežne overuje odosielajúci server voči doméne z MAIL FROM, nie priamo voči viditeľnej adrese. DKIM používa doménu uvedenú v položke d= svojho podpisu. DMARC tieto overené identity porovnáva s doménou From. Táto zhoda sa nazýva alignment. Nestačí teda zistiť, že nejaké SPF alebo nejaký podpis uspel.

Pri prevzatí administrácie žiadajte ukážku skutočnej doručenej správy s vysvetlením všetkých troch domén. Overenie iba v administrácii poskytovateľa nedokazuje, čo odosiela vaša aplikácia. Aj Reply-To je samostatný údaj na odpoveď, nie identita, podľa ktorej DMARC overuje From. Rozdiel medzi adresami opisuje dokumentácia Microsoftu.

04SPF určuje povolené zdroje, nie dôveryhodnosť obsahu

SPF vyjadruje, ktoré servery smú používať určitú doménu pri odosielaní. Príjemca porovnáva pripojenú IP adresu s publikovanými pravidlami. Záznam patrí k overovanej doméne; samotné pridanie pravidla na hlavnú firemnú doménu nemusí napraviť odosielanie s inou obálkovou adresou.

Podľa RFC 7208 nesmie pre jednu doménu vzniknúť viac samostatných SPF záznamov vybraných pri rovnakej kontrole. Ďalší dodávateľ preto zvyčajne znamená úpravu existujúceho pravidla, nie pridanie druhého konkurenčného SPF. Zároveň existuje limit desiatich vyhodnotení určených typov pravidiel s DNS dotazmi, napríklad include. Počítajú sa aj vnorené pravidlá; nejde jednoducho o počet riadkov v administrácii.

Prekročenie tohto limitu vedie k chybe, nie k úspešnému overeniu. Správca má preveriť celú závislosť od dodávateľov, odstrániť nepoužívané oprávnenia a vyhnúť sa zbytočne širokým rozsahom. Ani bezhlavé nahradenie odkazov pevnými IP adresami nie je trvalé riešenie: poskytovateľ ich môže zmeniť. Po zmene kontrolujte skutočný výsledok a doručovanie, nie iba syntaktickú platnosť.

05DKIM podpisuje správu za konkrétnu doménu

Odosielajúci systém pripojí kryptografický podpis. Príjemca získa verejný kľúč z DNS a overí podpísané časti správy. Súkromný kľúč zostáva v systéme, ktorý podpisuje. DKIM tým spája správu s podpisujúcou doménou a umožňuje rozpoznať zmenu chráneného obsahu. Nie je to osobný elektronický podpis zamestnanca.

RFC 6376 oddeľuje podpis od šifrovania. DKIM nezaisťuje utajenie prílohy a nepreveruje, či odkaz vedie na bezpečný web. Potrebujete aj vhodnú ochranu prenosu, účtov a obsahu. Pri preposielaní môže podpis prežiť, ak sa podpísané časti nezmenia; vložená pätička alebo zmena predmetu ho naopak môže porušiť.

Pri externej službe overte podpis vlastnou doménou, nie iba doménou poskytovateľa. Zapíšte selektor, vlastníka kľúča a postup výmeny. Pri rotácii najprv pripravte nový kľúč a overte nové podpisovanie. Starý verejný kľúč neodstraňujte skôr, než s dodávateľom zohľadníte správy ešte čakajúce na odoslanie. Zmena musí mať dôkaz úspešného doručenia.

06DMARC vyžaduje aspoň jednu úspešnú zhodnú identitu

Pravidlo podľa špecifikácie DMARC je jednoduché: na výsledok DMARC pass stačí úspešné SPF so zhodou domény alebo platný DKIM podpis so zhodou domény. Oboje je užitočné prevádzkovo a môže byť súčasťou požiadaviek poskytovateľa, ale samotný výpočet DMARC nevyžaduje úspech oboch metód súčasne.

Pri strict alignment sa domény musia zhodovať presne. Relaxed alignment pracuje s rovnakou organizačnou doménou. V modelovom príklade From pri example.org a platný podpis d=example.org vyhovujú aj strict režimu. Pri subdoménach nepredpokladajte zhodu iba podľa podobného názvu. Správca má overiť spôsob určenia organizačnej domény aj politiku celej hierarchie.

07Politika je požiadavka príjemcovi, nie príkaz celému internetu

DMARC politika p=none žiada sledovanie bez osobitného zásahu pre výsledok DMARC. Neznamená automatické doručenie: spamový filter môže správu odmietnuť z iného dôvodu. Politika p=quarantine žiada zaobchádzanie s neúspešnou správou ako s podozrivou, napríklad zaradenie do spamu. Politika p=reject žiada odmietnutie.

Konečné rozhodnutie zostáva na prijímajúcom systéme a jeho ďalších informáciách. Nezamieňajte preto DMARC fail s istým odmietnutím ani pass s garantovaným doručením. Prehľad pre vedenie má oddeliť výsledok autentizácie od skutočného zaobchádzania so správou. Práve rozdiel medzi nimi môže upozorniť na preposielanie alebo miestnu výnimku.

Sprísnenie posudzujte pre každú používanú doménu a jej účel. Fakturačná subdoména s riadeným odosielaním má inú prevádzku než zamestnanecké adresy používané v diskusných skupinách. Preverte aj dedenie politík do subdomén. Zmena na hlavnej doméne môže ovplyvniť službu, o ktorej autor zmeny nevedel.

08Preposielanie a mailing listy preverte pred vynucovaním

Pri preposlaní sa správa dostáva k ďalšiemu príjemcovi z inej IP adresy. Pôvodné SPF potom môže zlyhať. Úprava obálky preposielajúcim systémom môže pomôcť jeho vlastnému SPF, ale nemusí vytvoriť zhodu s pôvodnou doménou From. Platný zhodný DKIM môže DMARC zachrániť, ak podpis cestou zostane platný.

Diskusná skupina alebo bezpečnostná brána môže obsah upraviť a podpis porušiť. Taká správa nemusí byť podvod. ARC podľa RFC 8617 umožňuje odovzdávať overiteľné informácie o predchádzajúcich autentizačných výsledkoch cez sprostredkovateľov. Príjemca však musí vyhodnotiť dôveryhodnosť reťazca a jeho pôvodcov. Samotná prítomnosť ARC nie je automatická priepustka.

Do testov zahrňte skutočné cesty: externé preposielanie, zdieľané aliasy, zákaznícke brány a mailing listy, ktoré zamestnanci používajú. Neriešte ich plošným vypnutím kontroly ani univerzálnym zoznamom povolených domén. Ak konkrétna cesta vyžaduje výnimku, potrebuje vlastníka, zdôvodnenie a pravidelnú revíziu. Overenie samotného priameho doručenia túto časť nenahradí.

09Reporty používajte na rozhodovanie, nie iba na archiváciu

Agregované reporty ukazujú, odkiaľ príjemca zaznamenal správy používajúce vašu doménu a ako dopadli kontroly. RFC 9990 opisuje napríklad zdrojové IP adresy, počty správ, overené identity a uplatnenú politiku. Reporty nie sú úplný zoznam všetkých odoslaných e-mailov ani potvrdenie, že ich zákazníci prečítali. Nie každý príjemca ich poskytuje.

Vhodný prehľad rozdeľuje známe oprávnené služby, oprávnené služby s chybou a neznáme zdroje. Pri chybe ukážte vlastníka a ďalší krok. Popri percente úspechu sledujte konkrétne toky: malý počet odmietnutých resetov hesla môže byť závažnejší než veľký objem neúspešných podvrhov.

Určite príjemcu reportov, prístupy a dobu uchovania. Individuálne failure reporty môžu obsahovať hlavičky alebo aj obsah správy, ako upozorňuje RFC 9991. Nezapínajte ich rozosielanie externej službe automaticky. Najprv posúďte potrebnosť, rozsah údajov a ochranu príjemcu. Na bežný prehľad začnite agregovanými výsledkami. Ich cieľovú adresu určuje tag rua. Overte, že reporty skutočne prichádzajú a nástroj ich spracúva. Pri cieli mimo vlastnej domény preverte aj potrebné oprávnenie na prijímanie reportov.

10Zavádzajte podľa prevádzkových dôkazov a aktuálneho štandardu

Pripravte inventúru, zodpovednosti a plán návratu. Overte SPF, DKIM a zhodu na reálnych správach. Potom sledujte reporty v monitorovacom režime a opravte legitímne toky s chybou. Dĺžku pozorovania odvoďte od skutočných cyklov vrátane uzávierok a sezónnych kampaní. Neexistuje univerzálny počet dní, po ktorom je každá doména pripravená.

V máji 2026 vyšiel RFC 9989, ktorý nahrádza pôvodnú špecifikáciu DMARC. Odstránil starý parameter pct a mení zisťovanie organizačnej domény pomocou DNS. Starší návod s postupom „zapnite reject pre desať percent“ preto nepovažujte za všeobecne spoľahlivý bezpečnostný mechanizmus. Nové testovacie možnosti riešte podľa podpory konkrétnych systémov.

Nový štandard výslovne varuje pred p=reject na doménach pre bežnú komunikáciu, najmä pri účasti používateľov v mailing listoch. Rozhodnutie o vynucovaní má vychádzať z doložených dopadov a charakteru domény. Prísnejšia politika nie je automaticky vhodný konečný stav pre každý typ pošty. Poskytovatelia môžu naďalej používať odlišné implementácie, preto kontrolujte skutočné výsledky.

Pri schválenej zmene určite dostupného správcu a hranicu na zastavenie. Uchovajte predchádzajúce hodnoty, počítajte s DNS cache a sledujte chyby v prijímajúcich systémoch aj vo vlastnej aplikácii. Vrátenie záznamu nevráti už odmietnuté správy. Obnovenie dôležitých podaní preto musí mať vlastný bezpečný postup.

11Oddeľte pravidlá poskytovateľa od výsledku DMARC

Google, Yahoo a Microsoft majú vlastné požiadavky na odosielateľov. Ich pravidlá pre hromadné alebo vysokoobjemové odosielanie zahŕňajú SPF, DKIM a DMARC. Podmienky sa vzťahujú na konkrétne prijímajúce služby a definície objemu, nie automaticky na každú schránku na internete.

Napríklad technický DMARC pass cez DKIM sám osebe nedokazuje splnenie všetkých požiadaviek poskytovateľa na SPF. Rovnako monitorovacia DMARC politika môže splniť minimálnu podmienku danej služby, ale sama nežiada blokovanie podvrhov. Správca musí vyhodnotiť obe otázky osobitne: či správa prešla DMARC a či spĺňa pravidlá cieľového príjemcu.

Autentizácia tiež nenahrádza súhlas príjemcov, hygienu databázy, zrozumiteľné odhlásenie a vhodný obsah. Pri marketingu kontrolujte pravidlá odhlásenia priamo u poskytovateľa. Opravený DNS záznam nevyrieši kampaň, ktorú ľudia opakovane označujú ako nevyžiadanú. Požiadavky overujte pri zmene odosielacej služby a významnom raste objemu.

12Prevezmite riešenie a prideľte mu vlastníka

Odovzdanie sa nesmie skončiť obrázkom zelených kontrol. Žiadajte doložené výsledky hlavných odosielacích ciest, zoznam výnimiek a prevádzkový kontakt. Uložte konfiguráciu a jej zdôvodnenie do dokumentácie, ktorá zostane firme pri zmene dodávateľa. Prístup k DNS a službám musí zodpovedať zodpovednosti za zmeny.

• Pri každom toku je známa služba, doména a zodpovedný človek.
• Priame aj dôležité nepriame doručenie má overený výsledok.
• Reporty niekto vyhodnocuje a odovzdáva konkrétne chyby vlastníkovi.
• Nový dodávateľ nesmie začať odosielať bez kontroly autentizácie.
• Odchod služby zahŕňa odobratie nepotrebných oprávnení a kľúčov.
• Zmena politiky má plán návratu a sledovanie odmietnutých správ.

Kontrolu opakujte pri novej platforme pre kampane, migrácii pošty, zmene aplikácie aj zmene správcu. Pravidelný prevádzkový dohľad možno spojiť s mesačnou starostlivosťou o web, ak z neho odchádzajú dôležité správy. Cieľom je udržať dokumentáciu v súlade so skutočným odosielaním, nie raz ročne potvrdiť existenciu troch záznamov.

13Časté otázky k SPF, DKIM a DMARC