Jak číst a interpretovat DMARC reporty

Co jsou DMARC reporty

DMARC reporty jsou automatické zprávy, které přijímající mailové servery (Gmail, Outlook, Yahoo a další) zasílají vlastníkovi domény. Obsahují data o tom, kdo odesílá e-maily z vaší domény a zda procházejí autentizací přes SPF a DKIM.

Reporty dostáváte na adresu uvedenou v tagu rua= vašeho DMARC záznamu. Pokud DMARC záznam ještě nemáte, začněte článkem Jak nastavit DMARC záznam.

Existují dva typy reportů:

• Agregované reporty (RUA) — denní souhrnné přehledy ve formátu XML. Posílá je většina velkých poskytovatelů. Obsahují statistiky, ne obsah e-mailů.
• Forensní reporty (RUF) — detailní hlášení o jednotlivých selháních. V praxi je posílá jen zlomek poskytovatelů (Gmail ani Outlook je neposílají) kvůli ochraně soukromí příjemců.

Tento článek se zaměřuje na agregované reporty — ty jsou hlavním zdrojem informací pro správu e-mailové autentizace.

Jak agregovaný report vypadá

Agregované reporty přicházejí jako komprimované XML soubory (.xml.gz nebo .zip). Název souboru obsahuje identifikaci odesílatele, vaši doménu a časové období:

google.com!firma.cz!1713744000!1713830400.xml.gz

Po rozbalení najdete XML dokument se třemi hlavními sekcemi:

Metadata reportu

<report_metadata>
  <org_name>google.com</org_name>
  <email>noreply-dmarc-support@google.com</email>
  <report_id>12345678901234567890</report_id>
  <date_range>
    <begin>1713744000</begin>
    <end>1713830400</end>
  </date_range>
</report_metadata>

Identifikace odesílatele reportu a časové období (Unix timestamp). V tomto příkladu report pokrývá 24 hodin z domény google.com.

Publikovaná politika

<policy_published>
  <domain>firma.cz</domain>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <p>none</p>
  <sp>none</sp>
  <pct>100</pct>
</policy_published>

Jakou DMARC politiku přijímající server na vaší doméně nalezl:

Záznamy (records)

Jádro reportu. Každý <record> seskupuje e-maily ze stejné zdrojové IP se stejným výsledkem autentizace:

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>1523</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>firma.cz</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>firma.cz</domain>
      <result>pass</result>
      <selector>google</selector>
    </dkim>
    <spf>
      <domain>firma.cz</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Toto je nejdůležitější část. Rozeberme jednotlivé elementy.

Jak číst jednotlivé záznamy

source_ip a count

IP adresa serveru, který e-maily odeslal, a počet zpráv za sledované období. Reverzním DNS lookupem (přes DNS lookup) zjistíte, komu IP patří. Adresa 209.85.220.41 patří Googlu — to je legitimní odesílatel, pokud používáte Google Workspace.

policy_evaluated

Co přijímající server s e-maily udělal:

Pozor — dkim a spf v policy_evaluated reflektují alignment, ne jen samotnou autentizaci. E-mail může projít SPF kontrolou (server je v SPF záznamu), ale selhat v alignmentu (doména z envelope senderu neodpovídá doméně v hlavičce From).

auth_results

Surové výsledky autentizace bez ohledu na alignment:

<auth_results>
  <dkim>
    <domain>firma.cz</domain>
    <result>pass</result>
    <selector>google</selector>
  </dkim>
  <spf>
    <domain>firma.cz</domain>
    <result>pass</result>
  </spf>
</auth_results>

Porovnáním auth_results a policy_evaluated zjistíte, zda problém je v samotné autentizaci nebo v alignmentu. Pokud auth_results ukazuje pass, ale policy_evaluated ukazuje fail, máte problém s alignmentem — doména v SPF/DKIM neodpovídá doméně v hlavičce From.

Typické scénáře v reportech

Legitimní odesílatel — vše v pořádku

<row>
  <source_ip>209.85.220.41</source_ip>
  <count>842</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>
    <spf>pass</spf>
  </policy_evaluated>
</row>

DKIM i SPF prošly včetně alignmentu. E-maily jsou doručeny. Toto je cílový stav pro každého legitimního odesílatele.

Legitimní odesílatel — chybí v konfiguraci

<row>
  <source_ip>198.2.135.10</source_ip>
  <count>47</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>
<auth_results>
  <spf>
    <domain>sendgrid.net</domain>
    <result>pass</result>
  </spf>
</auth_results>

