Reporty DMARC a nasazení politiky: od p=none po reject

Nasazení DMARC jsou tři politiky a důkazy mezi nimi. Publikuješ p=none s adresou rua, dva až čtyři týdny sbíráš denní agregované reporty od velkých příjemců, opravíš každého legitimního odesílatele, který neprojde alignmentem, a pak přejdeš na p=quarantine a nakonec p=reject, přičemž v každém kroku čteš reporty. Reporty jsou podstatou celé věci. Jsou jediným pohledem na to, kdo po internetu posílá poštu s tvou doménou v řádku From: - tvoje vlastní servery, služby, na které jsi zapomněl, přeposílače i lidé, kteří se za tebe vydávají. Skok rovnou na p=reject bez čtení reportů je způsob, jakým organizace zjišťují, že jejich fakturační systém nikdy nebyl autentizovaný, a to v den, kdy zákazníkům přestanou chodit faktury.

Tento článek předpokládá, že víš, co jsou SPF, DKIM a DMARC - pokud ne, začni článkem SPF, DKIM a DMARC vysvětleno. Tady se zaměřujeme na reporty a postup nasazení.

Záznam tag po tagu, pro nasazení#

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

Tagy, na kterých při nasazování záleží:

fo=1 žádá o reporty o selhání, když selže kterýkoli mechanismus, a ne jen když selžou všechny. Ovlivňuje jen reporty ruf, které většina velkých příjemců z důvodu soukromí neposílá, takže to nevadí a občas to pomůže.

ri je jen požadavek. Příjemci posílají denně bez ohledu na něj, tak ho vynech.

Co obsahuje agregovaný report#

Agregované reporty chodí jako přílohy e-mailu - XML zabalené gzipem nebo zipem, jeden od každého příjemce za den, odesílá je třeba Google, Microsoft, Yahoo a mnoho menších poskytovatelů. Každý popisuje poštu, kterou tento příjemce viděl a která se hlásila k tvé doméně, seskupenou podle IP odesílatele a výsledku. Zkráceno na to podstatné:

<feedback>  <report_metadata>    <org_name>google.com</org_name>    <date_range><begin>1791331200</begin><end>1791417599</end></date_range>  </report_metadata>  <policy_published>    <domain>example.com</domain><p>none</p><adkim>r</adkim><aspf>r</aspf>  </policy_published>  <record>    <row>      <source_ip>203.0.113.25</source_ip>      <count>412</count>      <policy_evaluated>        <disposition>none</disposition><dkim>pass</dkim><spf>pass</spf>      </policy_evaluated>    </row>    <identifiers><header_from>example.com</header_from></identifiers>    <auth_results>      <dkim><domain>example.com</domain><selector>s2026a</selector><result>pass</result></dkim>      <spf><domain>example.com</domain><result>pass</result></spf>    </auth_results>  </record></feedback>

Každý record čti jako větu: „Z IP 203.0.113.25 přišlo 412 zpráv s From: example.com; DKIM prošel se shodnou doménou, SPF prošel se shodnou doménou; protože politika je none, nic jsme s nimi neudělali.“ Blok policy_evaluated udává vyhodnocené verdikty DMARC včetně alignmentu. Blok auth_results udává surové výsledky SPF a DKIM s doménou, pro kterou platily - podle toho poznáš, že SPF prošel, ale pro bounces.provider.example, což není aligned.

Po prvním týdnu je nikdo nečte očima. Pošli je parseru: parsedmarc je široce používaný open-source nástroj, který z reportů udělá prohledávatelný dashboard, a mnoho komerčních služeb dělá totéž s menším nastavováním. Některé poštovní servery zpracovávají příchozí reporty samy - nedávné verze Stalwartu umějí analyzovat reporty DMARC doručené na tebou nastavené adresy a zobrazit je ve webové administraci - což pro malou doménu stačí.

Pro reporty používej vyhrazenou adresu. Vytížená doména jich dostane desítky denně a nikdo je nechce mít ve své schránce.

Třídění odesílatelů, které najdeš#

