Defaults.Exposed › Korjaukset › Guides

DMARC p=none:sta p=reject:iin ilman laillisen sähköpostin menettämistä: Vaiheistettu käyttöönotto (2026)

Julkaistu 2026-07-08

Luvut päivätty 2026-06-29 · metodologia v7. Aggregoitu väestölaskentadata 261 miljoonan arvioidun verkkotunnuksen yli. Katso miten arvioimme.

Siirry DMARC p=none:sta p=reject:iin neljässä vaiheessa: seuraa rua-raportteja 2–4 viikkoa, korjaa jokainen laillinen lähettäjä, nosta p=quarantine pct:llä, sitten hylkää — älä koskaan hyppää suoraan reject:iin. 70,368,600 261,086,232:sta arvioidusta verkkotunnuksesta istuu pysähtyneenä pehmeässä SPF:ssä ilman DMARC-valvontaa Defaults.Exposed-palvelun väestölaskennan mukaan.

Tämä on operatiivinen ohjekirja: vaihdetaulukko poistumisehtojen kanssa, tietue jokaiselle vaiheelle, RFC 7489:n pct-hienovaraisuus joka muuttaa mitä “50%” tarkoittaa reject:issä, ja sp=-tunniste aliverkkotunnuksille. Jos päätät harkitaanko valvonnan ottamista käyttöön, lue DMARC-kypsyyden 6 vaihetta ensin — se on viitekehys; ja jos käytäntötasot itsessään ovat uusia, mitä p=none, p=quarantine ja p=reject todella tarkoittavat on alustus. Tämä sivu on tekeminen.

Miksi et voi hypätä suoraan p=reject:iin?

Koska p=reject käskee jokaista noudattavaa vastaanottajaa hylkäämään DMARC:ssa epäonnistuvan postin — ja ennen kuin olet katsonut raporttiasi, et tiedä mikä epäonnistuu. Lähes jokainen verkkotunnus, joka kytkee seurannan päälle, löytää unohtamansa lailliset lähettäjät: CRM:n, laskutusohjelmiston, yhteydenottolomakkeen. Hyppää reject:iin päivänä yksi ja kyseinen posti ei mene roskapostiin; se katoaa SMTP-tasolla. Laskutusajon menettäminen opettaa organisaatiolle pelkäämään DMARC:ia, ja tietue palautetaan pysyvästi p=none:een — 261,086,232 arvioidusta verkkotunnuksesta, 37,312,637 on pysäköity täsmälleen sinne, ja vain 10.59% (27,640,987) saavuttaa koskaan valvotun käytännön.

Toinen syy on linjautuminen. DMARC läpäisee vain kun SPF tai DKIM läpäisee ja linjautuu näkyvän From-verkkotunnuksen kanssa — SPF Return-Path (RFC5321.MailFrom) -verkkotunnusta vastaan, DKIM allekirjoituksen d=:ää vastaan. Kolmannen osapuolen lähettäjät läpäisevät SPF:n yleensä omalla verkkotunnuksellaan, ei sinun, minkä vuoksi korjaa-jokainen-lähde-vaihe koskee pääasiassa jokaisen toimittajan oman verkkotunnuksen DKIMin ottamista käyttöön — purettu DMARC epäonnistuu mutta SPF ja DKIM läpäisevät -oppaassa.

Mitkä ovat neljä käyttöönottoa vaihetta?

Tiedot päivätty 2026-06-29; käytäntökäyttäytyminen RFC 7489:n mukaan.

Vaihe 3 on missä verkkotunnukset pysähtyvät tai panikoivat. Roskapostittelu on palautettavissa — käyttäjät löytävät postin, löysäät pct:tä, korjaat lähteen. Hylkäys ei ole palautettavissa, minkä vuoksi puhdas karanteeni pct=100:lla on pääsylippu vaiheeseen 4.

Miten ajat käyttöönoton vaihe vaiheelta?

