DMARC-kypsyyden 6 vaihetta

Julkaistu 2026-07-03 · päivitetty 2026-07-03

Luvut ajankohtana 2026-06-29 · metodologia v7. Tämä on toistuvaan tutkimukseen (census) pohjautuva viitemalli; jokainen laitos mittaa saman populaation uudelleen, jotta lukuja voi seurata ajan mittaan. Kaikki luvut ovat aggregaatteja — emme koskaan julkaise yksittäisen yrityksen arvosanaa.

DMARC:n julkaiseminen ei ole sama asia kuin suojattuna oleminen

261 miljoonan mitatun verkkotunnuksen joukossa 24.89 % julkaisee DMARC-tietueen — mutta vain 10.59 % pakottaa sen. Toisin sanoen: niistä noin 65 miljoonasta verkkotunnuksesta, jotka aloittivat DMARC-matkan, 57.5 % ei koskaan päässyt siihen osaan, joka estää mitään. Ne julkaisivat tietueen, ohjasivat raportoinnin jonnekin ja pysähtyivät. Pienemmät riippumattomat tutkimukset havaitsevat saman muodon — eräs vuoden 2026 alan raportti arvioi pakottavien osuudeksi ~9 % niiden ~938 000 tarkastelemansa verkkotunnuksen joukossa.

Käyttöönotto ei ole enää ongelma. Suoja on. Ja verkkotunnukset pysähtyvät rakenteellisesta syystä: kartat, joita kaikki käyttävät, loppuvat kesken. Ne päättyvät liian aikaisin, eikä yksikään niistä anna vaikeimmalle askeleelle omaa nimeään.

Missä olemassa olevat kartat loppuvat kesken

Mallit, joiden mukaan ala suunnistaa, olivat oikeassa aikakaudellaan ja ansaitsevat reilun luennan:

Viisivaiheinen käyttöönottomalli, jonka dmarcian (jonka perustaja oli mukana laatimassa itse DMARC:ia) teki tunnetuksi, kulkee käyttöönotto → seuranta → politiikan tiukennus — ja kohtelee p=reject-tilan saavuttamista määränpäänä.
RFC-eteneminen — p=none → quarantine → reject — on kolme pakotuksen tasoa, ei kypsyysmalli. Se ei kerro mitään edellytyksistä eikä mitään siitä, mitä tulee sen jälkeen.
“Ryömi, kävele, juokse” on kansanomainen malli: suunnaltaan oikea, rakenteeltaan tyhjä.

Kaikilla kolmella on kaksi samaa rajoitusta. Ensinnäkin ne pysähtyvät kohtaan p=reject — ikään kuin pakotus olisi maaliviiva. Se ei ole: itse standardi on siirtynyt eteenpäin (DMARCbis — RFC 9989, 9990 ja 9991 — julkaistiin toukokuussa 2026 korvaten alkuperäisen RFC 7489:n), eikä pakotus tee mitään kuljetusturvallisuudelle tai brändiluottamukselle. Toiseksi — ja tämä on se, joka todella jättää verkkotunnukset jumiin — yksikään niistä ei tee “jokainen lähettäjä huomioitu” -askeleesta nimettyä vaihetta. Rehellisyyden nimissä käyttöönotto-oppaat mainitsevat kyllä työn: dmarcianin malli sisältää lähteiden tunnistamisen tehtävänä seurantavaiheensa sisällä. Mutta vaiheen sisään haudattua tehtävää kohdellaan juuri niin — osana “seurantaa” eikä erillisenä saavutuksena, jota se on. Raporttien saapumisen tarkkailu tuntuu edistymiseltä. Se ei sitä vielä ole. Suurin yksittäinen syy siihen, että verkkotunnukset istuvat p=none-tilassa vuosikausia, on se, että ne voivat nähdä postinsa mutta eivät ole huomioineet sitä — joten ne eivät uskalla pakottaa peläten rikkovansa jotain oikeaa.

Hyödyllisen mallin on annettava tälle askeleelle oma nimensä ja omat poistumiskriteerinsä. Tämä malli tekee niin. Kutsumme sitä nimellä DMARC Adoption Maturity Model — DAMM: kuusi vaihetta, kussakin yksi siirto, ja nimi, johon voit viitata.

Malli

DMARC-kypsyyden kuusi vaihetta — suojaamattomasta koventettuun, muurilla Observing- ja Visibility-vaiheiden välissä

