Näin luet DMARC-raportteja: koosteraportin XML kenttä kentältä

DMARC-raportin lukeminen alkaa pakatun XML-liitteen avaamisesta: tarkista policy_published-osiosta, mitä käytäntöä vastaanottajat sovelsivat, ja käy sitten läpi jokainen record-lohko. source_ip ja count kertovat, kuka lähetti ja kuinka paljon, policy_evaluated antaa DMARC-tuomion ja auth_results näyttää sen alla olevat raa'at SPF- ja DKIM-tulokset. Rivi, joka läpäisee SPF:n tai DKIM:n mutta ei DMARC:ia, kärsii kohdistusongelmasta (alignment). Rivi, joka epäonnistuu kaikessa, on joko unohtunut lähettäjä tai joku, joka väärentää domainiasi. Tämä opas käy oikean raportin läpi kenttä kentältä, esittelee seitsemän yleisintä kuviota ja kertoo, mitä kullekin pitää tehdä.

Mikä DMARC-raportti oikeastaan on

Jokainen DMARC:ia tukeva vastaanottaja (Google, Microsoft 365, Yahoo, Mail.ru, Fastmail, Zoho ja monet muut) laskee viestit, jotka väittävät From-otsakkeessa tulevansa domainistasi. Kerran UTC-vuorokaudessa se pakkaa laskurit XML-tiedostoon, tiivistää sen ja lähettää sen DMARC-tietueesi rua=-tagissa olevaan osoitteeseen. Nämä ovat koosteraportteja, joita kutsutaan myös RUA-raporteiksi. Ne eivät sisällä viestien sisältöä, vain lukumääriä lähettäjä-IP:tä kohden ja kunkin todennustulokset.

IETF:n toukokuussa 2026 julkaiseman RFC 9990 -standardin (Standards Track -määrittely koosteraportoinnille) mukaan raportointijakso on tyypillisesti yksi UTC-vuorokausi alkaen 0000 UTC, XML on normaalisti gzip-pakattu ja jokainen raportti kattaa täsmälleen yhden käytäntödomainin. Raportteja tulee riippumatta siitä, onko käytäntösi p=none, p=quarantine vai p=reject. Ne ovat ainoa palaute, jonka DMARC antaa, ja niiden lukeminen ratkaisee, siirrytkö pakottavaan käytäntöön turvallisesti vai estätkö omat laskusi.

1,8 miljoonasta kärkidomainista 937 931 (52,1 %) julkaisee DMARC:n, yli 553 000 kerää koosteraportteja ja 411 935 käyttää pakottavaa käytäntöä. Vain noin 9 % tekee molemmat. Lähde: EasyDMARC, 2026 DMARC Adoption Report, 30. maaliskuuta 2026.

Kaavion aukko on juuri se ongelma, jonka tämä artikkeli ratkaisee. EasyDMARCin maaliskuun 2026 tutkimus 1,8 miljoonasta kärkidomainista osoitti, että vain noin 9 % yhdistää pakottavan käytännön raportointiin. DMARCguardin erillinen skannaus 5 499 028 Tranco-domainista 27. helmikuuta 2026 puolestaan osoitti, että 1 670 975 DMARC-domainista 776 918:lla (46,5 %) ei ole rua=-tagia lainkaan. Useimmat raportteja saavat domainin omistajat eivät koskaan avaa niitä, koska raaka XML näyttää vaikealta. Sitä se ei ole. Osioita on vain kolme.

Vaihe 1: avaa liite

Aito raporttiviesti näyttää aiheessa esimerkiksi Report Domain: example.com Submitter: google.com Report-ID: 1234567890, ja siinä on yksi liite. RFC 9990:n kohta 3.5.2 lukitsee tiedostonimen muotoon vastaanottaja!käytäntödomain!alkuaika!loppuaika.xml.gz, esimerkiksi google.com!example.com!1757462400!1757548799.xml.gz. Kaksi lukua ovat Unix-aikaleimoja raportointi-ikkunan alusta ja lopusta, joten näet katetun päivän jo ennen kuin avaat mitään.

Pura tiedosto komentorivillä:

gunzip google.com!example.com!1757462400!1757548799.xml.gz

Jotkin lähettäjät, Microsoft mukaan lukien, käyttävät gzipin sijaan zip-muotoa. Käytä silloin tiedostoon unzip-komentoa. Tuloksen saa luettavaan muotoon näin:

xmllint --format google.com!example.com!1757462400!1757548799.xml

Mikä tahansa tekstieditori käy myös. Näet yhden feedback-elementin, joka sisältää osiot report_metadata ja policy_published sekä yhden tai useamman record-lohkon.

Vaihe 2: lue kolme osiota

Tässä on yhteen tietueeseen karsittu raportti, jonka rakenne on RFC 9990:n liitteestä B:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <version>1.0</version>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>1757548799.example.com</report_id>
    <date_range>
      <begin>1757462400</begin>
      <end>1757548799</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>none</sp>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.123</source_ip>
      <count>123</count>
      <policy_evaluated>
        <disposition>none</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>

Vanhemmat raportit käyttävät RFC 7489:n nimiavaruutta http://dmarc.org/dmarc-xml/0.1. Kentät ovat samat, joten ne luetaan samalla tavalla.

Ero, johon lähes kaikki kompastuvat: auth_results on raaka tarkistus, policy_evaluated on tarkistus kohdistuksen jälkeen. DMARC laskee SPF:n tai DKIM:n läpäistyksi vain, jos todennettu domain vastaa header_from-domainiasi. Omalla domainillaan allekirjoittava markkinointialusta näyttää DKIM pass kohdassa auth_results ja DKIM fail kohdassa policy_evaluated. Allekirjoitus ei ole rikki. Se ei vain ole kohdistettu.

