DMARC p=none tasolta p=quarantine tasolle menettämättä oikeaa postia

DMARC-tietue, jossa on p=none, pyytää sähköpostipalveluja raportoimaan postista, joka ei läpäise todennusta, mutta toimittamaan sen tavalliseen tapaan. Se on oikea paikka aloittaa ja väärä paikka jäädä: kuka tahansa voi yhä lähettää postia verkkotunnuksenne ollessa Lähettäjä-kentässä, eikä vastaanottajilla ole teiltä ohjetta pitää sitä epäilyttävänä.

Siirtyminen tasolle p=quarantine kertoo vastaanottajille, että tarkistuksessa hylätty posti on epäilyttävää, mikä käytännössä tarkoittaa yleensä roskapostikansiota. Riski ei ole itse muutos. Riski on oikea palvelu (laskutus, asiakastuki, CRM, uutiskirje), joka ei vielä vaihtopäivänä läpäise DMARC-tarkistusta, jolloin omat viestinne päätyvät roskapostiin.

Lyhyesti: lukekaa koosteraportteja, kunnes jokainen oikea lähettäjä läpäisee tarkistuksen kohdistetulla DKIM:llä, siirtykää ensin tasolle p=quarantine testitilassa, vertailkaa raportteja ja luopukaa testitilasta vasta sitten. Yksityiskohdat alla. Jos haluatte kerrata 3 tietuetta, lukekaa SPF, DKIM ja DMARC selitettynä.

Mitä p=none todella tekee

DMARC on nykyään määritelty standardissa RFC 9989, joka julkaistiin toukokuussa 2026 ja korvasi RFC 7489:n. Se kutsuu tasoa p=none nimellä Monitoring Mode ja selittää, miksi se on olemassa: kaikissa paitsi yksinkertaisimmissa ympäristöissä verkkotunnuksen omistaja voi unohtaa palvelimen tai kolmannen osapuolen lähetyssopimuksen, ja raportit paljastavat sen.

Arvo quarantine tarkoittaa, että verkkotunnuksen omistaja pitää hylättyä postia epäilyttävänä. Lopullinen päätös jää vastaanottajalle, mutta useimmilla sähköpostipalveluilla se tarkoittaa roskapostikansiota. Google kuvaa sen suoraan suositellussa DMARC-käyttöönotossaan: viestit, jotka eivät läpäise DMARC-tarkistusta, menevät vastaanottajan roskapostikansioon.

Vaihe 1: jokainen oikea lähettäjä läpäisee tarkistuksen

RFC 9989 on järjestyksestä suora. Oikeat postivirrat, jotka eivät läpäise tarkistusta kohdistamattomien tai puuttuvien tunnisteiden vuoksi, on korjattava ennen kuin julkaisette pakottavan käytännön.

Käykää koosteraportit läpi (oppaamme DMARC-koosteraportin lukemisesta selittää XML:n) ja listatkaa jokainen lähde:

• Pääasiallinen sähköpostipalvelunne: sen pitää läpäistä tarkistus kohdistetulla DKIM:llä ja SPF:llä.
• Jokainen kolmannen osapuolen työkalu, joka lähettää verkkotunnuksenne nimissä: kytkekää sen asetuksista päälle DKIM-allekirjoitus omalla verkkotunnuksellanne. Työkalu, joka läpäisee vain SPF:n omalla kirjekuoriverkkotunnuksellaan, ei ole kohdistettu ja hylätään DMARC-tarkistuksessa.
• Edelleenlähetykset ja postituslistat: nämä rikkovat usein SPF:n. DKIM-allekirjoitukset pysyvät yleensä voimassa, kun posti välitetään eteenpäin, mikä on yksi syy nojata DKIM:iin eikä pelkkään SPF:ään.
• Tuntemattomat lähteet, jotka hylätään: juuri nämä uusi käytäntö on tarkoitettu pysäyttämään.

Seurannan pituus on teidän päätöksenne. Google suosittelee vähintään 1 viikkoa tasolla p=none, koska se riittää yleensä kattamaan kaikki postivirtanne raporteissa. RFC 9989 huomauttaa, että lähetystiheydestä riippuen se voi viedä useita kuukausia. Ajatelkaa postia, jota lähetätte kerran neljännesvuodessa tai kerran vuodessa: palkkailmoitukset, vuosilaskut, uusimismuistutukset. Jos niitä ei vielä näy raporteissanne, ette ole nähneet niiden läpäisevän tarkistusta.

Vaihe 2: vaihto ensin testitilassa

RFC 7489:n aikana tavallinen tapa edetä varovasti oli pct-tagi (käytäntö sovelletaan prosenttiosuuteen hylätystä postista). RFC 9989 poisti pct-tagin, koska vastaanottajat soveltivat muita arvoja kuin 0 ja 100 epäjohdonmukaisesti. Sen tilalla on testitilan tagi t:

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