Vaihe 1 — Unprotected (Suojaamaton). Ei DMARC-tietuetta — tai SPF ja DKIM ovat puutteelliset sen alla. Kuka tahansa voi lähettää sähköpostia verkkotunnuksesi nimissä, eikä mikään missään tarkista sitä. Siirto: määritä SPF ja DKIM ensisijaiselle postillesi ja varmista, että ne todentavat ja yhdenmukaistuvat (align). DMARC rakentuu molempien varaan; tätä pohjaa ei voi ohittaa.

Vaihe 2 — Authenticated (Todennettu). SPF ja DKIM ovat oikein ja yhdenmukaistuvat päätoimiselle postivirrallesi. Laillinen postisi todistaa alkuperänsä — mutta mikään ei kerro maailman postilaatikoille, mitä tehdä postille, joka ei todista. Siirto: julkaise DMARC-tietue tilassa p=none ja rua=-raportointiosoitteella.

Vaihe 3 — Observing (Tarkkaileva). DMARC on julkaistu, aggregaattiraportit virtaavat, ja ensimmäistä kertaa näet, kuka lähettää verkkotunnuksesi nimissä. Mitään ei estetä. Useimmat työkalut kutsuvat tätä vaihetta “näkyvyydeksi” — me emme tietoisesti tee niin, koska raporttien näkeminen ja niiden ymmärtäminen ovat eri saavutuksia. Siirto: tunnista jokainen laillinen lähde, joka lähettää verkkotunnuksesi nimissä, ja saa kukin niistä yhdenmukaistettua.

Vaihe 4 — Visibility (Näkyvyys). Jokainen laillinen lähettäjä on tunnistettu ja yhdenmukaistettu — uutiskirjealusta, laskutusjärjestelmä, CRM, se juttu, johon markkinointi kirjautui viime keväänä. Tunnet postisi. Mikään laillinen ei rikkoudu, jos pakotat. Tämä on vaihe, jonka vanhat kartat ohittavat, ja se muuri, jonka yli useimmat verkkotunnukset eivät koskaan kiipeä. Siirto: nosta politiikkaa — p=none → p=quarantine (DMARCbisin t=y-testitila auttaa tässä) → p=reject.

Vaihe 5 — Enforced (Pakotettu). p=quarantine tai p=reject on käytössä, ja alitunnukset (subdomains) katetaan nimenomaisella sp=-politiikalla. Posti, joka epäonnistuu todennuksessa, asetetaan nyt tosiasiallisesti karanteeniin tai hylätään osallistuvilla vastaanottajilla — joihin kuuluu jokainen suuri postilaatikkotarjoaja — joten tarkalleen sinun verkkotunnuksesi suora väärentäminen lakkaa menemästä perille siellä, missä DMARC tarkistetaan. Siirto: lisää kovennuskerros — DMARCbisin np= ja tree-walk-kattavuus, MTA-STS ja TLS-RPT kuljetukselle, BIMI, jos brändinäyttö on sinulle tärkeä.

Vaihe 6 — Hardened & sustained (Koventettu ja ylläpidetty). Pakotus sekä moderni pino: olemattoman alitunnuksen (np=) kattavuus DMARCbisistä, MTA-STS ja TLS-RPT suojaamassa postia kuljetuksen aikana, BIMI siellä missä se ansaitsee paikkansa — ja ratkaisevaa on jatkuva seuranta ajautumisen ja uusien lähettäjien varalta. Tämä ei ole merkki (badge); se on kurinalaisuutta. Uusia lähettäjiä ilmestyy, tarjoajat vaihtavat IP-osoitteita, konfiguraatiot rappeutuvat. Siirto: pysy tässä.

Postittoman kaista. Mitattuna koko verkkotunnusinventaarion yli — kuolleet verkkotunnukset mukaan lukien — 51.5 % verkkotunnuksista ei aja lainkaan postipalvelua, ja niille matka kutistuu yhteen askeleeseen. Verkkotunnuksen, joka ei koskaan lähetä, tulisi julkaista SPF -all ja DMARC p=reject välittömästi: ei ole laillista postia suojattavana, joten ei ole mitään tarkkailtavaa eikä muuria kiivettävänä. Pysäköidyt ja lepäävät brändiverkkotunnukset menevät suoraan Enforced-vaiheeseen yhdellä ainoalla DNS-muutoksella — ja näin toimimalla suljetaan yksi yleisimmistä olemassa olevista henkilöllisyyden väärentämisen vektoreista.

Muuri: vaihe 3 → 4

Jokainen muu siirtymä tässä mallissa on DNS-muutos. Tämä on tutkivaa työtä — ja täällä kuukaudet kuolevat.