Po dvou týdnech reportů budeš mít seznam zdrojových IP. Každá spadá do jedné ze čtyř skupin a každá vyžaduje jinou akci.

1. Tvoje vlastní infrastruktura, aligned. Tvůj poštovní server, který prochází DKIM s tvou doménou. Není co dělat.
2. Legitimní služby, nealigned. Platforma pro newslettery, CRM, helpdesk, fakturační systém, nástroj pro nábor - posílají jako tvoje doména, ale SPF a DKIM procházejí jen pro jejich vlastní domény, nebo vůbec. To je skutečná práce. Poskytovatele zjisti z reverzního DNS adresy nebo z vyhledání IP a pak v jeho nastavení zapni DKIM s tvou doménou a tam, kde to nabízí, vlastní doménu pro return-path.
3. Přeposílače. Univerzitní aliasy, staré adresy přeposílající na Gmail, konference. SPF selže, protože IP přeposílače není tvoje; DKIM často pořád projde, pokud zpráva nebyla změněna. Tohle opravit nemůžeš, a když DKIM prochází, ani nemusíš.
4. Podvodníci. IP bez jakékoli vazby na tebe, které neprojdou ničím, často ze zemí, odkud neodesíláš. Přesně kvůli nim existuje vynucování DMARC. Poznamenej si je a jdi dál.

Při určování priorit pomáhá objem. Legitimní služba, která měsíčně pošle 3 000 zpráv nealigned, je důležitá; přeposílač, který přepošle šest zpráv, ne.

Odesílatele, který se objeví jen jednou za měsíc - výplaty, čtvrtletní výpisy, roční upomínka o obnovení - je ve dvoutýdenním okně snadné přehlédnout. Než půjdeš dál, zeptej se kolem sebe: finance, personalistika, marketing i ten, kdo spravuje formuláře na webu, znají odesílatele, o kterých IT nikdy neslyšelo.

Jak zjistit, komu patří neznámá IP

IP adresa v reportu je k užitku, až když víš, komu patří. Obvykle to vyřeší tři rychlé kontroly:

# Reverse DNS often names the provider outright$ dig +short -x 198.51.100.77# Who holds the address block$ whois 198.51.100.77 | grep -iE 'orgname|org-name|netname|descr'

Pak se podívej na domain a selector DKIM ve stejném řádku reportu: podpis d=sendgrid.net nebo selektor jako pm ti řekne službu, i když z IP nepoznáš nic. Pokud IP patří velkému cloudovému poskytovateli a žádný podpis službu nejmenuje, zeptej se kolegů, co tam běží, dřív než předpokládáš nepřátelský původ.

Praktický příklad: odesílatelé, které nikdo nezapsal#

Malá firma s vlastním poštovním serverem publikuje p=none a rua nasměruje na schránku pro reporty. Po třech týdnech ukazují zpracované reporty pět zdrojů, které odesílají jako example.com:

1. Jejich vlastní poštovní server, 6 200 zpráv, DKIM i SPF aligned. V pořádku.
2. Helpdeskový systém, 900 zpráv, SPF prochází pro bounce doménu platformy, DKIM podepsaný vlastní doménou platformy. Ani jedno není aligned - každá odpověď na tiket by se při p=reject odmítla.
3. Účetní program, 140 zpráv, všechny v posledních dvou dnech měsíce, žádný DKIM, SPF selhává. Nikdo z IT nevěděl, že posílá poštu; finance ho nastavily, aby odesílal faktury jako accounts@example.com.
4. Univerzitní přeposílací adresa jednoho zaměstnance, 30 zpráv, SPF selhává, DKIM prochází. Není co dělat.
5. Dvanáct IP ve třech zemích, 2 000 zpráv, neprojde nic. Podvod.

Opravy zaberou odpoledne. Helpdesk nabízí DKIM s vlastní doménou: dva záznamy CNAME, kliknutí na ověření a jeho podpisy nově nesou d=example.com. Účetní program podepisovat neumí, ale umí odesílat přes SMTP server, takže ho finance nasměrují na submission port firemního poštovního serveru s vyhrazeným účtem a faktury teď podepisuje Stalwart jako všechno ostatní.