Tagilla t=y pyydätte vastaanottajia soveltamaan 1 tasoa ilmoitettua käytäntöä lievempää, joten p=quarantine; t=y käsitellään kuin none, mutta välittäjät, kuten postituslistat, voivat jo mukauttaa postinne käsittelyä. Tagi ei muuta raportointia. Vertailkaa raportteja ennen ja jälkeen: ne näyttävät, kuinka suuri osa postistanne kulkee välittäjien kautta, jotka hylättäisiin käytännön tullessa voimaan.

Osa palveluista dokumentoi yhä vanhemman prosenttitavan; esimerkiksi Googlen käyttöönotto-ohje näyttää aloitusarvona pct=5. Vastaanottajat, jotka eivät vielä tue t-tagia, yksinkertaisesti ohittavat sen, joten pitäkää testitilaa pehmeänä aloituksena, ei turvaverkkona.

Vaihe 3: käytäntö voimaan ja seuranta jatkuu

Kun testitilan raportit näyttävät puhtailta, tagi poistetaan:

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

Ensimmäisinä viikkoina muutoksen jälkeen:

• Lukekaa raportit päivittäin ja etsikää disposition-arvoa quarantine lähteillä, jotka tunnistatte.
• Pyytäkää asiakkaille postia lähettäviä tiimejä (talous, myynti, tuki) kertomaan, jos vastauksia tulee vähemmän tai asiakkaat sanovat postin päätyneen roskapostiin.
• Käsitelkää jokaista uutta verkkotunnuksenne nimissä lähettävää työkalua muutospyyntönä: DKIM omalla verkkotunnuksellanne ennen käyttöönottoa.
• Pitäkää DNS-käyttöoikeudet järjestyksessä. DMARC-tietue, jonka avulias alihankkija hiljaa palauttaa tasolle p=none, kumoaa koko työn.

Aliverkkotunnukset ja verkkotunnukset, jotka eivät lähetä mitään

Ilman sp-tagia p-käytäntö koskee myös aliverkkotunnuksia. Jos aliverkkotunnus lähettää markkinointipostia erillisestä alustasta, katsokaa se raporteista ennen vaihtoa tai luokaa sille oma _dmarc-tietue. np-tagi asettaa käytännön aliverkkotunnuksille, joita ei ole lainkaan olemassa, mikä on yleinen valinta nimille, joista kenenkään ei pitäisi koskaan lähettää postia.

Verkkotunnukset, jotka omistatte mutta joita ette koskaan käytä postiin (vanhat tuotenimet, puolustavat rekisteröinnit), ovat helppo tapaus: koska oikeita lähettäjiä ei ole, ne voivat siirtyä suoraan pakottavaan käytäntöön. Juuri nämä verkkotunnukset houkuttelevat väärennettyjen laskujen huijauksiin, koska kukaan ei seuraa niitä.

Ennen kuin jatkatte tasolle p=reject

p=reject on seuraava askel, mutta RFC 9989 suhtautuu siihen varovasti verkkotunnuksissa, joiden käyttäjät kirjoittavat postituslistoille. Se suosittelee tasoa p=none vähintään kuukauden ajan ja sitten tasoa p=quarantine yhtä pitkään sekä tulosten vertailua ensin. Suuret sähköpostipalvelut edellyttävät jo DMARC:ia joukkolähettäjiltä, kuten artikkelissa Gmailin ja Yahoon lähettäjävaatimukset kerrotaan, joten vakaa p=quarantine on jo sellaisenaan vahva asema.

Lyhyt tarkistuslista

• Koosteraportteja on kerätty niin kauan, että harvinaisetkin postivirrat näkyvät.
• Jokainen oikea lähettäjä läpäisee DMARC-tarkistuksen kohdistetulla DKIM:llä.
• p=quarantine; t=y on julkaistu ja raportteja vertailtu ennen ja jälkeen.
• Testitila on poistettu ja raportteja luetaan päivittäin ensimmäisten viikkojen ajan.
• Aliverkkotunnukset ja käyttämättömät verkkotunnukset on katettu sp- tai np-tagilla tai omilla tietueillaan.

Missä Guarding auttaa

Kun käytäntönne on voimassa, suurin riski on, että se hiljaa muuttuu takaisin. Valvomme SPF-, DKIM- ja DMARC-tietueitanne ja muuta, mitä vartioimme, ulkopuolelta joka päivä menemättä järjestelmiinne. Jos tietuetta heikennetään tai DKIM-valitsin katoaa, ihminen tarkistaa asian ja saatte tarkan muutoksen, joka on tehtävä, kuten kerrotaan kohdassa mitä tapahtuu, kun löydämme jotain. Esimerkkinäkymä näyttää, miltä se näyttää.