Miten DMARC-koosteraporttia (rua) luetaan ja mitä sillä tehdään

DMARC-koosteraportti on päivittäinen yhteenveto, jonka suuret sähköpostipalvelut lähettävät DMARC-tietueenne rua-tagissa olevaan osoitteeseen. Siinä luetellaan jokainen IP-osoite, joka lähetti postia verkkotunnuksenne ollessa Lähettäjä-kentässä, kuinka monta viestiä kukin lähetti sekä sen, läpäisivätkö SPF ja DKIM tarkistuksen ja vastasivatko ne verkkotunnustanne (kohdistus eli alignment). Raportti ei sisällä viestien sisältöä, aiheita eikä vastaanottajien osoitteita.

Raportteja lukemalla selvitätte, kuka todella lähettää postia nimissänne: omat postipalvelimenne, CRM, laskutustyökalu, uutiskirjealusta ja kuka tahansa muu, joka vain laittaa verkkotunnuksenne Lähettäjä-kenttään. Juuri tämä luettelo tarvitaan, ennen kuin siirrätte käytännön tasolta p=none pakottavaan tilaan.

Toukokuusta 2026 lähtien muoto on määritelty standardissa RFC 9990, joka yhdessä standardin RFC 9989 (itse DMARC-mekanismi) kanssa korvasi vanhemman RFC 7489:n. Jos haluatte kerrata 3 tietuetta, aloittakaa artikkelista SPF, DKIM ja DMARC selitettynä.

Miten raportit tulevat teille

Raportteja pyydetään DMARC-tietueen rua-tagilla:

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

Tämän jälkeen jokainen osallistuva palveluntarjoaja lähettää teille sähköpostilla XML-tiedoston, yleensä pakattuna. RFC 9990:n mukaan XML SHOULD be GZIP compressed eli se pitäisi pakata GZIP-muotoon tiedostopäätteellä .xml.gz, ja tiedostonimi noudattaa kiinteää kaavaa:

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

Nimestä näkyvät raportoiva organisaatio, verkkotunnuksenne sekä jakson alku ja loppu Unix-aikaleimoina. Raportointijakso kattaa tyypillisesti yhden UTC-vuorokauden.

Jos raporttien pitää mennä toisen verkkotunnuksen postilaatikkoon (esimerkiksi raportointipalveluun osoitteessa reports.example.net), kyseisen verkkotunnuksen on vahvistettava, että se ottaa ne vastaan. Vastaanottajat hakevat TXT-tietueen, kuten example.com._report._dmarc.reports.example.net, jossa on v=DMARC1, ja jos sitä ei ole, ne jättävät rua-osoitteen huomiotta. Puuttuva vahvistustietue on yleinen syy siihen, että raportteja ei koskaan tule.

Yhden raportin rakenne

Jokaisessa raportissa on samat 3 osaa. Tässä lyhennetty esimerkki, joka perustuu RFC 9990:n malliin:

<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: kuka raportin lähetti ja mitä jaksoa se koskee.
• policy_published: DMARC-tietue, jonka vastaanottaja näki. Verratkaa sitä siihen, minkä uskotte julkaisseenne.
• record: yksi lohko jokaista lähettävän IP-osoitteen ja tulosten yhdistelmää kohden. Vilkkaalla verkkotunnuksella niitä on paljon.

Tietueen lukeminen kenttä kentältä

source_ip ja count. Palvelin, joka otti yhteyden vastaanottajaan, ja kuinka monta viestiä se toimitti jakson aikana. Tästä tunnistatte lähettäjät: käänteinen DNS-haku (dig -x 192.0.2.123 +short) tai IP-osoitteen omistaja kertoo usein, kuuluuko se sähköpostipalvelullenne, CRM:llenne vai jollekulle tuntemattomalle.

policy_evaluated. DMARC-tuomio. Tässä dkim ja spf eivät ole raakatuloksia vaan kohdistustuloksia: läpäisikö tarkistus verkkotunnuksella, joka vastaa Lähettäjä-kentän verkkotunnusta. Viesti läpäisee DMARCin, jos vähintään toinen niistä on pass. disposition näyttää, mitä vastaanottaja teki: none, pass, quarantine tai reject. Jos se poikkeaa käytännöstänne, reason-elementti kertoo syyn, esimerkiksi edelleenlähetyksen tai postituslistan aiheuttaman poikkeuksen.