Vaihe 3: luokittele jokainen rivi

Kun kentät ovat hallussa, raportin lukeminen on kuvioiden tunnistamista. Nämä seitsemän kuviota kattavat lähes jokaisen rivin, jonka tulet kohtaamaan.

Jos et osaa sijoittaa riviä, tee IP:lle käänteishaku komennolla dig -x 192.0.2.123 +short tai host 192.0.2.123 ja tarkista sitten epäilemäsi toimittajan SPF-include. PTR-tietue, joka päättyy outbound.protection.outlook.com, google.com, amazonses.com, sendgrid.net tai mailgun.org, osoittaa yleensä suoraan vastuulliseen palveluun.

Raporttien lukeminen suurina määrinä

Muutaman lähettäjän domain tuottaa kourallisen tiedostoja päivässä, ja käsin lukeminen toimii. Sitä suuremmilla määrillä tarvitset analysointityökalun. Tyypillinen työkalu lukee rua=-postilaatikon, purkaa jokaisen tiedoston ja kokoaa rivit lähteittäin, jolloin näet "Microsoft 365: 12 400 viestiä, 100 % kohdistettu" neljänkymmenen XML-tiedoston sijaan. Ilmaisia vaihtoehtoja on, ja FortifyNetin oma skannaus kertoo, onko rua=-tagia ylipäätään olemassa ja onko se kirjoitettu oikein.

Kaksi tapaa merkitsee enemmän kuin työkalu. Ensinnäkin seuraa policy_published-osiota jokaisen DNS-muutoksen jälkeen: vastaanottajat tallentavat DMARC-tietueita välimuistiin, joten p=-muutospäivän raportti voi näyttää vanhan käytännön, ja RFC 9990:n kohta 3.3 sallii nimenomaisesti sekoituksen. Toiseksi jatka lukemista senkin jälkeen, kun olet päässyt p=reject-tasolle. Uudet SaaS-työkalut, vaihdetut DKIM-avaimet ja muokatut SPF-tietueet ilmestyvät jo seuraavana päivänä uutena kuvion 2, 4 tai 5 rivinä, kauan ennen kuin asiakkaasi huomaavat palautuneita viestejä.

Mitä RFC 9990 muutti lukijan kannalta

Toukokuun 2026 standardi, joka korvaa vuoden 2015 RFC 7489:n raportointiosat, on merkityksellinen, jos jäsennät raportteja itse tai arvioit toimittajaa.

Kaikki suuret vastaanottajat lähettävät syyskuussa 2026 yhä vanhan muotoisia raportteja, ja niin jatkuu pitkään. Lue molemmat muodot samalla tavalla äläkä koskaan hylkää raporttia siksi, että siinä on kenttä, jota et tunnista.

Usein kysyttyä

Miksi saan DMARC-raportteja viesteistä, joita en ole koskaan lähettänyt? Koska joku muu lähettää niitä. Koosteraportit kattavat jokaisen viestin, joka väitti From-otsakkeessa tulevansa domainistasi, väärennetyt mukaan lukien. Rivi, jossa on suuri määrä, tuntematon IP ja epäonnistuminen sekä SPF:ssä että DKIM:ssä, on täsmälleen sitä väärentämistä, jonka takia DMARC otettiin käyttöön.

Kuinka monta raporttia päivässä pitäisi odottaa? Yksi raportoivaa vastaanottajaa kohden päivässä ja domainia kohden, eli pienelle yritykselle tyypillisesti 3 - 15 tiedostoa. RFC 9990 määrittää jaksoksi yhden UTC-vuorokauden. Erittäin suuret vastaanottajat voivat jakaa päivän useaan tiedostoon.

Mitä disposition none tarkoittaa, kun minulla on p=quarantine? Joko viesti läpäisi DMARC:n, jolloin käytäntöä ei sovellettu, tai vastaanottaja ohitti käytäntösi ja reason-elementti kertoo miksi. Tarkista policy_evaluated: jos molemmat kohdistetut tulokset ovat pass, none on oikea disposition.

Sisältävätkö DMARC-raportit viestien sisältöä tai henkilötietoja? Koosteraportit sisältävät lähettäjä-IP:t, lukumäärät ja todennustulokset, eivät mitään viestin rungosta tai otsakkeista From-domainia lukuun ottamatta. Virheraportit (RUF, määritelty RFC 9991:ssä) voivat sisältää otsakkeita, ja suuret palveluntarjoajat lähettävät niitä harvoin.

Voinko lopettaa raporttien vastaanottamisen? Poista rua=-tagi, niin vastaanottajat lopettavat lähettämisen vuorokauden sisällä. Menetät samalla kaiken näkyvyyden väärennöksiin ja virheellisiin määrityksiin, joten rua=-tagin osoittaminen analysointityökaluun on parempi vaihtoehto.

Tarkista, tulevatko raporttisi ylipäätään perille

Ennen kuin käytät illan XML:n parissa, kannattaa selvittää, pyytääkö DMARC-tietueesi raportteja lainkaan, onko rua=-osoite valtuutettu ja ovatko SPF ja DKIM kunnossa jo tuntemillasi lähettäjillä. FortifyNetin ilmainen skannaus lukee DMARC-, SPF- ja DKIM-tietueesi ja merkitsee puutteet noin 60 sekunnissa ilman rekisteröitymistä. Aja ilmainen skannaus FortifyNetissä.

Aiheeseen liittyvät oppaat: DMARC-valvonta: turvallisesti p=reject-tasolle · DMARC:n käyttöönotto vaihe vaiheelta · Mikä on DKIM? · SPF Record Checker