O týden později ukazují reporty zdroje 1 až 3 jako aligned. Firma přejde na p=quarantine a po měsíci na p=reject. Podvodné zprávy ze skupiny 5 se v reportech dál objevují - teď s dispozicí reject u každé zprávy. Ta poslední řádka je celá návratnost celého úsilí.

Alignment přesně#

DMARC projde, pokud projde SPF nebo DKIM a doména, pro kterou prošel, je aligned s doménou v From:.

• DKIM je aligned, když doména d= v podpisu odpovídá doméně v From:.
• SPF je aligned, když doména obálkového odesílatele (MAIL FROM, zobrazený jako Return-Path) odpovídá doméně v From:.

V uvolněném režimu (r, výchozí) „odpovídá“ znamená stejnou organizační doménu: mail.example.com je aligned s example.com a obě jsou aligned s news.example.com. Organizační doména se určuje podle Public Suffix List, a proto example.co.uk funguje správně, zatímco co.uk se nikdy nepovažuje za jednu organizaci. Ve striktním režimu (s) musí být domény totožné.

Nech obojí uvolněné. Striktní alignment rozbíjí vlastní subdomény return-path, díky kterým je SPF aligned u odesílatelů třetích stran, a pro většinu domén nepřináší nic podstatného.

Nasazení krok za krokem#

1. Publikuj `p=none` s `rua`. Počkej dva až čtyři týdny. Pokud vaše organizace posílá faktury, zahrň alespoň jeden konec měsíce.
2. Oprav každého legitimního nealigned odesílatele, kterého reporty ukážou. Týden po každé opravě reporty zkontroluj, jestli se změna projevila.
3. Přejdi na `p=quarantine`. Pokud máš obavy, použij pct pro postupné zavedení: pct=25 pošle čtvrtinu selhávající pošty do spamu a se zbytkem naloží jako s none. Po týdnu nebo dvou bez stížností zvyš na pct=100.
4. Zůstaň na `quarantine` aspoň dva týdny, během nichž nic legitimního neselhává.
5. Přejdi na `p=reject`. Selhávající pošta se teď odmítá už během SMTP konverzace, takže chybně nastavený odesílatel dostane bounce místo tichého přistání ve spamu - což je pro diagnostiku lepší než quarantine.
6. Adresu `rua` si nech. Přibývají nové služby, někdo změní poskytovatele, rotace klíčů se pokazí. Reporty jsou způsob, jak to zjistíš do dne místo za měsíc.

Tag pct se vždy dodržoval nejednotně - někteří příjemci efektivně považují cokoli pod 100 za „nevynucováno“. Revize specifikace DMARC (často zvaná DMARCbis) od něj upouští ve prospěch jednoduššího testovacího příznaku. Použij pct klidně jako mírné rozjezdové zavádění, ale nespoléhej na něj při jemném řízení.

O subdoménách stojí za to přemýšlet před krokem 5. sp= nastavuje politiku pro subdomény, výchozí je p samotné domény. Pokud odesíláš ze subdomén jako news.example.com, zkontroluj je v reportech také. Pokud ze subdomén nikdy neodesíláš, sp=reject od začátku vypne oblíbený trik podvodníků za minimální riziko.

Co se rozbije při p=reject#

Tři druhy pošty mohou i po pečlivém nasazení stále selhat a měl bys o nich vědět dřív, než začneš vynucovat.

