Čtení DMARC reportů

Modul 4: Doručitelnost: SPF, DKIM a DMARC v praxi · Doba čtení: 12 minut

Cíl lekce: Po této lekci dokážete otevřít a přečíst souhrnný DMARC report, u každého řádku určit, o jaký zdroj jde a proč uspívá nebo selhává, a rozhodnout, co opravit, co můžete ignorovat a kdy můžete zpřísnit svou politiku.

Klíčové pojmy: souhrnný report (aggregate report, RFC 9990), rua, XML, gzip nebo zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selector, chybový report (ruf, RFC 9991), reportovací služba, soukromí

Co vám přijde

Pokud jste ve svém DMARC záznamu nastavili adresu rua (lekce 4.4), budou vám velcí příjemci jako Google, Microsoft a Yahoo posílat zhruba každý den souhrnný report. Je to e-mail s přílohou, obvykle zazipovaným XML souborem s názvem jako:

receiver.example!example.com!1793923200!1794009599.xml.gz

To znamená: od příjemce receiver.example, o Vaší doméně example.com, za období mezi dvěma časovými razítky (sekundy od roku 1970; zde 6. listopadu 2026, celý den v UTC).

Report neobsahuje obsah e-mailů, žádné předměty a obvykle ani adresy příjemců. Obsahuje za každý odesílající server počet zpráv a výsledek SPF, DKIM a DMARC. Díky tomu je to spolehlivý přehled toho, kdo jménem Vaší domény odesílá poštu, i ze zdrojů, na které jste sami zapomněli, a od podvodníků.

Struktura reportu

Report má tři části. Níže jsou nejdůležitější úryvky z ukázkového souboru k této lekci (dmarc-rapport-1.xml).

1. Kdo reportuje a za jaké období

<report_metadata>
  <org_name>receiver.example</org_name>
  <email>noreply-dmarc@receiver.example</email>
  <report_id>receiver.example-20261106-7f3c2a91</report_id>
  <date_range>
    <begin>1793923200</begin>
    <end>1794009599</end>
  </date_range>
</report_metadata>

2. Jakou politiku příjemce u Vás zjistil

<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <sp>none</sp>
  <np>none</np>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

Toto vždy zkontrolujte: pokud zde není to, co si myslíte, že máte ve svém DNS, znamená to, že příjemce četl jiný (nebo starý) záznam.

3. Pro každý zdroj: jeden záznam

Každý record se týká jedné odesílající IP adresy s jednou kombinací výsledků:

<record>
  <row>
    <source_ip>198.51.100.40</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounce.mailer.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example</domain>
      <selector>k1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Nejdůležitější rozdíl: auth_results versus policy_evaluated

Zde je jádro čtení reportu. Ve výše uvedeném příkladu je v auth_results dvakrát uvedeno pass: DKIM uspělo pro mailer.example a SPF uspělo pro bounce.mailer.example. Přesto je v policy_evaluated dvakrát uvedeno fail. Není to rozpor: policy_evaluated počítá pouze úspěšnou kontrolu, která je v souladu (aligned) s header_from. Ani jedna z obou domén nepatří k example.com, takže DMARC selže.

Takto čtete každý řádek:

1. Podívejte se na policy_evaluated. Je u dkim nebo spf pass? Pak DMARC uspělo a tento zdroj je v pořádku.
2. Selže vše? Podívejte se v auth_results na domény. Je to Vaše služba, která sice uspívá, ale pro svou vlastní doménu? Pak musíte u této služby zapnout DKIM s Vaší vlastní doménou (lekce 4.3).
3. Selže to i v auth_results, nebo DKIM zcela chybí? Zjistěte, komu IP adresa patří (reverzní DNS, lekce 5.1, nebo whois dotaz). Je to jeden z Vašich systémů: opravte to. Je neznámý a jde o podezřelá množství: pravděpodobně jde o podvrh.

Vzory, které uvidíte stále

Dávejte pozor i na IPv6: vlastní server, který občas odesílá přes IPv6, zatímco Vaše SPF uvádí jen IPv4 adresu, dává u těchto řádků softfail. S DKIM podpisem DMARC přesto uspěje, ale je to signál, že Vaše SPF není úplné.

