Yrityksen DMARC-käytännön lukeminen kymmenessä sekunnissa (ja mitä se ei kerro)

Yksi DNS-tiedustelu kertoo, mitä yritys on pyytänyt maailman postiservereitä tekemään sen nimissä lähetetyillä väärennetyillä kirjeillä. Tietue on julkinen, ja komento on yksi rivi: dig +short TXT _dmarc.example.com. Takaisin tulee lyhyt asetusjonoinen, ja sisällä on yksi käsky — p=none, p=quarantine tai p=reject — joka ilmaisee verkkotunnuksen omistajan mieltymyksen, kun viesti, joka käyttää kyseistä verkkotunnusta, epäonnistuu todentamisessa.

Nykyisen määrittelyn RFC 9989, joka julkaistiin toukokuussa 2026 IETF Standards Track -asiakirjana, korvasi vanhemman RFC 7489:n. Se määrittelee kolme arvoa melko niukasti:

• p=none — "Verkkotunnuksen omistaja ei ilmaise mitään mieltymystä."
• p=quarantine — "Verkkotunnuksen omistaja pitää tällaisia viestejä epäilyttävinä. On mahdollista, että viesti on kelvollinen, vaikka epäonnistuminen herättää huomattavia huolia."
• p=reject — "Verkkotunnuksen omistaja pitää kaikkia tällaisia epäonnistumisia selvänä merkkinä siitä, että verkkotunnuksen käyttäminen ei ole kelvollista."

Lue nuo sanat uudelleen, koska ne ovat heikompia kuin useimmat DMARC-selitykset myöntävät. Käytäntö on mieltymys, jonka lähettäjä on julkaissut vastaanottajien harkittavaksi. Se ei ole käsky, jonka vastaanottaja on velvollinen toteuttamaan. RFC 9989 sanoo sen yhdessä lauseessa: "Minkä tahansa viestin lopullinen käsittely on aina paikallisen käytännön asia ja jätetään postin vastaanottajan harkintaan." Sama jakso lisää seurauksista molemmat puolet — vastaanottajat "VOIVAT valita hylätä tai karanteeniin ottaa viestin, vaikka se läpäisisi DMARC-todentamisen", ja ne "EIVÄT SAISI hylätä viestejä pelkästään julkaistun 'reject'-käytännön vuoksi", juuri siksi, että laillinen posti, joka lähetetään tavoin, joita DMARC ei voi kuvata, ja postituslistat eivät tuhoudu prosessissa.

Mitä siis p=none todella myöntää? Vähemmän kuin mitä se yleensä syytetään. Määrittelyn omissa termeissä se on Monitoring Mode: verkkotunnuksen omistaja kerää koosteita raportteja ja "ei ilmaise minkään käsittelemieltymystä viesteille, jotka epäonnistuvat DMARC-todentamisessa", kun taas vastaanottaja, joka ottaa DMARC:n käyttöön, "voi silti" validoida verkkotunnuksen käyttöä. Mitä se ei tee, se ei kytke mitään pois vastaanottopäästä. Palveluntarjoajasi roskapostinsuodatin, maine-pisteytys, URL-tarkistukset ja liitteiden analyysi ovat erillisiä koneita, jotka toimivat riippumatta siitä, mitä lähettäjä julkaisi. Väärennety viesti, joka saapuu p=none-verkkotunnukselle, ei noussuodi postituslistallesi tietueella; se yksinkertaisesti luovutetaan vastaanottajalle ilman ilmaistua mieltymystä, ja vastaanottaja päättää.

Väärinkäsityksen toinen puoli kulkee vastakkaiseen suuntaan. DMARC ei lue kalastelu-sähköpostin vaarallista osaa. Sen omassa määrittelyssä on lueteltu, mikä on tarkoituksellisesti poissuljettu alueesta, ja "sisältöanalyysi" on kyseisellä luettelolla. Se myös ilmoittaa, että DMARC "ei käsittele visuaalisesti samanlaisten verkkotunnusten tai RFC5322.From ihmisten luettavissa olevan näyttönimen väärinkäyttöä" — kaksi temppua, joka kuljettaa enemmän tuotemerkin jäljittelypostia. Ja läpimenyn arvosta: "DMARC-läpimeno itsessään ei takaa, että toimitus vastaanottajan saapuville kirjeille olisi turvallista tai toivottavaa." Oikein todentamaton viesti hetkellisestä verkkotunnuksesta läpäisee DMARC:n puhtaasti. DMARC vastaa siihen, kuka oli valtuutettu käyttämään verkkotunnusta From-otsikossa. Ei mitään muuta.