SPF prošlo pro doménu sendgrid.net, ale selhal alignment — e-mail tvrdí, že je z firma.cz, ale SPF ověřil sendgrid.net. Řešení: nakonfigurujte SendGrid pro DKIM podepisování vaší doménou a přidejte include:sendgrid.net do SPF záznamu.

Spoofing — podvržený e-mail

<row>
  <source_ip>45.33.18.92</source_ip>
  <count>3</count>
  <policy_evaluated>
    <disposition>reject</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>
<auth_results>
  <spf>
    <domain>unknown-domain.ru</domain>
    <result>pass</result>
  </spf>
</auth_results>

Neznámá IP, selhání obou kontrol, cizí doména v SPF. Toto je spoofing — někdo se pokouší posílat e-maily za vaši doménu. S politikou p=reject jsou tyto e-maily odmítnuty.

Přeposílání — legitimní selhání

<row>
  <source_ip>72.14.199.25</source_ip>
  <count>12</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>

SPF selhalo (přeposílající server není ve vašem SPF záznamu), ale DKIM prošlo — podpis zůstává platný i po přeposlání. DMARC vyžaduje úspěch alespoň jednoho mechanismu, takže e-mail prošel. Toto je běžné u přeposílaných e-mailů a není potřeba řešit, pokud máte funkční DKIM.

Postup analýzy reportů

Při vyhodnocování reportů postupujte systematicky:

1. Identifikujte všechny zdrojové IP adresy — pomocí reverzního DNS nebo DNS lookupu zjistěte, komu patří. Porovnejte se seznamem služeb, které používáte k odesílání e-mailů.

2. Zkontrolujte disposition — pokud vidíte quarantine nebo reject u legitimního odesílatele, máte problém v konfiguraci, který je třeba urychleně řešit.

3. Rozlište autentizaci od alignmentu — porovnejte auth_results s policy_evaluated. Pokud autentizace prošla, ale DMARC selhal, opravte alignment (většinou stačí nakonfigurovat DKIM podepisování vaší doménou u třetích stran).

4. Ignorujte spoofing (s enforce politikou) — záznamy s disposition: reject od neznámých IP jsou důkaz, že DMARC funguje. S politikou p=reject jsou podvržené e-maily blokovány.

5. Sledujte trendy — jednorázový report nestačí. Sledujte vývoj v čase: přibývají nová selhání? Objevily se nové zdrojové IP?

Proč nečíst reporty ručně

Agregované reporty v surovém XML jsou nepřehledné. Doména s aktivním e-mailovým provozem může dostávat desítky reportů denně od různých poskytovatelů. Ruční parsování XML souborů je:

• Časově náročné — rozbalování, čtení XML, hledání problémů v tisících záznamů
• Náchylné k chybám — snadno přehlédnete problematický záznam
• Bez kontextu — jeden report ukazuje jen výřez, potřebujete agregovaný pohled přes čas a přes poskytovatele

SPF Monitor reporty automaticky zpracuje, vizualizuje a upozorní vás na problémy. Stačí nasměrovat rua= adresu na firma.cz@rua.spfmonitor.com a data se začnou sbírat. Nemusíte řešit XML, komprimované soubory ani ruční agregaci.

Forensní reporty (RUF)

Forensní reporty obsahují detail o jednotlivých e-mailech, které selhaly v DMARC ověření — včetně hlaviček a někdy i částí těla zprávy. Konfigurují se tagem ruf= v DMARC záznamu:

v=DMARC1; p=reject; rua=mailto:firma.cz@rua.spfmonitor.com; ruf=mailto:firma.cz@ruf.spfmonitor.com; fo=1

Tag fo= (failure options) určuje, kdy se forensní report odešle:

Praktický přínos RUF reportů je omezený — většina velkých poskytovatelů (Gmail, Microsoft, Yahoo) je neposílá z důvodu ochrany soukromí příjemců. Pokud je ale dostáváte, slouží k rychlé diagnostice konkrétních selhání.

Kontrolní seznam

Po nastavení DMARC reportingu ověřte:

• DMARC záznam obsahuje tag rua= s platnou adresou
• Po 24–72 hodinách přicházejí první reporty
• Identifikovali jste všechny legitimní odesílatele v reportech
• Legitimní odesílatelé mají dkim: pass a spf: pass v policy_evaluated
• Odesílatelé třetích stran mají nakonfigurovaný DKIM pro vaši doménu
• Záznamy se selháním od neznámých IP jsou spoofing (ověřte reverzním DNS)
• Teprve po vyřešení všech legitimních selhání zpřísníte politiku na quarantine a poté reject

Zkontrolujte svůj DMARC záznam a ověřte, že je reportování správně nakonfigurováno.