Datahorses

Ako čítať súhrnný DMARC report (rua) a čo s ním robiť

Autor: · · 4 min čítania

Súhrnný DMARC report je denný prehľad, ktorý veľkí poskytovatelia e-mailových schránok posielajú na adresu uvedenú v značke rua vo vašom DMARC zázname. Uvádza každú IP adresu, ktorá posielala poštu s vašou doménou v riadku Od (From), koľko správ z nej odišlo a či SPF a DKIM prešli a boli zarovnané s vašou doménou. Neobsahuje obsah správ, predmety ani adresy príjemcov.

Z týchto reportov zistíte, kto naozaj posiela poštu vo vašom mene: vaše vlastné poštové servery, CRM, fakturačný nástroj, platforma na newslettre a ktokoľvek ďalší, kto jednoducho vloží vašu doménu do riadku Od. Práve tento zoznam potrebujete skôr, než politiku zmeníte z p=none na vynútenie.

Od mája 2026 formát definuje RFC 9990, ktoré spolu s RFC 9989 (samotný mechanizmus DMARC) nahradilo staršie RFC 7489. Ak si potrebujete osviežiť 3 záznamy, začnite článkom SPF, DKIM a DMARC vysvetlené.

Ako sa k vám reporty dostanú

Reporty si vyžiadate značkou rua vo vašom DMARC zázname:

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

Každý zapojený poskytovateľ vám potom pošle e-mailom XML súbor, zvyčajne skomprimovaný. RFC 9990 uvádza, že XML by mal byť skomprimovaný GZIP s príponou .xml.gz, a názov súboru má pevný tvar:

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

Je to organizácia, ktorá report posiela, vaša doména a začiatok a koniec obdobia ako Unix časové značky. Obdobie reportu zvyčajne pokrýva 1 deň v UTC.

Ak majú reporty chodiť do schránky na inej doméne (napríklad do služby na spracovanie reportov na reports.example.net), táto doména musí potvrdiť, že ich prijíma. Prijímajúce servery hľadajú TXT záznam ako example.com._report._dmarc.reports.example.net s hodnotou v=DMARC1 a ak chýba, adresu rua ignorujú. Chýbajúci potvrdzovací záznam je častý dôvod, prečo reporty nikdy neprídu.

Štruktúra jedného reportu

Každý report má tie isté 3 časti. Tu je skrátený príklad podľa ukážky 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: kto report poslal a aké obdobie pokrýva.
  • policy_published: DMARC záznam, ktorý prijímajúci server videl. Porovnajte ho s tým, čo si myslíte, že ste zverejnili.
  • record: 1 blok pre každú kombináciu odosielajúcej IP adresy a výsledkov. Doména s veľkou prevádzkou ich dostane veľa.

Čítanie záznamu pole po poli

source_ip a count. Server, ktorý sa pripojil k prijímajúcemu serveru, a počet správ, ktoré v danom období doručil. Tu identifikujete odosielateľov: spätný DNS dopyt (dig -x 192.0.2.123 +short) alebo vlastník IP adresy často prezradí, či patrí vášmu poskytovateľovi pošty, vášmu CRM alebo niekomu neznámemu.

policy_evaluated. Verdikt DMARC. Hodnoty dkim a spf tu nie sú surové výsledky, ale výsledky zarovnania: či kontrola prešla pre doménu zhodnú s doménou v riadku Od. DMARC prejde, ak je aspoň 1 z nich pass. disposition ukazuje, čo prijímajúci server urobil: none, pass, quarantine alebo reject. Ak sa líši od vašej politiky, prvok reason vysvetlí prečo, napríklad výnimku pre preposielanie alebo mailing list.

identifiers. header_from je doména, ktorú videli vaši príjemcovia. envelope_from je doména, ktorú použila kontrola SPF; často je to subdoména vašej odosielacej služby, nie vaša.

auth_results. Surové výsledky SPF a DKIM s doménami, pre ktoré sa kontrolovali. RFC 9990 teraz vyžaduje DKIM selektor, vďaka čomu rozoznáte, ktorá služba správu podpísala.

V príklade vyššie DKIM prešiel a bol zarovnaný, SPF zlyhal a správa aj tak prešla kontrolou DMARC. Je to typický obraz služby, ktorá podpisuje vašou doménou, ale posiela z vlastnej obálkovej domény.

Rozdelenie odosielateľov do 3 skupín

Po niekoľkých týždňoch reportov zapadne každá zdrojová IP adresa do 1 z týchto skupín:

  1. Známe a prechádzajúce. Váš poskytovateľ pošty a správne nastavené služby. Netreba nič robiť.
  2. Známe, ale zlyhávajúce. Legitímny nástroj (helpdesk, fakturácia, newsletter), ktorý posiela bez zarovnaného DKIM alebo chýba v SPF. Zapnite v tom nástroji DKIM s vašou doménou alebo ho pridajte do SPF a sledujte pritom limit 10 DNS dopytov.
  3. Neznáme a zlyhávajúce. Servery, ktoré neviete priradiť k ničomu, čo používate. Niektoré sú preposielače a mailing listy, iné patria niekomu, kto vkladá vašu doménu do riadku Od. Presne tieto správy by zastavila politika p=quarantine alebo p=reject; je to ten istý druh pošty, aký sa používa pri podvodoch s falošnými faktúrami.

Pred vynútením politiky je dôležitá skupina 2. Ak prejdete na p=quarantine, kým legitímny nástroj stále zlyháva, jeho pošta skončí v spame.

Praktické tipy

  • Používajte samostatnú schránku alebo nástroj na spracovanie reportov. Surové XML od viacerých poskytovateľov každý deň sa ručne číta ťažko.
  • Sledujte hodnotu testing. RFC 9989 nahradilo starú značku pct značkou testovacieho režimu t; t=y žiada prijímajúce servery, aby použili miernejší postup, než určuje vaša politika.
  • Sledujte objem, nielen zlyhania. Náhly nový zdroj s vysokým count si zaslúži pozornosť, aj keď prechádza.
  • Reporty uchovávajte niekoľko mesiacov, aby ste vedeli porovnať stav pred zmenou a po nej.
  • Nezabudnite, že poskytovatelia schránok čoraz viac očakávajú DMARC od hromadných odosielateľov, ako píšeme v článku Požiadavky Gmailu a Yahoo na odosielateľov.

Krátky kontrolný zoznam

  • DMARC záznam s adresou rua, ktorú niekto naozaj číta.
  • Externé ciele reportov potvrdené záznamom _report._dmarc.
  • Každá zdrojová IP adresa priradená k službe, ktorú poznáte.
  • Zarovnaný DKIM zapnutý pre každého legitímneho odosielateľa.
  • Neznáme zlyhávajúce zdroje preverené, potom politika presunutá na p=quarantine a neskôr na p=reject.

Kde pomáha Guarding

DMARC reporty ukazujú, čo videli prijímajúce servery. My každý deň sledujeme druhú stranu zvonku: vaše záznamy SPF, DKIM a DMARC, podobné domény a zvyšok vašej vonkajšej expozície. Keď sa záznam oslabí alebo selektor zmizne, posúdi to človek a vy dostanete presnú zmenu, ktorú treba urobiť, ako popisujeme v časti čo sa stane, keď niečo nájdeme. Ako to vyzerá, uvidíte na ukážkovom dashboarde.

Ďalšie články

Pripnuté

Odteraz hrdo strážime aj InvestTimes.com

Invest Times, anglický finančný denník o startupoch a investovaní, si vybral Guarding. Od dnešného dňa strážime InvestTimes.com zvonku, nepretržite.

Všetky články