Mitä DMARCissa muuttui RFC 9989:n myötä ja mitä nyt pitää tehdä?

RFC 9989 (toukokuu 2026) on nykyinen DMARC-standardi. Se korvaa vuonna 2015 julkaistun RFC 7489:n, jota useimmat ohjeet yhä kuvaavat. Luonnoksena sen nimi oli DMARCbis. Uutta tietuetta et tarvitse: v=DMARC1 on edelleen ainoa versio, ja postilaatikkopalvelu ohittaa tagin, jota se ei tunne. Muutokset koskevat muutamaa tagia. pct poistuu, ja uusi t-tagi hoitaa sen testauskäytön. np asettaa käytännön aliverkkotunnuksille, joita ei ole olemassa, ja psd on tarkoitettu rekistereille, jotka ylläpitävät päätteitä kuten .com. Samaan aikaan julkaistu RFC 9990 määrittää koontiraporttien muodon.

Mikä muuttui

• Se on nyt standardi. RFC 7489 julkaistiin vain tiedoksi. RFC 9989 kuuluu internetstandardien sarjaan (Standards Track).
• Kolme tagia tuli ja kolme lähti. np, psd ja t ovat uusia. pct, rf ja ri poistettiin. Muut tagit, kuten p, sp, rua ja ruf, tarkoittavat samaa kuin ennen.
• Organisaatiotason verkkotunnus haetaan DNS:stä. RFC 9989:ää noudattava postilaatikkopalvelu ei enää etsi sitä julkisten päätteiden luettelosta (Public Suffix List). Se kulkee verkkotunnuksesi nimeä ylöspäin osa kerrallaan ja kysyy DMARC-tietueita. RFC kutsuu tätä nimellä DNS tree walk.
• Raporteilla on omat dokumenttinsa. Koontiraporteista kertoo RFC 9990 ja failure-raporteista, joita me kutsumme forensic-raporteiksi, RFC 9991.
• Reject saa varoituksen. RFC 9989 pyytää, että verkkotunnukset, joiden käyttäjät saattavat kirjoittaa postituslistoille, jättävät p=reject-käytännön julkaisematta tai siirtyvät siihen vasta, kun ne ovat olleet vähintään kuukauden none-käytännössä ja yhtä kauan quarantine-käytännössä. Kohta Reject ja postituslistat kertoo tarkemmin.

Mailmoni-palvelun tietueen muodostin jättää ri- ja rf-tagit pois ehdottamastaan tietueesta ja kertoo siitä kummastakin erikseen.

pct poistuu

RFC 7489:ssä pct rajasi käytännön osaan läpäisemättömästä postista, jotta verkkotunnus voisi siirtyä quarantine- tai reject-käytäntöön vähitellen. RFC 9989 poistaa tagin. Sen liite A.6 kertoo syyn: tagia sovellettiin yleensä epätarkasti, ellei arvo ollut 0 tai 100 (oletus), ja epätarkkuus vaihteli paljon toteutuksesta toiseen. DMARC-tagien rekisteri luokittelee pct:n nyt historialliseksi.

Mitä sille kannattaa tehdä:

• Ei pct-tagia tai pct=100. Ei mitään. pct=100 tarkoittaa samaa kuin tagin puuttuminen, joten voit jättää sen tai poistaa sen.
• pct välillä 1–⁠99. Älä luota siihen, että se rajaa vahinkoa. Ennen kuin julkaiset sen, varaudu siihen, että käytäntö koskee kaikkea läpäisemätöntä postia.
• pct=0. Osa postituslistoista ja postilaatikkopalveluista on pitänyt sitä merkkinä kirjoittaa viestiesi From-osoite uudelleen. RFC 9989 säilyttää tämän käytön uudella nimellä: alla kuvatulla t-tagilla.

Mailmoni-palvelun käytännön portaissa toinen askel on p=quarantine; pct=25. Valmiuden sääntö on sama joka askeleella, joten kun verkkotunnus on valmis tähän askeleeseen, sen lähteet läpäisevät jo niin hyvin kuin täysi quarantine vaatii. Valmius-sivu laskee, kuinka moni viesti ei läpäissyt DMARC-tarkistusta, ja arvioi sitten askeleen osuuden perusteella, kuinka monta niistä se siirtäisi roskapostiin. Pidä ensimmäistä lukua ylärajana sille, mitä askel voi siirtää roskapostiin. DNS-tarkistus varoittaa, kun pct on alle 100, tällä löydöksellä. Tietueet-välilehden tietueen muodostin tarjoaa pct-kenttää ja jättää tagin pois arvolla 100, ellei tietueessasi jo ole sitä.

t merkitsee käytännön testiksi

