DMARCbis muuttaa miten osat DMARC määritellään ja toteutetaan. Se ei pyydä sinua nimeämään tietueesi uudelleen muotoon DMARC2. Perusspesifikaatio, RFC 9989, julkaistiin toukokuussa 2026, kun RFC 9990 ja RFC 9991 kattavat aggregaatin ja vikaraportoinnin erikseen.
Käytännön tehtävänä on selvittää, mitkä muutokset vaikuttavat verkkotunnukseesi, lähetyspalveluihin ja todennustietojasi käsitteleviin ohjelmistoihin. Se alkaa ymmärtämällä nykyiset tekniset tiedot ja sitten vertaamalla niitä jo käytössä oleviin konfiguraatioihin ja prosesseihin. Tuloksena pitäisi olla selkeä valmiusrekisteri, jossa on todisteet, omistajat ja päätös jokaisesta löydöstä.
Yhdistä kolme eritelmää järjestelmiisi
Käytä nykyisiä asiakirjoja vastaavissa töissään:
| Asiakirja | Mitä arvostella |
|---|---|
| RFC 9989 | DMARC -ydinarviointi, käytäntöjen selvittäminen, linjaus ja tallentaa semantiikkaa |
| RFC 9990 | Aggregaattiraportoinnin muoto, luonti ja käsittely |
| RFC 9991 | Vikailmoitus ja sen käsittelyyn liittyvät näkökohdat |
Aloita olemassa olevasta tietueesta ja määrityshistoriasta. Älä poista käyttötietuetta vain siksi, että vanha opas viittaa siihen RFC 7489. Tunnista muuttuneet ohjeet ja ne toteuttava ohjelmisto.
Tärkeimmät tarkastelualueet ovat seuraavat:
- Verkkotunnuksen löytäminen: RFC 9989 kohta 4.10 määrittää DNS puun kävelyn. Tarkista järjestelmät, jotka olettavat vanhemman julkisen pääteluettelon etsintämallin.
- Käytäntötunnisteet: Tarkista nykyinen IANA rekisteri. The
pct,rfjaritunnisteet ovat historiallisia. Arvioidat,npjapsdniiden todellisen laajuuden perusteella sen sijaan, että lisäisit niitä päivityksen tarkistuslistaksi. - Testaus: Selvitä, kuinka asianomainen arvioija toteuttaa binaarin
tsignaali. Ilmoitettu testaustila ja vastaanottimen lopullinen sijainti ovat eri havaintoja. - Raportointi: Varmista, että kerääjät ja jäsentimet käsittelevät raporttimuotoja ja -kenttiä, joita odotat saavasi menettämättä asiaankuuluvia vanhoja havaintoja.
Versiomerkki jää v=DMARC1. Älä korvaa DMARC2 tai korvata vanha prosenttiosuus mekaanisesti testauslipulla.
Käännä muuttuneet tunnisteet testeiksi
The t lipun oletusarvo on n, joka pyytää ilmoitetun arvioinnin soveltamista DMARC virheisiin. Asetus t=y ilmaisee, että omistaja testaa sen sijaan, että se pyytäisi ilmoitetun arvioinnin soveltamista suoraan. RFC 9989 kohta 4.7 määrittää yhden tason vähennyksen epäonnistuneille viesteille: hylkäämisestä tulee karanteeni ja karanteenista ei mitään. Toteutuksilla voi olla myös asiaankuuluvaa erityiskäsittelyä.
Lippu ei muuta epäonnistunutta todennustulosta hyväksytyksi, muuta raportin luontia tai vaikuta none-käytäntöön. Se on binäärinen, ei pyyntö ottaa näyte mielivaltaisesta prosenttiosuudesta postista. Luo toteutustuki ennen kuin luotat siihen todellisessa liikenteessä ja pidä vastaanottimen paikallinen suodatus erillään käytäntötason testituloksista.
Kaksi muuta tunnistetta vaikuttavat arvioinnin laajuuteen:
- np: Määrittää vallitsevien aliverkkotunnusten arvioinnin organisaation toimialue. Jos sitä ei ole, soveltuva varmistus on sp, kun se on olemassa, muussa tapauksessa p. A puuttuva MX tietue yksin ei vahvista olemattomuutta.
- psd: Merkitsee etsinnässä käytetyt toimialueen rajatiedot. Oletusarvo u jättää rajan määrittämisen etsintäsääntöjen tehtäväksi; y identifioi julkisen päätteen, kun taas n identifioi itselleen ja sen aliverkkotunnuksille ei-julkisen liitteen organisaatiorajan. Älä aseta kumpaakaan nimenomaista raja-arvoa varmistamatta, että se kuvaa verkkoaluetta oikein.
Tavallinen organisaatio ei saisi leimata toimialuettaan julkiseksi päätteeksi vain väittääkseen olevansa valmis. Tarkista todelliset etsintäoletukset ja delegoidut nimitilat. The aliverkkotunnuskäytäntöopas kattaa suppeamman perintökysymyksen.
Tunnista sähköposti, jonka on toimittava edelleen
Verkkotunnus voi edustaa paljon muutakin kuin työntekijän sähköpostia. Se voi näkyä laskuissa, kirjautumislinkeissä, asiakashälytyksissä ja ulkopuolisten tahojen lähettämissä viesteissä. Standardien päivitys tarjoaa mahdollisuuden tarkistaa nämä riippuvuudet ennen kuin nopea konfiguraatiomuutos häiritsee niitä.
Pyydä kolmea tuotetta: luettelo palveluista henkilöllisyytesi avulla, selitys sinuun vaikuttavista erityisistä muutoksista ja testisuunnitelma kriittisille viesteille. Vastauksen tulisi erottaa julkaistu spesifikaatio tietyn vastaanottimen tai ohjelmistopalvelun jo käyttöönottamasta ominaisuudesta.
Jaa omistus ja budjetti. Raportin käsittelyn muutos vaatii jonkun, joka vastaa raportointiprosessista. Lähettäjä, joka ei pysty todentamaan oikein, tarvitsee yrityksen omistajan mukana. Molempien kohteiden kutsuminen DNS päivitykseksi piilottaa työn.
Rakenna valmiusrekisteri
Seuraava on havainnollinen suunnittelurekisteri, ei arvio todellisesta toimialueesta:
| Löytäminen | Työtä tarvitaan | Todiste valmistumisesta |
|---|---|---|
| Käyttöönottoohjeissa oletetaan prosentuaalista otantaa | Testaa binäärilippua käyttämällä alla olevia ohjattuja laitteita | Talletettu ilmoitettu arviointi, arviointi testauslipun jälkeen ja riippumaton vastaanottimen päätös |
| Raportin jäsentäjä olettaa yhden vanhan skeeman | Tarkista hyväksytyt muodot, kentät ja virheiden käsittely | Versioitu kelvollinen, vanha ja virheellisesti muotoiltu kalusteet |
| Kriittisellä sovelluksella ei ole tunnettua omistajaa | Perustaa yrityspalvelu ja tuetut identiteetit | Nimetty omistaja ja vahvistettu vastaanotetun viestin näyte |
| DNS editoria hallitsee ulkoistettu tiimi | Sovi hyväksymis- ja palautusvastuut | Tarkka muutoksen esikatselu, hyväksyntä ja palautusmateriaali |
Seuraavat synteettiset valaisimet määrittelevät odotetut tulokset RFC 9989 ää toteuttavalle kontrolloidulle arvioijalle. Ne ovat testisyötteitä, eivät tuotantotietuemalleja tai jo suoritettuja testejä. Oletetaan, että kelvollinen sovellettava käytäntö on löydetty ja testisanoma epäonnistuu DMARC .
| Teline | Syöte | Odotettu politiikkatason havainto |
|---|---|---|
| Testauslippu | p=reject; t=y | Validointi epäonnistuu; t=y jälkeinen arviointi on karanteeni, eikä ilmoitettu hylkääminen |
| Lippu ei missään | p=none; t=y | Lippu jättää none-arvioinnin ja raportin luomiskäyttäytymisen ennalleen |
| Olematon lapsi | Vallitsevassa organisaatio-aluepolitiikassa on p=none; sp=quarantine; np=reject, oletusarvolla t=n; lapsi on todettu olemattomaksi, eikä hänellä ole suoraa politiikkaa | Sovellettava lapsiarvio on hylättävä olemassa olevan lapsen sp-arvon sijaan |
Tallenna arvioijan versio, syöte, havaittu validointi, valittu arviointi ja mahdollinen lopullinen käsittely erikseen. Ohjattu valaisin määrittää testatun käyttäytymisen; se ei todista, että jokainen Internet-vastaanotin toteuttaa samoja sääntöjä. Käytäntötason karanteenihavainto ei ole yleinen lupaus roskapostikansioiden sijoittamisesta.
Tarkista myös käytännön soveltuvuus. RFC 9989 kohta 7.4 ei suosittele yleiskäyttöisten sähköpostiverkkotunnusten hylkäämistä, koska lailliset epäsuorat reitit, mukaan lukien postituslistat, voivat katketa. Valmiusarvioinnissa olisi yksilöitävä kyseiset reitit ja arvioitava sovellettavat yhteentoimivuusohjeet ennen vahvemman politiikan ehdottamista.
Pidä konfiguraatiomuutokset erillään ohjelmisto- tai prosessimuutoksista. Jotkut löydöt eivät vaadi välitöntä DNS muokkausta. Toiset vaativat palveluntarjoajan päivityksen, jäsentimen korjauksen tai kontrolloidun toteutustestin.
Tarkista yhteentoimivuus ja valmiusvaatimuksen rajat
Valmiusvaatimuksen tulee nimetä sen laajuus. Kattaako se verkkotunnussalkun, politiikan arvioijan, raporttien käsittelijän vai vain ennätys tarkistaa? Nämä ovat erilaisia arvioita.
Käytä rekisteriä toteutusversioiden ja ratkaisemattomien erojen seuraamiseen. Valitse soveltuvat tapaukset olemassa olevista ja olemattomista aliverkkotunnuksista, kohdistustiloista, epäsuorasta postista ja DNS virheistä.
Käsittele vastaanottimen harkintaa osana toimintamallia. Erittelyn julkaiseminen ei saa jokaista vastaanotinta käyttäytymään samalla tavalla. Julkaistu hylkäysasetus ei myöskään ole todiste siitä, että jokainen vastaanottaja hylkäsi jokaisen epäonnistuneen viestin.
Säilytä riippumattomia valvontaa vaarantuneiden tilien, harhaanjohtavien näyttönimien, samankaltaisten verkkotunnusten ja arkaluonteisten yritysten hyväksyntöjen suhteen. DMARC valmius ei muuta verkkotunnuksen todennusta tuomioksi viestin sisällön turvallisuudesta.
Tee ja vahvista vaaditut muutokset
Ennen tuotannon muutosta säilytä edellinen tila, tunnista vaikuttaneet virrat, hanki asianmukainen hyväksyntä ja määritä talteenottoehdot. Tarkista sitten sekä julkaistut asetukset että edustavat viestit koko lähetysreitin kautta.
Jos tulos on erilainen kuin odotettu käyttäytyminen, keskeytä laajennus muihin toimialueisiin ja ratkaise tai hyväksy yhteensopivuushavainto.
Käytä taustalla oleville identiteeteille kohdistusdiagnoosiopas. Alkukokoonpanon saat seuraavasti DMARC luonti- ja vahvistustyönkulku. Käytä raportointitasolle koontiraportin esittely.
Käytännön takeaway
Sulje arviointi, kun jokaisella soveltuvalla löydöllä on omistaja, tuettu päätös ja toistettava näyttö. Pidä ratkaisemattomat toteutuserot näkyvissä, tarkista kriittiset viestit ja raporttien käsittely sekä säilytä hyväksytyt palautusehdot. Valmiusmerkinnän tulee osoittaa kyseiseen tietueeseen, ei korvata sitä.