• Konference, které zprávy upravují. Konference, která přidá předponu předmětu nebo patičku, rozbije DKIM a IP serveru konference neprojde SPF pro tvou doménu. Většina moderního software pro konference DMARC obchází přepsáním From: na vlastní adresu konference u autorů z domén s p=reject a ARC (Authenticated Received Chain) umožňuje konferencím předat původní verdikt příjemcům, kteří jim důvěřují. Starší konference mohou příspěvky tvých členů stále vracet.
• Přeposílání, které zprávy upravuje. Prosté přeposílání obvykle díky DKIM přežije. Přeposílání přes bezpečnostní bránu, která přepisuje odkazy, ne.
• Zařízení a skripty, které odesílají přímo. Kancelářský skener, který posílá PDF e-mailem, NAS, který posílá upozornění, cron úloha na zapomenutém serveru, která mailuje report - každé z nich posílá jako tvoje doména přímo příjemci, nepodepsané. Mívají za cíl interní adresy, takže se v reportech od Googlu nebo Microsoftu nemusí nikdy objevit, a rozbíjejí se potichu. Nasměruj každé z nich na submission port vlastního poštovního serveru s vlastním účtem, aby se jejich pošta podepisovala jako všechna ostatní.

Žádná z těchto věcí není důvod zůstat navždy na p=none. Jsou důvodem číst reporty i po zapnutí vynucování a vědět, co říct kolegovi, jehož příspěvek do staré konference se vrátil.

Proč se tím zabývat: požadavky příjemců#

Od února 2024 Google a Yahoo vyžadují od každého, kdo svým uživatelům pošle více než zhruba 5 000 zpráv denně, aby publikoval záznam DMARC (alespoň p=none) a aby SPF a DKIM procházely a byly aligned. Microsoft v roce 2025 oznámil podobné požadavky pro odesílatele s vysokým objemem na adresy Outlook.com. Menší odesílatelé se posuzují mírněji, ale doména bez jakéhokoli DMARC je stále častěji považována za podezřelou. A doména s p=reject je mnohem méně atraktivní k podvržení, protože podvržená pošta se odmítá u všech velkých příjemců. Proč e-mail končí ve spamu zasazuje DMARC do kontextu všeho ostatního, co příjemci kontrolují.

DMARC s poštovním serverem RE:NODE#

V tarifu Mail Server Stalwart podepisuje odchozí poštu klíči DKIM, které jeho webová administrace generuje pro každou doménu, takže máš aligned DKIM z vlastního serveru hned první den. Samotný záznam DMARC publikuješ ty, vedle MX, SPF a DKIM, tam, kde máš hostované DNS - na naší straně žádný editor zón není. Schránka na stejném serveru je přirozeným cílem rua pro reporty. Zbytek práce - najít a opravit ostatní služby, které odesílají jako tvoje doména - je stejný, ať tvoje pošta běží kdekoli. Stranu podepisování pokrývá článek Klíče DKIM a jejich rotace.

FAQ#

Jak dlouho zůstat na p=none?

Aspoň dva týdny, lépe čtyři, a dost dlouho na to, aby se zahrnulo případné měsíční odesílání, jako jsou faktury nebo výpisy. Přejdi dál, až bude každý legitimní odesílatel v reportech aligned, ne když to řekne kalendář.

Proč mi nechodí žádné reporty DMARC?

Zkontroluj syntaxi rua (mailto: je povinné), zkontroluj, že je záznam na _dmarc.example.com, a pokud je adresa v jiné doméně, zkontroluj, že tato doména publikuje autorizační záznam. Reportům také trvá den nebo dva, než začnou chodit, a doména, která posílá málo, jich může dostávat málo.

Proč nikdy nedostávám reporty o selhání ruf?

Většina velkých příjemců je neposílá, protože mohou obsahovat obsah zpráv a osobní údaje. Dostaneš hlavně agregované reporty a ty stačí.

Je quarantine bezpečnější než reject?

Je mírnější k chybě, protože selhávající pošta jde do spamu místo toho, aby se vracela. Ale chybně nastaveného odesílatele je při quarantine těžší si všimnout, protože nikdo nedostane bounce. Quarantine ber jako etapu, ne jako cíl.

Potřebuju DMARC i na doménách, které nikdy neposílají poštu?

Ano, a jdi rovnou na p=reject s v=spf1 -all a nulovým MX. Není tam nic legitimního, co by šlo rozbít, a zaparkované domény jsou oblíbeným cílem podvržení.