1. Aja ilmainen skannaus osoitteessa defaults.exposed ennen DNS:n koskemista. Se vahvistaa nykyisen käytäntösi ja onko SPF ja DKIM alla — kaksi jalkaa, joiden varassa valvonta seisoo.
2. Kytke seuranta päälle jos et ole jo. p=none julkaiseminen rua=:lla on viiden minuutin vaihe kohdassa “DMARC-käytäntöä ei ole otettu käyttöön”. Kerää 2–4 viikkoa raportteja — tarpeeksi kuukausittaisten lähettäjien, kuten laskutusajojen, kiinniottamiseksi.
3. Inventoi kaikki raporteissa olevat lähteet. Lajittele lähettäjät omiin, toimittajien ja tuntemattomiin. Raa’at raportit saapuvat XML:nä — raporttinkäsittelytyökalu (tai tarjoajan hallintapaneeli) muuttaa ne luettavaksi lähettäjäinventaariksi.
4. Saa jokainen laillinen lähde läpäisemään linjautuneesti. Ota käyttöön jokaisen toimittajan oman verkkotunnuksen DKIM (yleensä kaksi CNAME-tietuetta heidän hallintapaneelissaan) jotta allekirjoitukset kantavat verkkotunnuksesi, ei heidän. Suosi DKIMia linjautumisessa: se selviää edelleenlähetyksestä, SPF ei.
5. Odota puhdasta kahta viikkoa. Poistu vaiheesta 2 vasta kun raportoitujen epäonnistumisten joukossa on yksinomaan liikennettä, jota et tunnista — huijaus, jonka haluat estää.
6. Siirry p=quarantine; pct=10:een — muokkaa olemassa olevaa _dmarc-TXT-tietuetta (käytännön esimerkki: IONOS DMARC -asennus), ja vaali syntaksia: kirjoitusvirhe käytäntötagissa voi mitätöidä tietueen kokonaan. Nosta pct:tä 25:een, 50:een, 100:een 2–4 viikon aikana, seuraten raportteja ja helpdesktiketejä. Mitä tahansa laillista roskapostissa: laske pct takaisin, korjaa lähde, jatka.
7. Siirry p=reject:iin 1–2 puhtaan viikon jälkeen pct=100:lla. Pidä rua= päällä pysyvästi — jokainen uusi työkalu, jonka yrityksesi ottaa käyttöön, on tuleva epäonnistuva lähettäjä.

Mitä pct oikeasti tekee? RFC 7489:n hienovaraisuus

pct pyytää vastaanottajia soveltamaan käytäntöäsi kyseiseen prosenttiosuuteen epäonnistuvasta postista. Hienovaraisuus RFC 7489 §6.6.4:stä: posti, joka otetaan pois otoksesta, ei palaa “toimita normaalisti” -tilaan — se saa seuraavaksi vähemmän vakavan käytännön. p=quarantine; pct=25:n alla muut 75% käsitellään p=none:na ja toimitetaan. Mutta p=reject; pct=50:n alla muut 50% karanteenisoidaan, ei toimiteta. Ei ole lempeää hylkäystä: heti kun tietueesi sanoo reject, jokainen epäonnistuva viesti on vähintään roskapostilokeroon noudattavilla vastaanottajilla.

Tarkoituksella käytettynä se on ominaisuus — p=reject; pct=1 käyttäytyy kuten “karanteeninoi lähes kaikki, hylkää pieni tihku”, laillinen viimeinen ramppi. Kaksi varoitusta: vastaanottajat eivät kaikki toteuta otantaa samalla tavalla, joten käsittele pct:tä karkeana säätönä; ja poista tunniste (tai aseta pct=100) kun vaihe 4 on vakaa, jotta tietueesi sanoo mitä tarkoitat.

Entä aliverkkotunnukset — sp=-tunniste?

Oletuksena aliverkkotunnukset perivät organisaatioiden verkkotunnuksen käytännön: p=reject kohdassa sinunverkkotunnuksesi.com kattaa myös mail.sinunverkkotunnuksesi.com. sp=-tunniste antaa niiden poiketa, molempiin hyödyllisiin ja vaarallisiin suuntiin. Hyödyllistä: p=quarantine; sp=reject lukitsee aliverkkotunnukset, joilta et koskaan lähetä, samalla kun huipputaso on vielä kesken rampissa — huijaat kohdistavat tarkoituksella seurattujen verkkotunnusten aliverkkotunnuksiin. Vaarallista: unohtunut sp=none vapauttaa hiljaisesti jokaisen aliverkkotunnuksen kuudessa viikossa ansaitsemastasi hylkäyskäytännöstä. Tarkista se vaiheessa 4; jos yhdellä aliverkkotunnuksella todella tarvitaan löysempi käytäntö, julkaise _dmarc-tietue kyseisellä aliverkkotunnuksella sen sijaan, että löysäät niitä kaikkia.

Tarkoittaako NIS2, että EU-yritysten on tehtävä tämä?

