DMARC-seuranta: näin luet raportit ja pääset turvallisesti p=reject-tilaan
Yli puolet DMARC-tietueen julkaisevista verkkotunnuksista ei kerää raportteja lainkaan. Näin DMARC-seuranta toimii, näin luet koosteraportin, mitä RFC 9990 muutti vuonna 2026 ja miten pääset p=reject-tilaan estämättä omaa postiasi.
Suorita sama tarkistus heti — ilmaiseksi
Anna verkkotunnuksesi ja saat 9-kohdan auditoinnin — DNS, SPF/DKIM/DMARC, SSL, tietoturvaotsikot, dark web -altistus — 60 sekunnissa.
Ei rekisteröitymistä · <60s · GDPR/EU-käsittely
DMARC-seuranta tarkoittaa niiden koosteraporttien keräämistä ja lukemista, joita sähköpostin vastaanottajat lähettävät verkkotunnuksellesi joka päivä. Näin näet tarkalleen, kuka lähettää postia nimissäsi, ennen kuin vaihdat käytännön quarantine- tai reject-tilaan. Seuranta otetaan käyttöön lisäämällä rua=mailto:-tunniste DMARC-tietueeseen. Vuorokauden tai kahden kuluessa Googlen, Microsoft 365:n ja Yahoon kaltaiset palvelut alkavat lähettää pakattuja XML-tiedostoja, jotka tiivistävät jokaisen viestin, joka väitti tulevansa verkkotunnuksestasi. Nämä tiedostot ovat ainoa saamasi todiste, ja ilman niitä siirtymä tiukempaan käytäntöön on pelkkää arvailua.
Mitä DMARC-seuranta oikeastaan on
DMARC (Domain-based Message Authentication, Reporting and Conformance) tekee kaksi asiaa. Käytäntöpuoli kertoo vastaanottajille, mitä tehdä todennuksen läpäisemättömälle postille. Raportointipuoli kertoo sinulle, mitä vastaanottajat näkevät. Seuranta on tämä jälkimmäinen puolisko, ja juuri sen useimmat verkkotunnusten omistajat ohittavat.
Mekanismi on suoraviivainen. Kun vastaanottava palvelu arvioi postia, joka ilmoittaa From-kentässä verkkotunnuksesi, se laskee tulokset. Jokaisen UTC-vuorokauden lopuksi se pakkaa luvut XML-tiedostoon ja lähettää sen rua=-tunnisteessa olevaan osoitteeseen. RFC 9990 kohta 3.1.1.4 määrittelee, että raportointijakso kattaa yhden UTC-vuorokauden alkaen klo 00.00 UTC. Siksi ensimmäinen raportti saapuu 24 - 48 tunnin kuluessa tunnisteen julkaisusta eikä heti.
Raportit ovat gzip-pakattuja ja pieniä. Mitatut tiedostokoot palveluittain olivat 3,6 kt:n ja 4,8 kt:n välillä (Google 3 962 tavua, Yahoo 4 626, Fastmail 4 839) Ashiqin ja muiden USENIX Security 2023 -konferenssissa julkaisemassa aineistossa. Tallennustila ei ole koskaan ongelma. Määrä on: vilkkaasti liikennöivä verkkotunnus voi saada satoja tiedostoja päivässä, ja siksi niitä ei juuri kukaan lue käsin.
Yli puolet DMARC-verkkotunnuksista lentää sokkona
DMARC-käytäntöjen jakauma niissä 1 670 975 verkkotunnuksessa, jotka julkaisevat tietueen. Lähde: DMARCguard, State of Email Authentication 2026, 5 499 028 Tranco-verkkotunnuksen skannaus, 27. helmikuuta 2026.
Sama skannaus osoitti, että vain 894 057 näistä 1 670 975 verkkotunnuksesta (53,5 %) julkaisee rua=-tunnisteen. Lopuilla 776 918:lla on käytäntö mutta ei lainkaan mittaustietoa.
Seuraus näkyy yllä olevassa jakaumassa. 57,9 prosenttia DMARC-verkkotunnuksista, 967 474 kappaletta, on yhä p=none-tilassa. Pelkkä seurantatila on tarkoitettu väliasemaksi, ei päätepysäkiksi, ja syy siihen, ettei niin moni koskaan poistu siitä, on yksinkertainen: ilman raportteja päätökselle ei ole pohjaa.
Riski ei ole teoreettinen. FBI:n Internet Crime Complaint Center kirjasi vuoden 2024 vuosiraportissaan 2,77 miljardin dollarin tappiot Business Email Compromise -huijauksista 21 442 ilmoituksen perusteella. Vaakakupin toisella puolella: kun Google ja Yahoo ottivat helmikuussa 2024 käyttöön massalähettäjien todennusvaatimukset, Gmail raportoi 265 miljardia todentamatonta viestiä vähemmän samana vuonna (Neil Kumaran, Group Product Manager, Gmail Security and Trust, lokakuu 2024).
Näin otat raportoinnin käyttöön
Lisää rua=-tunniste TXT-tietueeseen osoitteessa _dmarc.verkkotunnuksesi.fi:
v=DMARC1; p=none; rua=mailto:dmarc-raportit@verkkotunnuksesi.fi; fo=1
Tarkista DNS-haulla, mitä on julkaistu:
dig +short TXT _dmarc.verkkotunnuksesi.fi
Kolme sääntöä kannattaa tietää ennen DNS-muokkausta:
- Vain yksi tietue. RFC 9989 vaatii täsmälleen yhden DMARC TXT -tietueen verkkotunnusta kohden. Jos julkaiset kaksi, vastaanottajat eivät sovella mitään käytäntöä, mikä käytännössä sammuttaa DMARCin.
- Ilman
rua=-tunnistetta ei tule raportteja. Vastaanottajat eivät saa tuottaa koostepalautetta ilman tunnistetta. Muuta reittiä ei ole. - Kattavuus on tarkoituksella osittainen. Microsoftin oma dokumentaatio, päivitetty 14. toukokuuta 2026, toteaa, etteivät kaikki vastaanottajat lähetä raportteja ja että kattavuus on tyypillisesti 70 - 90 prosenttia kokonaisvolyymistä. Apple iCloudia ja Protonia ei ole dokumentoitu raporttien lähettäjiksi lainkaan.
Raporttien lähettäminen toiseen verkkotunnukseen
Jos rua=-osoitteesi on eri organisaatioverkkotunnuksessa kuin käytäntö, vastaanottavan verkkotunnuksen on valtuutettava se. RFC 9990 kohta 4 vaatii TXT-tietueen osoitteessa <verkkotunnuksesi>._report._dmarc.<raporttiverkkotunnus>, joka sisältää arvon v=DMARC1;. Ilman sitä vastaanottajat lakkaavat lähettämästä ilman ilmoitusta. Tämä on ylivoimaisesti yleisin syy siihen, ettei oikein kirjoitettu rua=-tunniste tuota lainkaan raportteja.
Koosteraportit ja virheraportit vertailussa
| Koosteraportit (RUA) | Virheraportit (RUF) | |
|---|---|---|
| Määrittely | RFC 9990 | RFC 9991 |
| Tiheys | Kerran UTC-vuorokaudessa palvelua kohden | Lähes reaaliaikaisesti, viestikohtaisesti |
| Sisältö | Lukumäärät lähde-IP:tä kohden, SPF- ja DKIM-kohdistus sekä sovellettu käsittely | Yhden epäonnistuneen viestin tiedot, mahdollisesti otsikot ja sisältö |
| Tietosuoja | Koostetut luvut, ei viestisisältöä | RFC 9991 huomauttaa, että raportit voivat sisältää henkilötietoja |
| Palvelutuki | Laaja: Google, Microsoft 365, Yahoo, Mail.ru, Fastmail, Zoho | Harvinainen. Microsoft 365 ei lähetä niitä edes kelvollisella ruf=-arvolla |
| Paras käyttö | Lähettäjäluettelon rakentaminen ja tiukennuksen ajoitus | Yksittäisen toistettavan virheen selvittäminen |
Aloita RUA-raporteista. Lähes kaikki, mitä tarvitset päästäksesi turvallisesti p=reject-tilaan, löytyy koostedatasta, eikä siihen liity virheraporttien tietosuojataakkaa.
Raportin lukeminen: neljä merkitsevää lopputulosta
Jokainen XML-tiedoston <record>-lohko yhdistää lähde-IP:n viestimäärään, raakoihin SPF- ja DKIM-tuloksiin sekä policy_evaluated-tuomioon. Merkitystä on kohdistuksella, ei pelkällä todennuksella. SPF:n tai DKIM:n on sekä läpäistävä että vastattava From-verkkotunnustasi, jotta DMARC läpäisee.
| SPF kohdistettu | DKIM kohdistettu | Mitä se tarkoittaa | Mitä tehdä |
|---|---|---|---|
| Läpäisee | Läpäisee | Kunnossa. Oma infrastruktuurisi, oikein määritettynä | Ei mitään. Tämä on tavoitetila jokaiselle aidolle lähettäjälle |
| Läpäisee | Epäonnistuu | Lähettäjä on valtuutettu mutta ei allekirjoita, tai allekirjoittaa omalla verkkotunnuksellaan | Ota DKIM käyttöön palvelussa ja kohdista d=-verkkotunnus omaasi |
| Epäonnistuu | Läpäisee | Lähes aina edelleenlähetys tai postituslista. DMARC läpäisee silti | Vaaratonta. Älä lisää edelleenlähettäjää SPF-tietueeseesi |
| Epäonnistuu | Epäonnistuu | Joko unohtunut aito lähettäjä tai väärentäminen | Tunnista IP-osoite. Valtuuta se tai anna sen estyä tiukennuksessa |
Kolmas rivi ymmärretään useimmin väärin. Edelleenlähetys rikkoo SPF:n rakenteellisesti, koska kuoren lähettäjä vaihtuu edelleenlähetysvaiheessa. Juuri siksi DKIM on tärkeä varakeinona, ja siksi ne 43,0 prosenttia DMARC-verkkotunnuksista, jotka nojaavat pelkkään SPF-kohdistukseen (DMARCguard, helmikuu 2026), ovat hauraampia kuin miltä näyttävät.
Mikä muuttui vuonna 2026: RFC 9989, 9990 ja 9991
Toukokuussa 2026 IETF julkaisi standardit RFC 9989, RFC 9990 ja RFC 9991. Yhdessä ne korvaavat RFC 7489:n ja siirtävät DMARCin ensimmäistä kertaa vuoden 2015 jälkeen Standards Track -polulle Proposed Standard -tasolle, raportointi omissa dokumenteissaan.
| Kohde | RFC 7489 (2015) | RFC 9989 / 9990 (2026) | Mitä sinun kannattaa tehdä |
|---|---|---|---|
Tunniste pct | Tuettu, osittaiseen käyttöönottoon | Poistettu | Lakkaa luottamasta siihen. Käytä uutta t=y-testitilaa |
Tunnisteet rf ja ri | Määritellyt | Poistetut | Poista ne seuraavan DNS-muokkauksen yhteydessä |
| Organisaatioverkkotunnuksen tunnistus | Public Suffix List | DNS-puun läpikäynti | Ei mitään. Muutos on vastaanottajan puolella |
| Raportin XML-nimiavaruus | http://dmarc.org/dmarc-xml/0.1 | urn:ietf:params:xml:ns:dmarc-2.0 | Jäsentimen on hyväksyttävä molemmat |
DKIM-kenttä selector | Valinnainen | Pakollinen | Korjaa generaattorit tai jäsentimet, jotka jättävät kentän pois |
disposition-arvot | none, quarantine, reject | Lisää arvon pass | Käsittele uusi arvo sen sijaan, että hylkäisit tiedoston |
| Tuntemattomat elementit | Määrittelemätön | Ohita ja jatka (RFC 9990 kohta 5) | Älä koskaan hylkää raporttia, jota et täysin ymmärrä |
Nykyinen tietueesi toimii edelleen. Tunnisteet v=, p=, sp=, rua=, ruf=, adkim=, aspf= ja fo= säilyttävät merkityksensä. Käytännössä kaikki suuret palvelut lähettävät yhä vanhanmuotoista XML:ää, joten varaudu vuosien sekavaiheeseen ja jäsennä salliten äläkä tiukasti.
Turvallinen nelivaiheinen siirtymä p=reject-tilaan
- Viikot 1 ja 2. Julkaise
p=nonejarua=. Älä muuta muuta. Kerää raportteja ja rakenna luettelo jokaisesta IP-osoitteesta ja palvelusta, joka lähettää nimissäsi. - Viikot 3 - 6. Korjaa kohdistus. Lisää puuttuvat lähettäjät SPF-tietueeseen, ota DKIM käyttöön kaikkialla ja varmista, että jokainen kolmannen osapuolen palvelu allekirjoittaa sinun verkkotunnuksellasi eikä omallaan.
- Viikot 7 ja 8. Siirry tilaan
p=quarantine, halutessasi ensin aliverkkotunnuksessasp=-tunnisteella. Seuraa raportteja kokonainen viikko unohtuneiden aitojen lähettäjien varalta. - Viikosta 9 eteenpäin. Siirry tilaan
p=rejectja pidärua=pysyvästi. Seuranta ei ole rakennusteline, joka puretaan valmistumisen jälkeen.
Ensimmäisen vaiheen kiirehtiminen on klassinen virhe. Neljännesvuosittainen laskutusajo tai vuosittainen kampanja ei näy kahden viikon aineistossa, ja se pomppaa takaisin juuri sinä päivänä, kun tiukennat käytännön.
Usein kysyttyä
Kuinka usein DMARC-raportteja lähetetään?
Kerran UTC-vuorokaudessa kutakin raportoivaa palvelua kohden, ikkunalta, joka alkaa klo 00.00 UTC (RFC 9990 kohta 3.1.1.4). Ensimmäinen raportti saapuu tavallisesti 24 - 48 tunnin kuluessa rua=-tunnisteen julkaisusta.
Miksi en saa raportteja lainkaan?
Useimmiten rua=-osoite on toisessa verkkotunnuksessa ja pakollinen valtuutustietue osoitteessa <verkkotunnuksesi>._report._dmarc.<raporttiverkkotunnus> puuttuu. Muita syitä: syntaksivirhe DMARC-tietueessa, kaksi samanaikaisesti julkaistua DMARC-tietuetta tai yksinkertaisesti se, ettei kukaan lähettänyt postia verkkotunnuksesi nimissä kyseisenä jaksona.
Onko postilaatikkooni saapunut DMARC-raportti aito?
Mitä todennäköisimmin on. Aidot raportit käyttävät aihekaavaa Report Domain: <verkkotunnus> Submitter: <lähettäjä> Report-ID: <tunnus> ja liittävät mukaan pakatun XML-tiedoston, jonka nimi on eroteltu huutomerkein. Aidoissa raporteissa ei ole klikattavia linkkejä, maksuvaatimuksia eikä tunnuspyyntöjä.
Tarvitsenko seurantaa vielä p=reject-tilan jälkeen? Kyllä. Uusia palveluja tulee mukaan, DNS:ää muokataan, DKIM-avaimia vaihdetaan. Raporttien kautta huomaat rikkoutumisen ennen asiakkaitasi.
Voinko vain poistaa raportit?
Voit poistaa rua=-tunnisteen ja lopettaa ne, mutta vaihdat samalla sotkuisen postilaatikon nollanäkyvyyteen siitä, kuka väärentää verkkotunnustasi. rua=-osoitteen ohjaaminen analyysipalveluun on parempi vastaus.
Tarkista asetuksesi 60 sekunnissa
Ennen kuin kosket DNS:ään, kannattaa tietää tarkalleen, missä mennään. FortifyNetin maksuton skannaus lukee DMARC-, SPF- ja DKIM-tietueesi ja kertoo, onko raportointi todella määritetty, onko käytäntösi tiukennettu ja mitä puuttuu. Se kestää noin minuutin eikä vaadi rekisteröitymistä. Aja maksuton skannaus FortifyNetissä.
Aiheeseen liittyvät oppaat: Näin otat DMARCin käyttöön vaihe vaiheelta · Mikä on DKIM? · SPF-tietueen tarkistin · DNS-tietoturva-asetukset
