DMARC-raporttien lukeminen

Moduuli 4: Toimitettavuus: SPF, DKIM ja DMARC käytännössä · Lukuaika: 12 minuuttia

Oppimistavoite: Tämän oppitunnin jälkeen osaat avata ja lukea DMARC-yhteenvetoraportin, päätellä rivikohtaisesti mikä lähde on kyseessä ja miksi se läpäisee tai ei läpäise tarkistusta, sekä päättää mitä korjaat, mitä voit jättää huomiotta ja milloin voit tiukentaa käytäntöäsi.

Keskeiset käsitteet: yhteenvetoraportti (aggregate report, RFC 9990), rua, XML, gzip tai zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selector, virheraportti (ruf, RFC 9991), raportointipalvelu, yksityisyys

Mitä saat vastaanottaa

Jos olet asettanut DMARC-tietueeseesi rua-osoitteen (oppitunti 4.4), suuret vastaanottajat kuten Google, Microsoft ja Yahoo lähettävät sinulle suunnilleen joka päivä yhteenvetoraportin. Se on sähköposti, jossa on liite, yleensä pakattu XML-tiedosto, jonka nimi on esimerkiksi:

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

Tämä tarkoittaa: vastaanottajalta receiver.example, koskien verkkotunnustasi example.com, ajanjaksolta kahden aikaleiman välillä (sekunteina vuodesta 1970 lähtien; tässä 6. marraskuuta 2026, koko päivä UTC-ajassa).

Raportti ei sisällä sähköpostin sisältöä, ei aiheita eikä yleensä vastaanottajien osoitteita. Se sisältää lähettävän palvelimen kohdalla viestien määrän sekä SPF:n, DKIM:n ja DMARC:n tuloksen. Siksi se on luotettava yleiskuva siitä, kuka lähettää postia verkkotunnuksesi nimissä, mukaan lukien lähteet, jotka olit itse unohtanut, ja huijarit.

Raportin rakenne

Raportissa on kolme osaa. Alla tärkeimmät osat tämän oppitunnin esimerkkitiedostosta (dmarc-rapport-1.xml).

1. Kuka raportoi, miltä ajanjaksolta

<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. Minkä käytännön vastaanottaja löysi sinulta

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

Tarkista tämä aina: jos tässä ei lue sitä mitä luulet DNS:ssäsi olevan, vastaanottaja luki eri (tai vanhan) tietueen.

3. Lähdekohtaisesti: yksi record

Jokainen record koskee yhtä lähettävää IP-osoitetta yhdellä tulosyhdistelmällä:

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

Tärkein ero: auth_results suhteessa policy_evaluated

Tässä on lukemisen ydin. Yllä olevassa esimerkissä auth_results-kohdassa lukee kahdesti pass: DKIM onnistui verkkotunnukselle mailer.example ja SPF onnistui verkkotunnukselle bounce.mailer.example. Silti policy_evaluated-kohdassa lukee kahdesti fail. Tämä ei ole ristiriita: policy_evaluated laskee vain onnistuneen tarkistuksen, joka on kohdistettu (aligned) verkkotunnukseen header_from. Kumpikaan verkkotunnus ei kuulu verkkotunnukselle example.com, joten DMARC epäonnistuu.

Näin luet jokaisen rivin:

1. Katso policy_evaluated-kohtaa. Lukeeko dkim- tai spf-kohdassa pass? Silloin DMARC onnistuu ja tämä lähde on kunnossa.
2. Epäonnistuuko kaikki? Katso auth_results-kohdasta verkkotunnukset. Onko kyseessä sinun käyttämäsi palvelu, joka onnistuu mutta omalla verkkotunnuksellaan? Silloin sinun pitää ottaa palvelussa käyttöön DKIM omalla verkkotunnuksellasi (oppitunti 4.3).
3. Epäonnistuuko se myös auth_results-kohdassa, tai puuttuuko DKIM kokonaan? Selvitä kuka IP-osoite on (reverse DNS, oppitunti 5.1, tai whois-haku). Jos kyseessä on yksi omista järjestelmistäsi: korjaa se. Jos se on tuntematon ja määrät ovat epäilyttäviä: kyseessä on todennäköisesti väärennös.

Toistuvat kuviot

Huomioi myös IPv6: oma palvelin, joka joskus lähettää IPv6:n kautta, kun SPF:si mainitsee vain IPv4-osoitteen, antaa softfailin niillä riveillä. DKIM-allekirjoituksella DMARC onnistuu silti, mutta se on merkki siitä, että SPF:si on puutteellinen.

Raportista päätökseen

Olet valmis tiukentamaan käytäntöäsi (asetuksesta none asetukseen quarantine, sitten asetukseen reject), kun:

• jokaisella sinulle kuuluvalla lähteellä on policy_evaluated-kohdassa vähintään yksi pass;
• näin on ollut jo muutaman viikon ajan kaikilla suurilla vastaanottajilla;
• mikä vielä epäonnistuu, on vain uudelleenohjattua sähköpostia, jossa on kelvollinen DKIM-allekirjoitus (joka silti onnistuu), tai selvää väärennöstä.