DMARC toimii samalla tavalla kaikkialla — mikään tässä ohjekirjassa ei muutu EU-rajalla. Mitä muuttuu on vaatimustenmukaisuusvoima. NIS2 artikla 21(2)(j) vaatii soveltamisalan yrityksiä turvaamaan viestintänsä, ja komission täytäntöönpanoasetus (EU) 2024/2690 täsmentää tekniset vaatimukset digitaalisen infrastruktuurin tahoille — sen liitteen (kohta 6.7.2(k)) mukaan vaaditaan toteutussuunnitelma kansainvälisesti sovittujen sähköpostin tietoturvastandardien käyttöönotolle, ja kohta 6.7.2(l) vaatii DNS-tietoturvan parhaita käytäntöjä. Valvottu DMARC-käytäntö, SPF:n ja DKIMin kanssa alla, on tunnustettu auditoitava kontrolli väärennöstä vastaan; p=none on todistettavasti seuranta, ei suojaus. Jos asiakkaasi ovat soveltamisalassa, heidän toimittajakyselynsä kysyvät yhä useammin täsmälleen tätä.

Usein kysytyt kysymykset

Kuinka kauan koko käyttöönotto kestää? Kuudesta kymmeneen viikkoa on tyypillistä: 2–4 viikkoa seurantaa, 1–3 viikkoa lähteiden korjausta, 2–4 viikkoa karanteenin nostoa, sitten hylkäys. Se on kalenteriaikaa, ei vaivannäköä — pääasiassa raportien odottamista jokaisen muutoksen vahvistamiseksi. 89.41% 261,086,232:sta arvioidusta verkkotunnuksesta ilman valvottua käytäntöä (tiedot päivätty 2026-06-29) ei pääasiassa ole käyttöönototon puolivälin — ne eivät koskaan aloittaneet kelloa.

Voinko ohittaa karanteenin ja käyttää p=reject:iä matalalla pct:llä sen sijaan? Voit — RFC 7489 §6.6.4:n mukaan, p=reject; pct=10 tarkoittaa 10% hylättyä ja 90% karanteenissa, karkeasti vaiheen 3 loppua. Mutta p=quarantine ensin on helpompi hahmottaa, ja vastaanottajat vaihtelevat siinä kuinka uskollisesti ne ottavat otoksia. Kummassakin tapauksessa vaiheet 1–2 ovat neuvottelemattomat: mikään valvontatyyppi ei ole turvallinen kun lailliset lähettäjät epäonnistuvat edelleen.

Entä posti, jota en voi korjata — edelleenlähettäjät ja postituslistat? Edelleenlähetys rikkoo SPF:n rakenteellisesti, ja jotkut postituslistat kirjoittavat sisällön uudelleen, rikkoen myös DKIMin. Linjautunut DKIM selviää tavallisesta edelleenlähetyksestä, joka hoitaa useimman; pieni jäänne on syy, miksi karanteenivaihe on olemassa — roskapostilokeroon joutunut posti on palautettavissa kun arvioit vaikutusta. Yksityiskohdat kohdassa edelleenlähetetty posti epäonnistuu SPF:ssä.

Riittääkö pysähtyminen p=quarantine:een? Se on suurin osa arvosta, ja paljon parempi kuin 37,312,637 verkkotunnusta pysäköitynä p=none:een (261,086,232 arvioidusta, tiedot päivätty 2026-06-29) — mutta huijattu posti pääsee edelleen roskapostikansioihin, joista ihmiset kalastelevat sitä. Hylkäys on päätepiste: vain 10.59% arvioiduista verkkotunnuksista valvoo ylipäänsä, ja loppuun suorittaminen on se mitä tarkistimet, vakuuttajat ja kyselyt kirjaavat.

Lähetä omistajalle raportti

Jos ajat tätä käyttöönottoa asiakkaalle tai työnantajalle, maaliviiva on näytettävissä. Aja ilmainen skannaus uudelleen kun p=reject on levinnyt ja lähetä arvioitu raportti: verkkotunnus siirtymässä valvottuun käytäntöön, aikaleimattu ja selkokielellä. Tämä yksi sivu vastaa kyberturvallisuusvakuutusten uusimis- ja NIS2-pohjaisten toimittajakyselyjen sähköpostiturvallisuusrivin paremmin kuin DNS-paneelin kuvakaappaus — ja se tekee kuuden viikon huolellisen, näkymättömän työn näkyväksi sille henkilölle, joka maksaa siitä.

Tarkista DMARC-käytäntösi ilmaiseksi

Katso nykyinen käytäntösi — ja voivatko SPF ja DKIM kantaa valvonnan — yksityisesti ja vain omistajalle.

Tarkista verkkotunnuksesi → · Korjaa DMARC → · “DMARC-käytäntöä ei ole otettu käyttöön” — rehellinen ensiaskel → · Vain aggregoitua dataa. Tiedot tallennettu ja käsitelty EU:ssa.