Jak číst souhrnný report DMARC (rua) a co s ním dělat

Souhrnný report DMARC (aggregate report) je denní přehled, který velcí poskytovatelé e-mailových schránek posílají na adresu uvedenou v tagu rua vašeho záznamu DMARC. Uvádí každou IP adresu, která odeslala poštu s vaší doménou v poli Od (From), kolik zpráv z ní odešlo a zda SPF a DKIM prošly a byly zarovnané (aligned) s vaší doménou. Neobsahuje obsah zpráv, předměty ani adresy příjemců.

Právě z těchto reportů zjistíte, kdo za vás skutečně odesílá: vaše vlastní poštovní servery, CRM, fakturační nástroj, platforma pro newslettery a kdokoli další, kdo vaši doménu jednoduše vloží do pole Od. Tento seznam potřebujete dřív, než politiku přepnete z p=none na vynucování.

Od května 2026 formát definuje RFC 9990, které spolu s RFC 9989 (samotný mechanismus DMARC) nahradilo starší RFC 7489. Pokud si potřebujete osvěžit 3 záznamy, začněte článkem SPF, DKIM a DMARC srozumitelně.

Jak se k vám reporty dostanou

Reporty si vyžádáte tagem rua ve svém záznamu DMARC:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Každý zapojený poskytovatel vám pak e-mailem pošle soubor XML, obvykle komprimovaný. RFC 9990 uvádí, že XML by mělo být komprimované pomocí GZIP s příponou .xml.gz, a název souboru má pevný formát:

mail.receiver.example!example.com!1013662812!1013749130.xml.gz

Jde o organizaci, která report posílá, vaši doménu a začátek a konec období jako časová razítka Unix. Období reportu obvykle pokrývá 1 den v UTC.

Pokud mají reporty chodit do schránky na jiné doméně (například do služby pro zpracování reportů na reports.example.net), musí tato doména potvrdit, že je přijímá. Příjemci hledají záznam TXT, například example.com._report._dmarc.reports.example.net, obsahující v=DMARC1, a pokud chybí, adresu rua ignorují. Chybějící potvrzovací záznam je častým důvodem, proč reporty vůbec nepřicházejí.

Struktura jednoho reportu

Každý report má stejné 3 části. Zde je zkrácený příklad podle vzoru v RFC 9990:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <report_metadata>
    <org_name>Sample Reporter</org_name>
    <date_range><begin>302832000</begin><end>302918399</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>quarantine</p>
    <testing>n</testing>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.123</source_ip>
      <count>123</count>
      <policy_evaluated>
        <disposition>pass</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>example.com</envelope_from>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><result>pass</result><selector>abc123</selector></dkim>
      <spf><domain>example.com</domain><result>fail</result></spf>
    </auth_results>
  </record>
</feedback>

• report_metadata: kdo report poslal a jaké období pokrývá.
• policy_published: záznam DMARC, který příjemce viděl. Porovnejte ho s tím, co si myslíte, že máte zveřejněno.
• record: 1 blok pro každou kombinaci odesílající IP adresy a výsledků. Doména s velkým provozem jich dostane mnoho.

Čtení záznamu pole po poli

source_ip a count. Server, který se připojil k příjemci, a počet zpráv, které v daném období doručil. Tady odesílatele identifikujete: reverzní DNS dotaz (dig -x 192.0.2.123 +short) nebo vlastník IP adresy často prozradí, zda patří vašemu poskytovateli pošty, vašemu CRM, nebo někomu neznámému.

policy_evaluated. Verdikt DMARC. Hodnoty dkim a spf zde nejsou surové výsledky, ale výsledky zarovnání: zda kontrola prošla pro doménu, která odpovídá vaší doméně v poli Od. DMARC projde, pokud je alespoň jedna z nich pass. disposition ukazuje, co příjemce udělal: none, pass, quarantine nebo reject. Pokud se liší od vaší politiky, prvek reason vysvětlí proč, například kvůli přeposílání nebo výjimce pro e-mailovou konferenci.

identifiers. header_from je doména, kterou viděli vaši příjemci. envelope_from je doména, kterou použila kontrola SPF, a často jde o subdoménu vaší odesílací služby, nikoli o vaši doménu.

auth_results. Surové výsledky SPF a DKIM spolu s doménami, pro které se kontrolovaly. RFC 9990 nově vyžaduje selektor DKIM, díky čemuž poznáte, která služba zprávu podepsala.

V příkladu výše DKIM prošlo a bylo zarovnané, SPF selhalo a zpráva přesto DMARC prošla. To je typický obraz služby, která podepisuje vaší doménou, ale odesílá z vlastní obálkové domény.

Rozdělení odesílatelů do 3 skupin

Po několika týdnech reportů zapadne každá zdrojová IP adresa do jedné z těchto skupin:

1. Známé a procházející. Váš poskytovatel pošty a správně nastavené služby. Není co řešit.
2. Známé, ale selhávající. Legitimní nástroj (helpdesk, fakturace, newsletter), který odesílá bez zarovnaného DKIM nebo chybí v SPF. Zapněte v tomto nástroji DKIM s vaší doménou, nebo ho přidejte do SPF a hlídejte přitom limit 10 DNS dotazů.
3. Neznámé a selhávající. Servery, které nedokážete přiřadit k ničemu, co používáte. Některé jsou přeposílací služby a e-mailové konference, jiné patří někomu, kdo vkládá vaši doménu do pole Od. Přesně takové zprávy by zastavila politika p=quarantine nebo p=reject, a jde o stejný druh pošty, jaký se používá při podvodech s falešnými fakturami.

Před vynucováním je rozhodující skupina 2. Pokud přepnete na p=quarantine ve chvíli, kdy legitimní nástroj stále selhává, jeho pošta skončí ve spamu.

Praktické tipy

• Používejte vyhrazenou schránku nebo nástroj na zpracování reportů. Surové XML od několika poskytovatelů každý den se ručně čte těžko.
• Sledujte hodnotu testing. RFC 9989 nahradilo starý tag pct tagem testovacího režimu t; t=y žádá příjemce, aby použili mírnější opatření, než předepisuje vaše politika.
• Dívejte se na objem, nejen na selhání. Náhle se objevivší nový zdroj s vysokou hodnotou count si zaslouží pozornost, i když kontrolou prochází.
• Uchovávejte reporty několik měsíců, abyste mohli porovnat stav před změnou a po ní.
• Pamatujte, že poskytovatelé schránek od hromadných odesílatelů stále častěji očekávají DMARC, jak popisujeme v článku Požadavky Gmailu a Yahoo na odesílatele.

Krátký kontrolní seznam

• Záznam DMARC s adresou rua, kterou někdo skutečně čte.
• Externí cíle reportů potvrzené záznamem _report._dmarc.
• Každá zdrojová IP adresa přiřazená ke službě, kterou znáte.
• Zarovnané DKIM zapnuté pro každého legitimního odesílatele.
• Neznámé selhávající zdroje prověřené, potom politika přepnutá na p=quarantine a později na p=reject.

Kde pomáhá Guarding

Reporty DMARC ukazují, co viděli příjemci. My každý den zvenčí hlídáme druhou stranu: vaše záznamy SPF, DKIM a DMARC, podobně vypadající domény a zbytek vaší vnější expozice. Když je záznam oslaben nebo selektor zmizí, posoudí to člověk a vy dostanete přesnou změnu, kterou je potřeba udělat, jak popisujeme v části co se stane, když něco najdeme. Jak to vypadá, uvidíte na ukázkovém dashboardu.