Jos epäonnistuu suuri oma lähde, kuten esimerkissä uutiskirjepalvelu 1250 viestillä, on vielä liian aikaista. Asetuksella p=reject vastaanottaja hylkäisi nuo 1250 uutiskirjettä.

Raporttien lukemisen helpottaminen

Yksi raportti tekstieditorissa on hoidettavissa. Kaksikymmentä päivässä ei. Keinoja on kolme:

• Raportointipalvelu (niitä on paljon, myös ilmaisversioita). Lisäät palvelun osoitteen rua-kenttään, ja he tekevät siitä kaavioita ja listoja. Huomaa: tällöin annat kyseiselle palvelulle näkyvyyden siihen, mitkä palvelimet lähettävät postia nimissäsi, ja raporttiosoite on heidän verkkotunnuksellaan (katso suostumus _report._dmarc-tietueen kautta oppitunnissa 4.4). Valitse palvelu, johon luotat ja joka noudattaa GDPR:ää (tietosuoja-asetus).
• Oma työkalu: on olemassa avoimen lähdekoodin ohjelmia, jotka hakevat raportit sähköpostilaatikosta ja koostavat niistä yhteenvedon.
• Lukeminen itse XML-katseluohjelmalla tai selaimella, satunnaiseen käyttöön.

Virheraportit (ruf, RFC 9991) ovat erilaisia: niitä lähetetään yksittäisistä epäonnistuneista viesteistä, joskus osia itse sähköpostista mukana. Lähes mikään suuri vastaanottaja ei lähetä niitä, juuri yksityisyyden vuoksi. Et tarvitse niitä DMARC:n kunnolliseen käyttöönottoon.

Käytännössä: näin se näyttää

WebOkéssa voit syöttää raporttiosoitteen DMARC-aputyökaluun DirectAdminissa tai Oma WebOkéssa (katso oppitunti 4.4), ja valitset itse sähköpostilaatikon, johon raportit saapuvat; erillinen osoite kuten dmarc@ omalla kansiollaan estää tavallisen postisi hukkumisen niiden alle. Lukemiseen käytät valitsemaasi raportointipalvelua tai ohjelmaa. Tämä toimii samalla tavalla kaikilla palveluntarjoajilla: raportti on standardimuotoinen.

Yhteenveto

• Yhteenvetoraportti on päivittäinen XML-tiedosto (usein pakattuna) vastaanottajaa kohden, jossa on lähettävää IP:tä kohden viestien määrä ja tulokset.
• auth_results antaa SPF:n ja DKIM:n raa'an tuloksen; policy_evaluated vain sen, mikä onnistui kohdistettuna. Pass auth_results-kohdassa voi olla fail DMARC:ssa.
• Uudelleenohjatun sähköpostin tunnistat DKIM pass -tuloksesta yhdistettynä SPF fail -tulokseen; väärennöksen tunnistat kaiken epäonnistumisesta tuntemattomalta IP:ltä.
• Tiukenna käytäntöäsi vasta, kun kaikki omat lähteesi ovat onnistuneet muutaman viikon ajan.
• Virheraportit (ruf) ovat harvinaisia eikä niitä tarvita.

Tietovisa

Tehtävä

Tehtävä Z4.5: DMARC-raportin lukeminen. Avaa esimerkkitiedosto dmarc-rapport-1.xml (yhteenvetoraportti verkkotunnuksesta example.com, keksityillä tiedoilla). Vastaa kysymyksiin: minkä käytännön vastaanottaja löysi, kuinka monta viestiä raportissa on yhteensä, kuinka monta niistä epäonnistui DMARC:ssa, mikä rivi on uutiskirjepalvelu ja mitä sille pitää tehdä, mikä rivi on uudelleenohjattua sähköpostia, mikä rivi on todennäköisesti väärennös, mitä SPF-tietueeseen pitää muuttaa rivin 6 perusteella, mikä rivi onnistuu vain DKIM:n ansiosta palvelussa, jolla on oma Return-Path, ja voiko verkkotunnus nyt siirtyä asetukseen p=quarantine? Ohjelma tarkistaa vastauksesi kiinteällä vastausavaimella ja selittää jokaisen kysymyksen kohdalla, mikä raportin rivi antaa vastauksen.

Lue lisää

Näiden artikkelien vaiheet koskevat WebOkén hallintapaneeleja; muilla palveluntarjoajilla toimintatapa on vastaava.

• Mitä on DMARC? Selitys selkeällä kielellä
• DirectAdmin-ohje 5.9: DMARC-tietueen määrittäminen
• Ilmainen DNS-kurssi 4.5: DMARC: mitä vastaanottajien pitäisi tehdä huijausviesteille
• RFC 9990 (DMARC Aggregate Reporting), esimerkkiraportti liitteessä B; RFC 9991 (Failure Reporting)