DMARC-jelentések olvasása

Modul 4: Kézbesíthetőség: SPF, DKIM és DMARC a gyakorlatban · Olvasási idő: 12 perc

Tanulási cél: E lecke után Ön képes lesz megnyitni és elolvasni egy DMARC-összesítő jelentést, soronként megállapítani, melyik forrásról van szó, és miért sikeres vagy sikertelen, valamint eldönteni, mit javítson, mit hagyhat figyelmen kívül, és mikor szigoríthatja a szabályzatát.

Kulcsfogalmak: összesítő jelentés (aggregate report, RFC 9990), rua, XML, gzip vagy zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, szelektor, hibajelentés (ruf, RFC 9991), jelentésszolgáltatás, adatvédelem

Mit kap kézhez

Ha a DMARC-rekordjában megadott egy rua címet (4.4. lecke), a nagy fogadó szolgáltatók, mint a Google, a Microsoft és a Yahoo, körülbelül naponta küldenek Önnek egy összesítő jelentést. Ez egy e-mail, amelyhez csatolmány tartozik, általában egy tömörített XML-fájl, amelynek neve valahogy így néz ki:

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

Ez azt jelenti: a receiver.example fogadótól, az Ön example.com domainjéről, a két időbélyeg közötti időszakról (másodpercek 1970 óta; itt 2026. november 6., a teljes nap UTC szerint).

Egy jelentés nem tartalmazza a levelek tartalmát, nincsenek benne tárgyak, és általában a fogadók címei sem szerepelnek benne. Küldő szerverenként tartalmazza az üzenetek számát, valamint az SPF, a DKIM és a DMARC eredményét. Ezáltal megbízható áttekintést ad arról, ki küld levelet az Ön domainje nevében, beleértve azokat a forrásokat is, amelyekről Ön megfeledkezett, és a visszaéléseket is.

Egy jelentés felépítése

Egy jelentés három részből áll. Alább a lecke példafájljának (dmarc-rapport-1.xml) legfontosabb részletei olvashatók.

1. Ki jelent, milyen időszakról

<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. Milyen szabályzatot talált a fogadó az Ön domainjénél

<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>

Ezt mindig ellenőrizze: ha nem az szerepel itt, amiről azt gondolja, hogy a DNS-ében van, akkor a fogadó egy másik (vagy régi) rekordot olvasott be.

3. Forrásonként egy rekord

Minden record egyetlen küldő IP-címről szól, egyetlen eredménykombinációval:

<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>

A legfontosabb különbség: auth_results a policy_evaluated-dal szemben

Itt rejlik az olvasás lényege. A fenti példában az auth_results kétszer pass eredményt mutat: a DKIM sikeres volt a mailer.example domainnél, az SPF pedig a bounce.mailer.example domainnél. Mégis a policy_evaluated kétszer fail eredményt mutat. Ez nem ellentmondás: a policy_evaluated csak azt a sikeres ellenőrzést számolja, amely össze van illesztve (aligned) a header_from értékkel. Egyik domain sem tartozik az example.com-hoz, így a DMARC sikertelen.

Így kell olvasni minden egyes sort:

1. Nézze meg a policy_evaluated mezőt. Szerepel-e a dkim vagy az spf mellett pass? Akkor a DMARC sikeres, és ez a forrás rendben van.
2. Ha minden sikertelen? Nézze meg az auth_results mezőben a domaineket. Egy olyan szolgáltatásról van szó, amely az Öné, de a saját domainjével sikeres? Akkor az adott szolgáltatásnál be kell kapcsolni a DKIM-et az Ön saját domainjével (4.3. lecke).
3. Sikertelen az auth_results-ban is, vagy teljesen hiányzik a DKIM? Derítse ki, kié az IP-cím (fordított DNS, 5.1. lecke, vagy whois-lekérdezés). Az Ön saját rendszeréről van szó: javítsa ki. Ismeretlen, és gyanús mennyiségekről van szó: valószínűleg hamisítás.

Visszatérő minták

Figyeljen az IPv6-ra is: ha a saját szervere időnként IPv6-on keresztül küld, miközben az SPF-ben csak az IPv4-cím szerepel, az ezekben a sorokban softfailt eredményez. DKIM-aláírással ilyenkor a DMARC még sikeres lehet, de ez jelzi, hogy az SPF-je hiányos.

A jelentéstől a döntésig

Akkor készen áll a szabályzat szigorítására (none-ról quarantine-ra, majd reject-re), ha:

• minden Önhöz tartozó forrás a policy_evaluated-ban legalább egy pass eredményt mutat;
• ez már néhány hete így van, minden nagy fogadónál;
• ami még sikertelen, az csak érvényes DKIM-aláírással rendelkező átirányított levél (ami akkor mégis sikeres lesz), vagy egyértelmű hamisítás.