Pääseminen Observing-vaiheesta Visibility-vaiheeseen tarkoittaa jokaisen raporteissasi näkyvän lähettävän lähteen kohdistamista todelliseen järjestelmään: mikä ESP, mikä CRM, minkä aluetoimiston postivälitin, mikä SaaS-työkalu, jonka joku yhdisti vuonna 2023 ja unohti. Se tarkoittaa niiden shadow-IT-lähettäjien löytämistä, joita kukaan ei dokumentoinut. Se tarkoittaa yhdenmukaistuksen korjaamista ESP kerrallaan, koska jokaisella alustalla on oma tapansa todentaa puolestasi — jotkin niistä oletuksena väärin.

Muurin ohittaminen on tapa, jolla DMARC sai pelottavan maineensa. Pakota Observing-vaiheesta — ilman Visibilityä — ja tulet estämään jotain oikeaa: laskutusajon, salasanan nollauksen kulun, toimitusjohtajan uutiskirjeen. Sitten seuraa paniikinomainen paluu p=none-tilaan, sisäinen jälkiselvittely ja opetus, jonka kaikki oppivat väärin: “kokeilimme DMARC:ia ja se rikkoi sähköpostin.” Useimmat DMARC-kauhutarinat ovat juuri tätä — pakotusta yritettiin yksi vaihe liian aikaisin. Muuri ei ole syy pysähtyä vaiheeseen 3. Se on syy siihen, että vaihe 4 on olemassa.

Tämä on myös vaihe, jossa omistajat useimmiten ottavat apua — IT-palveluntarjoaja tai DMARC-seurantapalvelu voi tehdä lähettäjien tunnistustyön; vaiheet pysyvät samoina kummallakin tavalla.

Se osa, jonka kaikki unohtavat: vaihe 5 → 6

p=reject-tilan saavuttaminen pysäyttää verkkotunnuksesi suoran väärentämisen From:-rivillä niillä vastaanottajilla, jotka tarkistavat sen. Se on välttämätöntä — eikä se ole riittävää. On myös syytä nimetä se, mitä pakotus ei koskaan kattanut: samannäköiset verkkotunnukset (yourc0mpany.com) ja näyttönimen väärentäminen jäävät kokonaan DMARC:n ulottumattomiin, joten pakotus sulkee tarkan verkkotunnuksen oven ja jättää naapuriovet valppauden ja muiden hallintakeinojen varaan.

Pakotus ei tee mitään kuljetukselle: ilman MTA-STS:ää ja TLS-RPT:tä verkkotunnukseesi menevä posti voidaan yhä alentaa (downgrade) tai siepata kuljetuksen aikana. Se ei tee mitään brändin tunnistamiselle: BIMI — logosi näytettynä postilaatikossa — on luottamussignaali, ei turvakontrolli, ja on rehellistä kohdella sitä sellaisena (se myös vaatii maksullisen varmenteen, minkä vuoksi se on viimeisenä eikä ensimmäisenä). Ja pelkkä p=reject on DMARCbisiä vanhempi: uusien RFC:iden np=-tunniste ja tree-walk sulkevat olemattoman alitunnuksen aukon, jonka vanhemmat käyttöönotot jättävät auki.

Verkkotunnus, joka on p=reject-tilassa mutta ilman mitään edellä mainituista, on suojattu yleisintä hyökkäystä vastaan ja valmistautumaton loppujen varalta. Se on todellinen ero, ja se ansaitsee oman vaiheensa.

Vaiheesi on mitattavissa

Tämä malli ei ole vain kaavio — verkkotunnuksen vaihe on laskettavissa, mikä erottaa sen seinällä olevasta julisteesta.

Vaiheet 3–6 voidaan johtaa verkkotunnuksen omasta DMARC-raportointidatasta sekä sen julkaistuista tietueista: mikä politiikka on käytössä, virtaavatko raportit ja yhdenmukaistuuko jokainen havaittu lähettäjä. Vaiheet 1 ja 2 arvioidaan reaaliaikaisella DNS-tarkistuksella, koska raportteja ei vielä ole. Yksi rehellinen rajoitus kumpaankin suuntaan: vaihe 4 vahvistetaan ajan mittaan kertyneellä näytöllä — “jokainen havaittu lähettäjä yhdenmukaistuu riittävän monen raportointipäivän ajan” on vahva korvike, mutta yksikään raportti ei voi paljastaa lähettäjää, jota et ole vielä yhdistänyt. Ja vaiheen 6 kovennuskerros — MTA-STS, TLS-RPT, BIMI — on näkymätön DMARC-raporteissa; sen näkeminen vaatii DNS-tarkistuksen. Verkkotunnus voi näyttää raporttiensa perusteella “valmiilta” ja silti kantaa piilotettua vaiheen 5 → 6 aukkoa. Tätä mallia vasten oma raportointianalyysimme mittaa, esteineen kaikkineen.