identifiers. header_from on verkkotunnus, jonka vastaanottajanne näkivät. envelope_from on verkkotunnus, jota SPF-tarkistus käytti, ja se on usein lähettävän palvelun aliverkkotunnus eikä teidän.

auth_results. SPF:n ja DKIM:n raakatulokset sekä verkkotunnukset, joille ne tarkistettiin. RFC 9990 edellyttää nyt DKIM-valitsinta, mikä auttaa näkemään, mikä palvelu viestin allekirjoitti.

Yllä olevassa esimerkissä DKIM läpäisi ja vastasi verkkotunnusta, SPF epäonnistui, ja viesti läpäisi silti DMARCin. Tämä on tyypillistä palvelulle, joka allekirjoittaa teidän verkkotunnuksellanne mutta lähettää oman envelope-verkkotunnuksensa kautta.

Lähettäjien lajittelu 3 ryhmään

Kun raportteja on kertynyt muutaman viikon ajalta, jokainen lähettävä IP-osoite kuuluu johonkin näistä ryhmistä:

1. Tunnettu ja läpäisee. Sähköpostipalvelunne ja oikein määritetyt palvelut. Ei toimenpiteitä.
2. Tunnettu mutta epäonnistuu. Oikea työkalu (asiakastuki, laskutus, uutiskirje), joka lähettää ilman verkkotunnusta vastaavaa DKIM-allekirjoitusta tai puuttuu SPF:stä. Ottakaa työkalussa käyttöön DKIM verkkotunnuksellanne tai lisätkää se SPF:ään ja pitäkää silmällä 10 haun rajaa.
3. Tuntematon ja epäonnistuu. Palvelimet, joita ette pysty yhdistämään mihinkään käyttämäänne. Osa on edelleenlähettäjiä ja postituslistoja, osa taas joku, joka laittaa verkkotunnuksenne Lähettäjä-kenttään. Juuri nämä viestit käytäntö p=quarantine tai p=reject pysäyttäisi, ja samanlaista postia käytetään väärennettyjen laskujen huijauksissa.

Ryhmä 2 on ratkaiseva ennen pakottavan käytännön käyttöönottoa. Jos vaihdatte käytäntöön p=quarantine, kun oikea työkalu yhä epäonnistuu, sen posti päätyy roskapostiin.

Käytännön vinkkejä

• Käyttäkää erillistä postilaatikkoa tai raporttien käsittelytyökalua. Useiden palveluntarjoajien raakaa XML:ää on työlästä lukea käsin joka päivä.
• Seuratkaa testing-arvoa. RFC 9989 korvasi vanhan pct-tagin t-testitilatagilla; t=y pyytää vastaanottajia soveltamaan käytäntöänne lievempää toimenpidettä.
• Katsokaa määriä, ei vain epäonnistumisia. Äkillinen uusi lähde, jolla on korkea count, ansaitsee huomiota, vaikka se läpäisisikin.
• Säilyttäkää raportit muutaman kuukauden ajan, jotta voitte verrata tilannetta ennen muutosta ja sen jälkeen.
• Muistakaa, että sähköpostipalvelut odottavat yhä useammin DMARCia joukkolähettäjiltä, kuten artikkelissa Gmailin ja Yahoon lähettäjävaatimukset kerrotaan.

Lyhyt tarkistuslista

• DMARC-tietue, jossa on rua-osoite, jota joku todella lukee.
• Ulkoiset raporttien vastaanottajat vahvistettu _report._dmarc-tietueella.
• Jokainen lähettävä IP-osoite yhdistetty tuntemaanne palveluun.
• Verkkotunnusta vastaava DKIM käytössä jokaisella oikealla lähettäjällä.
• Tuntemattomat epäonnistuvat lähteet käyty läpi, sitten käytäntö siirretty tasolle p=quarantine ja myöhemmin p=reject.

Miten Guarding auttaa

DMARC-raportit näyttävät, mitä vastaanottajat näkivät. Me valvomme toista puolta ulkoapäin joka päivä: SPF-, DKIM- ja DMARC-tietueitanne, samankaltaisia verkkotunnuksia ja muuta ulkoista altistumistanne. Kun tietuetta heikennetään tai valitsin katoaa, ihminen tarkistaa asian ja saatte tarkan kuvauksen tarvittavasta muutoksesta, kuten kohdassa mitä tapahtuu, kun löydämme jotain kuvataan. Voitte katsoa, miltä se näyttää, esimerkkinäkymästä.