t=y pyytää postilaatikkopalveluja soveltamaan käytäntöä yhtä astetta lievempänä kuin tietueessa lukee: p=quarantine; t=y käsitellään kuten none ja p=reject; t=y kuten quarantine. Oletusarvo t=n soveltaa käytäntöä sellaisenaan. RFC 9989:n mukaan tagi ei vaikuta DMARC-raporttien laatimiseen eikä mihinkään käytäntöön (p, sp tai np), jonka arvo on none. Käytännön sijaan RFC pyytää viestin tarkistajaa soveltamaan omia erityissääntöjään, esimerkiksi kirjoittamaan uudelleen RFC5322.From-otsakkeen. Se on From-osoite, jonka vastaanottaja näkee. Liitteen A.6 mukaan t=y ja t=n on tarkoitettu toimimaan kuten pct=0 ja pct=100.

Postilaatikkopalvelu, joka noudattaa yhä RFC 7489:ää, ei tunne t-tagia. RFC 7489:n mukaan tuntemattomat tagit on ohitettava, joten tällainen palvelu soveltaa käytäntöäsi sellaisenaan. Julkaise t=y vain sellaisen käytännön kanssa, jonka voisit hyväksyä täysimääräisenä, ja poista tagi, kun haluat käytännön voimaan kaikkialla.

Mailmoni-palvelun DNS-tarkistus lukee t-tagin. Kun tietueessa on t=y, DMARC-kortti kertoo käytännön olevan testitilassa ja sen, mitä käytäntöä RFC 9989:ää noudattavat postilaatikkopalvelut soveltavat sen sijaan. Valmius laskee käytännön yhtä astetta lievemmäksi, kuten nämä palvelut tekevät, joten käytäntöä p=reject; t=y ei lasketa rejectiksi. Tietueen muodostimessa on testitilan valintaruutu, joka on valittuna, kun tietueessasi on t=y. Valmiuden tarjoama seuraavan askeleen tietue poistaa testitilan. t-tagin muutos tietueessasi laukaisee DMARC-käytäntö muuttui -hälytyksen.

np koskee aliverkkotunnuksia, joita ei ole

np asettaa käytännön postille, jonka From-osoitteessa on aliverkkotunnus, jota DNS:ssä ei ole, esimerkiksi keksitty laskutus.example.com. Sen arvot ovat samat kuin p-tagilla. Ilman sitä tällaiset nimet noudattavat sp-tagia ja ilman sp-tagia p-tagia. Nimeä ei ole olemassa, kun DNS vastaa, ettei sen kohdalla tai alla ole mitään. Nimi, jolla on yksikin tietue, vaikka vain verkkosivun osoite, on olemassa, ja sitä koskee sp tai p. RFC 9989 ottaa np-tagin RFC 9091:stä, kokeilusta, jonka se korvaa.

Mitä sille kannattaa tehdä:

• Harkitse arvoa np=reject jo varhain. Se koskee vain DMARC-tarkistusta läpäisemätöntä postia nimistä, joita ei ole olemassa. Voit siis lisätä sen, vaikka oma verkkotunnuksesi on vielä none-käytännössä.
• Tarkista ensin aliverkkotunnuksesi. Mikään palvelu ei saisi lähettää puolestasi postia aliverkkotunnuksesta, jolla ei ole omia DNS-tietueita. Aliverkkotunnus, josta lähetetään postia nimissäsi, näkyy Mailmoni-palvelussa verkkotunnuksesi alla, kun se on ollut raportissa.
• Kirjoita arvo oikein. Kohdan 4.10.1 mukaan postilaatikkopalvelu käsittelee koko tietuetta kuin siinä lukisi p=none, jos np- tai sp-tagin arvo ei kelpaa ja rua-tagissa on kelpaava osoite. Kirjoitusvirhe np-tagissa kytkee siis voimassa olevan käytäntösi pois. Jos DNS-tarkistus kertoo, että np-tagisi ei kelpaa, korjaa se DNS:ään.

Mailmoni-palvelun DNS-tarkistus lukee np-tagin ja näyttää sen tietueessasi. Jos arvo on muu kuin none, quarantine tai reject, tarkistus varoittaa, että tagi ei kelpaa. Tietueen muodostimessa ei ole np-kenttää, joten lisää tagi käsin. Kun muodostin päivittää tietueesi, se säilyttää kelpaavan np-tagin sellaisenaan ja jättää kelpaamattoman pois. Siitä se kertoo erikseen. Raportin sivu näyttää np-tagin, kun raportti ilmoittaa sen, ja np-tagin muutos tietueessasi laukaisee DNS-tietue muuttui -hälytyksen.

psd on rekistereitä varten

psd kertoo, kuuluuko DMARC-tietue julkiselle päätteelle eli nimelle, jonka alle muut rekisteröivät verkkotunnuksiaan, kuten .com tai .co.uk. RFC 9989 tarvitsee sitä DNS tree walkin takia. Kun postilaatikkopalvelu etsii organisaatiotason verkkotunnusta, se kysyy DMARC-tietueita nimi kerrallaan From-verkkotunnuksesta ylöspäin ja pysähtyy tietueeseen, jossa lukee psd=y tai psd=n.