Tässä on kohta, jossa vuoden 2024 joukkomunistensäännöt raportoidaan säännöllisesti väärin, myös tämän artikkelin ensimmäisessä versiossa. Google:n lähettäjäohjeet vaativat 5 000 tai useampaa viestiä päivässä Gmail-tileille lähettäviä lähettäjiä "Asettaa DMARC-sähköpostin todentamisen lähettämiseesi verkkotunnukselle", ja sitten sanotaan samalla henellä: "DMARC-täytäntöönpanokäytäntösi voidaan asettaa arvoon none." Yahoo:n oma Sender Hub, joka on luettava erikseen eikä oletetaan kopioivan Google:ta, esittää vaatimuksen "Julkaise kelvollinen DMARC-käytäntö, jossa on vähintään p=none - DMARC:n on läpäistävä", eikä julkaise numeerista volyymikynnysta ollenkaan. Molemmat vaatimusjoukot tulivat voimaan helmikuussa 2024. Kumpikaan ei pakota ketään pois p=none-arvosta. Mitä molemmat todellisuudessa pakottavat on todentamista, joka samaistuu: Google vaatii, että "lähettäjän From-otsikon verkkotunnus on samaistettava joko SPF-verkkotunnukseen tai DKIM-verkkotunnukseen", ja Yahoo sanoo, että rento samaistus on hyväksyttävä. Samaistuminen, ei vakavuus, on portti.

Mikä jättää todellisen syyn siihen, miksi verkkotunnukset istuvat monitoroinnissa, ja se on operatiivinen eikä pelkuri. Siirtyminen kohti quarantine-arvoa tai reject-arvoa tarkoittaa ensin jokaisen palvelun etsimistä, joka lähettää postia sinun nimissäsi — palkanlaskenta, lipunmyynti, markkinointi, dokumentoimaton support-pöytä — ja kunkin todentamista, jotta se samaistuu. Standardi itse tunnustaa vaarat, jotka tekevät tämän hitaaksi: kolmannen osapuolen lähettäjiä ei esitellä eikä sulkea pois DMARC:lla, välitys ja postituslistat voivat rikkoa samaistumisen ilman lähettäjän virhettä, ja määritys osoittaa vastaanottajille RFC 7960:een juuri näille vikamuodoille. Organisaatio, joka julkaisee p=none-arvon ja lukee sen raportteja, tekee työn järjestyksessä, jossa määritys sitä kuvaa. Organisaatio, joka julkaisee p=none-arvon ja jättää raportit huomiotta, ei tee sitä. Ulkoapäin katsottuna tietue yksin ei voi kertoa sinulle, kumpi näistä kahdesta olet katsomassa.

Et tarvitse päätettä katsomiseen. Ilmaiset hakutyökalut — dmarcian:n verkkotunnuspalvelu, MXToolboxin DMARC-tarkistus — noutavat tietueista ja tulostavat käytännön sinulle. Tee se pankkillesi, palkanlaskentapalveluntarjoajallesi, lentoyhtiölle, jolla lentää. Vain lue vastaus siitä, mitä se on: verkkotunnuksen omistajan intentiotilanne, yksi panosta monesta päätökseen, jonka postintarjoajasi tekee itsenäisesti, yhdestä tietystä väärennöstyypistä. Se on todella hyödyllinen asia, jota voi lukea kymmenessä sekunnissa. Se ei ole tuomio siitä, onko seuraava viesti, joka väittää olevan kyseiseltä tuotemerkiltä, turvallinen.

Korjaus, 20. lokakuuta 2026. Tämän artikkelin aikaisemmassa versiossa p=none-arvo kuvattiin väärennösten toimittamiseksi saapuville kirjeille ja p=reject ainoaksi asetukseksi, joka estää väärennetyn viestin, sanoi, että vuoden 2024 Google:n ja Yahoo:n joukkomunistensäännöt pakottivat lähettäjät pois p=none-arvosta, ja mainitsi noin yhden kolmasosan verkkotunnuksista täytäntöönpanossa. Käytäntöjen kuvaukset on korjattu RFC 9989:ään; Google ja Yahoo hyväksyvät todellisuudessa p=none-arvon, kuten edellä on lainattu niiden omasta dokumentaatiosta; ja täytäntöönpanoluku on poistettu, koska taustalla oleva raportti ei julkaise sen näytettä tai nimittäjää. Artikkelissa kerrotaan nyt myös siitä, mitä DMARC ei tutki.