Läpikäyty esimerkki

Keskikokoinen yritys ajaa Microsoft 365:tä postia suodattavan yhdyskäytävän takana. SPF päättyy -all-tilaan, DKIM on määritetty, DMARC on julkaistu tilassa p=none, ja raportit virtaavat seurantatyökaluun. Vanhoilla kartoilla tämä näyttää lähes valmiilta. Tällä kartalla se on vaihe 3 — Observing: vaikea asennus on valmis, ja verkkotunnus on pysähtynyt tarkalleen muurille — näkyvä, ei suojattu. Arvokkain siirto on 3 → 4 → 5: vahvista, että (todennäköisesti harvat) lailliset lähettäjät kaikki yhdenmukaistuvat, ja nosta sitten politiikkaa vaiheittain. Tämän muotoiselle verkkotunnukselle se on yleensä viikkojen, ei kuukausien, huomiota — muuri on korkein niille, jotka eivät koskaan kartoita sitä.

Löydä vaiheesi

Kysymys, joka on syytä jättää eläkkeelle, on “onko meillä DMARC?” — 24.89 % verkkotunnuksista voi sanoa kyllä, kun taas 57.5 % niistä pysyy väärennettävissä. Parempi kysymys on “missä vaiheessa olemme, ja mikä on se yksi siirto seuraavaan?” Jokainen internetin verkkotunnus on tänään tarkalleen yhdessä näistä kuudesta vaiheesta. Sen tietäminen, missä, muuttaa ahdistuksen tehtävälistaksi.

Missä internet sijaitsee kuuden vaiheen halki — useimmilla verkkotunnuksilla ei ole lainkaan DMARC-tietuetta; useimmat niistä, joilla on, ovat jumissa ennen pakotusta

Usein kysytyt kysymykset

Mikä on DAMM? DMARC Adoption Maturity Model — tällä sivulla oleva kuusivaiheinen malli: Unprotected, Authenticated, Observing, Visibility, Enforced, Hardened. Verkkotunnuksen vaihe on mitattavissa sen DNS:stä ja sen DMARC-raportointidatasta, mikä erottaa sen seinällä olevasta julisteesta.

Onko p=none-tilan julkaiseminen sitten arvotonta? Ei — se on vaihe 3, ja vaihe 3 on kantava: raportointi on tapa, jolla löydät jokaisen lähettäjän ennen kuin pakotat. Siitä tulee ongelma vasta, kun sitä kohdellaan määränpäänä. Katso miksi p=none ei ole suojaa.

Voinko hypätä suoraan p=reject-tilaan? Jos verkkotunnuksesi ei lähetä postia — kyllä, tänään, ja sinun tulisi. Jos se lähettää postia — ei: pakottaminen ilman Visibilityä (vaihe 4) on tapa, jolla laillinen posti rikkoutuu ja peruutuksia tapahtuu. Vaiheet ovat turvallinen polku, ei seremonia.

Tarvitsenko BIMI:n ollakseni “valmis”? En. BIMI on vaiheen 6 brändinäyttökerros ja mallin valinnaisin osa — MTA-STS, TLS-RPT ja DMARCbisin np=-kattavuus ovat ne osat, jotka olennaisesti koventavat verkkotunnuksen. Jos varmenteen kustannus ei ole sinulle perusteltu, ohita se ja pidä loput vaiheesta 6.

Mihin SPF ja DKIM sopivat? Kaiken alle — ne ovat vaiheet 1 → 2, ja SPF ilman DMARC:ia suojaa vähemmän kuin useimmat omistajat olettavat. Vuodesta 2024 lähtien suuret vastaanottajat ovat myös vaatineet todennusta suoralta kädeltä joukkolähettäjiltä.

Tarkista, missä oma verkkotunnuksesi seisoo

Nämä vaiheet ovat populaation kuvioita — verkkotunnuksesi on tarkalleen yhdessä niistä, ja seuraava siirto on tiedettävissä. Voit tarkistaa yksityisesti ja ilmaiseksi ja nähdä, minkä 34 tarkistuksesta läpäiset ja miten korjata ne, joita et.

Tarkista verkkotunnuksesi → · Miten arvostelimme internetin → · DMARC-pilari → · Vain aggregaattidataa. Data tallennetaan ja käsitellään EU:ssa.