• psd=y on julkisten päätteiden ylläpitäjiä varten.
• psd=n kertoo, että verkkotunnus ei ole julkinen pääte, vaan organisaatiotason verkkotunnus itselleen ja aliverkkotunnuksilleen.
• Oletusarvo psd=u jättää vastauksen tree walkin ratkaistavaksi.

Yrityksen verkkotunnus ei tarvitse mitään näistä, joten jätä psd pois. Jos tietueessasi on se, tietueen muodostin säilyttää sen sellaisenaan.

Reject ja postituslistat

RFC 9989 suhtautuu rejectiin varovaisemmin kuin RFC 7489. Kohta 7.4 sanoo, että verkkotunnusten, joiden käyttäjät saattavat kirjoittaa postituslistoille, ei pitäisi julkaista p=reject-käytäntöä (SHOULD NOT). Jos tällainen verkkotunnus haluaa silti rejectin, sen pitäisi ensin oppia raporteistaan: julkaista p=none vähintään kuukaudeksi ja sen jälkeen p=quarantine yhtä pitkäksi ajaksi.

Syy on postituslistojen edelleenvälitys. Viesti, jonka lista lähettää eteenpäin From-osoitteesi kanssa, voi jäädä DMARC-tarkistuksessa läpäisemättä, ja RFC toteaa, että tällainen posti hylätään usein p=reject-käytännön vuoksi. Sama kohta kieltää postilaatikkopalveluja hylkäämästä postia pelkän p=reject-käytännön perusteella ja käskee käsittelemään sen quarantinena, kun muuta tietoa ei ole.

Jos siis yrityksesi ihmiset kirjoittavat postituslistoille työosoitteestaan, quarantine voi olla oikea paikka pysähtyä. Mailmoni-palvelun käytännön portaat päättyvät rejectiin. Valmiussäännön tarkastelujakso on oletuksena 14 päivää. Jos haluat antaa jokaiselle askeleelle kuukauden, kuten RFC pyytää, odota ennen askelta pidempään. Pro-paketista alkaen ylläpitäjä voi myös pidentää tarkastelujaksoa verkkotunnuksen Valmius-sivulla, ja jakso voi olla enintään 30 päivää. Edelleenvälitettyä postia koskeva ohje kertoo, miltä listojen posti näyttää raporteissasi.

Mitä RFC 9990 muuttaa raporteissa

RFC 9990 määrittää koontiraporttien muodon, joka oli ennen osa RFC 7489:ää. Raportti on yhä XML-tiedosto, ja se pitäisi pakata gzipillä. Tiedostossa on uutta:

• policy_published sisältää np-elementin, testing-elementin eli t-tagin arvon sekä discovery_method-elementin. Viimeksi mainitun arvo on psl tai treewalk, ja se kertoo, miten postilaatikkopalvelu löysi tietueesi. pct-elementtiä siinä ei ole.
• Rivin disposition voi olla arvojen none, quarantine ja reject lisäksi pass.
• Ohitussyy voi olla policy_test_mode: viesti säästyi t=y-tagin ansiosta. RFC 7489:n syyt forwarded ja sampled_out poistuivat.
• Jokainen raportin DKIM-allekirjoitus kertoo valitsimensa.
• Yksi raportti koskee yhtä verkkotunnusta, jolla on DMARC-tietue. Aliverkkotunnus, jolla on oma tietue, saa omat raporttinsa.
• Tiedostossa voi olla version-elementti arvolla 1.0 ja generator-elementti, joka nimeää raportin kirjoittaneen ohjelman.

Mailmoni-palvelu lukee molempia muotoja, ja sen lähteet, selitykset ja valmius käsittelevät niitä samalla tavalla. Rivi, jonka disposition on pass, näkyy muodossa ”ei sovellettu” kuten none: postilaatikkopalvelu ei soveltanut siihen käytäntöä.

• Raportin sivu näyttää raportin ilmoittaman käytännön ja myös np-tagin, kun se on mukana. RFC 9990 -raportissa ei ole pct-elementtiä, joten sivulla näkyy oletusarvo pct=100.
• API palauttaa testing-arvon raportin käytännön mukana ja verkkotunnuksen yhteenvedon käytännön mukana.
• Ohitussyyt, myös policy_test_mode, näkyvät sellaisinaan, kun painat rivin Selitä-painiketta, ja viennin override_reasons-sarakkeessa.
• Jokainen valitsin, jonka raportti kertoo omasta verkkotunnuksestasi, lisätään DNS-tarkistuksen luetteloon, joten DKIM-tarkistus etsii avainta sen alta.