Ha egy nagy, Önhöz tartozó forrás sikertelen, mint a példában a hírlevélszolgáltatás 1250 üzenettel, akkor még korai. A p=reject beállítás esetén a fogadó elutasítaná azt az 1250 hírlevelet.

A jelentések olvashatóvá tétele

Egyetlen jelentést egy szövegszerkesztőben is el lehet olvasni. Napi húszat már nem. Három lehetőség van:

• Jelentésszolgáltatás (sok létezik, ingyenes változattal is). A rua mezőbe azok címét adja meg, ők pedig grafikonokat és listákat készítenek belőle. Fontos: ezzel betekintést enged a szolgáltatásnak abba, mely szerverek küldenek az Ön nevében, és a jelentéscím az ő domainjükön lesz (lásd a _report._dmarc mezőn keresztüli hozzájárulást a 4.4. leckében). Olyan szolgáltatást válasszon, amelyben megbízik, és amely betartja a GDPR-t.
• Saját eszköz: léteznek nyílt forráskódú programok, amelyek kiolvassák a jelentéseket egy postafiókból, és áttekintésbe rendezik azokat.
• Önálló olvasás egy XML-nézegetővel vagy böngészővel, alkalmankénti esetekre.

A hibajelentések (ruf, RFC 9991) ettől eltérnek: sikertelen levelenként, néha a levél részleteivel együtt. Szinte egyetlen nagy fogadó sem küld ilyet, éppen az adatvédelem miatt. Ezekre nincs szükség a DMARC megfelelő bevezetéséhez.

A gyakorlatban: így néz ki

A WebOkénál a jelentéscímet a DirectAdmin vagy a Fiókom DMARC-segédletében lehet megadni (lásd a 4.4. leckét), és Ön maga választhatja ki, melyik postafiókba érkezzenek a jelentések; egy külön cím, mint a dmarc@, saját mappával, megakadályozza, hogy a rendes levelezése elvesszen köztük. Az olvasáshoz tetszőleges jelentésszolgáltatást vagy programot választhat. Ez minden szolgáltatónál ugyanúgy működik: a jelentés egy szabványos formátum.

Összefoglalás

• Egy összesítő jelentés egy naponkénti XML-fájl (gyakran tömörítve) fogadónként, amely küldő IP-nként tartalmazza az üzenetek számát és az eredményeket.
• Az auth_results a nyers SPF- és DKIM-eredményt adja meg; a policy_evaluated csak azt, ami összeillesztve (aligned) sikeres volt. Egy pass az auth_results-ban lehet fail a DMARC-ban.
• Az átirányított levelet a DKIM pass és az SPF fail kombinációjáról ismeri fel; a hamisítást arról, hogy minden sikertelen egy ismeretlen IP-ről.
• A szabályzatot csak akkor szigorítsa, ha minden saját forrása néhány héten át sikeres.
• A hibajelentések (ruf) ritkák, és nincs szükség rájuk.

Kvíz

Feladat

Feladat Z4.5: DMARC-jelentés olvasása. Nyissa meg a dmarc-rapport-1.xml példafájlt (egy example.com domainről szóló összesítő jelentés, kitalált adatokkal). Válaszoljon a kérdésekre: milyen szabályzatot talált a fogadó, hány üzenet szerepel összesen a jelentésben, ezek közül hány volt sikertelen a DMARC szerint, melyik sor a hírlevélszolgáltatás, és mit kell ott tenni, melyik sor az átirányított levél, melyik sor valószínűleg hamisítás, mit kell módosítani az SPF-rekordon a 6. sor szerint, melyik sor sikeres csak a DKIM-nek köszönhetően egy saját Return-Pathtal rendelkező szolgáltatásnál, és áttérhet-e most a domain a p=quarantine beállításra? A program rögzített kulccsal ellenőrzi a válaszait, és kérdésenként elmagyarázza, a jelentés melyik sora adja a választ.

További olvasnivaló

Az ezekben a cikkekben szereplő lépések a WebOké paneljeire vonatkoznak; más szolgáltatóknál hasonlóan működik.

• Mi az a DMARC? Magyarázat közérthetően
• DirectAdmin útmutató 5.9: DMARC beállítása
• Ingyenes DNS-tanfolyam 4.5: DMARC: mit kell tenniük a címzetteknek a hamis levelekkel
• RFC 9990 (DMARC Aggregate Reporting), a B mellékletben található példajelentéssel; RFC 9991 (Failure Reporting)
• A DMARC-jelentés olvasása