Od reportu k rozhodnutí

Jste připraveni zpřísnit svou politiku (z none na quarantine, poté na reject), pokud:

• každý zdroj, který je Váš, má v policy_evaluated alespoň jeden pass;
• tak tomu je už pár týdnů, u všech velkých příjemců;
• co stále selhává, je pouze přeposlaná pošta s platným DKIM podpisem (ta nakonec stejně uspěje) nebo zjevný podvrh.

Pokud selhává velký vlastní zdroj, jako v příkladu newsletterová služba s 1250 zprávami, je ještě brzy. S p=reject by příjemce těch 1250 newsletterů odmítl.

Jak si reporty zpřehlednit

Jeden report v textovém editoru se dá zvládnout. Dvacet denně ne. Existují tři způsoby:

• Reportovací služba (existuje jich mnoho, i s bezplatnou variantou). Jejich adresu nastavíte v rua a oni z toho vytvoří grafy a seznamy. Pozor: tím dáte této službě přehled o tom, které servery jménem Vás odesílají poštu, a adresa pro reporty je na jejich doméně (viz souhlas přes _report._dmarc v lekci 4.4). Vyberte si službu, které důvěřujete a která dodržuje GDPR.
• Vlastní nástroj: existují open-source programy, které reporty vytahují ze schránky a sestavují z nich přehled.
• Čtení ručně pomocí XML prohlížeče nebo prohlížeče, pro občasné použití.

Chybové reporty (ruf, RFC 9991) jsou jiné: za každou neúspěšnou zprávu, někdy s částmi e-mailu uvnitř. Téměř žádný velký příjemce je neposílá, právě kvůli soukromí. K úspěšnému zavedení DMARC je nepotřebujete.

V praxi: takto to vypadá

U WebOké můžete adresu pro reporty vyplnit v DMARC pomocníkovi v DirectAdmin nebo Můj WebOké (viz lekce 4.4), a sami si zvolíte schránku, do které budou reporty chodit; samostatná adresa jako dmarc@ s vlastní složkou zabrání tomu, aby se Vaše běžná pošta ztratila. Čtení provádíte pomocí reportovací služby nebo programu dle vlastního výběru. To funguje u každého poskytovatele stejně: report je ve standardním formátu.

Shrnutí

• Souhrnný report je denní XML soubor (často zazipovaný) za každého příjemce, s počtem zpráv a výsledky za každou odesílající IP.
• auth_results udává syrový výsledek SPF a DKIM; policy_evaluated pouze to, co uspělo v souladu (aligned). Pass v auth_results může být fail v DMARC.
• Přeposlanou poštu poznáte podle DKIM pass se SPF fail; podvrh podle toho, že vše selhává u neznámé IP.
• Politiku zpřísněte, až všechny Vaše vlastní zdroje uspívají po dobu pár týdnů.
• Chybové reporty (ruf) jsou vzácné a nejsou potřeba.

Kvíz

Úkol

Úkol Z4.5: Čtení DMARC reportu. Otevřete ukázkový soubor dmarc-rapport-1.xml (souhrnný report o example.com, s fiktivními údaji). Odpovězte na otázky: jakou politiku příjemce zjistil, kolik zpráv je v reportu celkem, kolik z nich selhalo v DMARC, který řádek patří newsletterové službě a co se tam musí udělat, který řádek je přeposlaná pošta, který řádek je pravděpodobně podvrh, co se podle řádku 6 musí změnit na SPF záznamu, který řádek uspívá pouze díky DKIM u služby s vlastním Return-Path, a může doména nyní přejít na p=quarantine? Program Vaše odpovědi zkontroluje podle pevného klíče a u každé otázky vysvětlí, který řádek reportu dává odpověď.

Další čtení

Kroky v těchto článcích platí pro panely WebOké; u jiných poskytovatelů to funguje obdobně.

• Co je DMARC? Vysvětlení běžnou řečí
• Příručka k DirectAdmin 5.9: DMARC instellen
• Bezplatný DNS kurz 4.5: DMARC: co mají příjemci dělat s podvodnou poštou
• RFC 9990 (DMARC Aggregate Reporting), s ukázkovým reportem v příloze B; RFC 9991 (Failure Reporting)