DMARC voi katkaista omat viestit – etene valvonnasta estoon

Ota DMARC käyttöön valvonnasta: tarkista ensin SPF ja DKIM, kerää raportit p=none-käytännöllä ja kiristä käsittelyä vasta, kun organisaation omat viestit tunnistuvat oikein. Traficomin Microsoft 365 -suojausohje neuvoo etenemään toimivan SPF:n ja DKIM:n jälkeen valvonnasta p=quarantine- tai p=reject-käytäntöön ympäristön toimivuuden varmistamisen jälkeen.

Ratkaiseva kysymys on, mitkä palvelut lähettävät postia verkkotunnuksellasi. Tavallisen sähköpostipalvelun lisäksi lähettäjänä voi olla esimerkiksi uutiskirjepalvelu, laskutusjärjestelmä tai verkkosivuston ilmoituspalvelu. Jos tarpeellinen viesti ei läpäise DMARCia, tiukempi käytäntö voi siirtää sen roskapostiin tai johtaa hylkäykseen.

Tarkista lähettäjät ja tunnisteiden täsmääminen

Kirjaa jokainen palvelu, joka lähettää viestejä organisaation osoitteista, sekä sen käyttämä näkyvä From-verkkotunnus. Selvitä erikseen, käyttääkö palvelu omaa aliverkkotunnusta ja lähteekö jokin viestityyppi vain harvoin. Esimerkiksi kuukausittain toimiva laskutusjärjestelmä voi jäädä huomaamatta, jos kartoitus perustuu vain tavallisen työviikon liikenteeseen.

SPF tarkistaa viestin teknisen lähettäjäverkkotunnuksen ja lähettävän palvelimen suhteen; DKIM tarkistaa allekirjoituksen. DMARC hyväksyy viestin, kun vähintään toinen tarkistus onnistuu ja sen käyttämä verkkotunnus täsmää näkyvän From-osoitteen verkkotunnukseen DMARCin kohdistussääntöjen mukaan. Täsmääminen voi sallia saman organisaation aliverkkotunnuksen, joten pelkkää merkkijonojen yhtäläisyyttä ei pidä käyttää arviointiin.

Kolmannen osapuolen palvelun viesti voi läpäistä SPF:n palvelun omalla verkkotunnuksella mutta epäonnistua DMARCissa, jos näkyvä From-osoite kuuluu organisaatiolle. Pyydä palvelulta ohje sen oman lähettäjäverkkotunnuksen tai organisaation verkkotunnukseen kohdistuvan DKIM-allekirjoituksen määrittämiseen. Lähetä sen jälkeen koevies­tejä ulkopuolisiin postilaatikoihin ja tarkista viestien tunnistustulokset; DNS-asetuksen näkyminen yksin ei kerro, millaisena vastaanottaja näkee viestin.

Google Workspacen DMARC-ohje edellyttää SPF:n tai DKIM:n käyttöönottoa ennen DMARCia, neuvoo odottamaan 48 tuntia niiden määrittämisen jälkeen ja kehottaa tarkistamaan ulkoiset lähettäjät. Molempien menetelmien toimivuus on hyödyllistä varmistaa: edelleenlähetys voi rikkoa SPF:n, jolloin säilynyt ja verkkotunnukseen täsmäävä DKIM-allekirjoitus voi yhä auttaa viestiä läpäisemään DMARCin.

Perusta raportointi ja julkaise p=none

Luo koosteraporteille erillinen postilaatikko tai käytä palvelua, joka pystyy käsittelemään raportit luettaviksi. Lisää sen osoite DMARC-tietueen rua-kenttään ja varmista, että postia todella saapuu. Jos raportit ohjataan eri organisaation verkkotunnukseen, vastaanottava verkkotunnus tarvitsee lisäksi raporttien vastaanoton sallivan DNS-asetuksen.

Ehdollisessa esimerkissä verkkotunnuksen example.com tietue julkaistaan nimellä _dmarc.example.com ja sen arvo on v=DMARC1; p=none; rua=mailto:[email protected]. Tarkista tallennuksen jälkeen DNS-kyselyllä, että arvo näkyy oikeassa nimessä ja ettei siellä ole kilpailevia DMARC-tietueita. p=none pyytää raportointia muuttamatta viestien käsittelyä DMARC-tuloksen perusteella; vastaanottajan muu roskapostisuodatus toimii edelleen.

Käy koosteista läpi lähettävät lähteet, SPF- ja DKIM-tulokset, verkkotunnusten täsmääminen sekä vastaanottajien ilmoittama käsittely. Yhdistä havainto omaan lähettäjäluetteloon: tuntematon IP-osoite voi kuulua luvalliselle ulkoiselle palvelulle, ja epäonnistuva oma lähetys vaatii korjauksen ennen politiikan kiristämistä. Raportit eivät korvaa kaikkien tärkeiden viestityyppien koetoimitusta, sillä harvoin käytetty palvelu voi puuttua tarkastelujaksolta.

Siirry karanteeniin, kun oma liikenne on tunnistettu

Vaihda p=quarantine-käytäntöön, kun jokainen tiedossa oleva tarpeellinen lähetyslähde läpäisee DMARCin tai sen puute on ensin korjattu. Vertaa muutoksen jälkeisiä raportteja valvontavaiheeseen ja seuraa erityisesti aiemmin epäonnistuneita lähteitä. Pyydä esimerkiksi uutiskirjepalvelusta uusi lähetys, jos sen viestejä lähtee vain kampanjoiden yhteydessä.

Karanteeni ilmaisee vastaanottajalle, että epäonnistuva viesti on käsiteltävä epäilyttävänä; käytännön sijoittelu riippuu vastaanottavasta palvelusta. Seuraavaan vaiheeseen voi siirtyä, kun tarpeellisesta liikenteestä ei jää selittämättömiä DMARC-epäonnistumisia ja tärkeät koejakelut saapuvat tarkoitettuihin postilaatikoihin. Tarkista myös aliverkkotunnusten lähettäjät ennen muutosta, sillä pääverkkotunnuksen käytäntö voi vaikuttaa niihinkin.

Arvioi hylkäys myös edelleenlähetysten kannalta

p=reject on perusteltu vain, jos oman postin tunnistus kestää myös käytössä olevat poikkeavat toimitusreitit. Edelleenlähetyksessä lähettävä palvelin vaihtuu ja SPF voi epäonnistua; postituslista voi puolestaan muuttaa viestiä niin, ettei alkuperäinen DKIM-allekirjoitus enää kelpaa. Selvitä siksi, lähettävätkö käyttäjät organisaation osoitteista postituslistoille ja mitä niiden kautta kulkeville viesteille tapahtuu.

DMARC-määrittely RFC 9989 varoittaa p=reject-käytännön yhteensopivuusongelmista postituslistoilla ja suosittelee tällaisia lähettäjiä sisältäville verkkotunnuksille vähintään kuukauden valvontaa sekä yhtä pitkää karanteenivaihetta ennen hylkäyksen harkintaa. Määrittely poisti myös vanhoissa ohjeissa esiintyvän pct-tunnisteen, joten kiristystä ei kannata rakentaa sen varaan. Jos postituslistojen vaikutusta ei saada hallintaan, karanteeni voi olla verkkotunnukselle sopivampi pysyvä käytäntö.

Hylkäys on verkkotunnuksen omistajan vastaanottajalle ilmoittama käsittelytoive, ei lupaus kaikkien epäonnistuvien viestien samanlaisesta kohtalosta. Tarkista raporttien lisäksi lähetyspalvelujen virheilmoitukset ja vastaanottajien havainnot. DMARCin läpäisykään ei yksin takaa pääsyä saapuneet-kansioon, koska vastaanottaja arvioi viestin myös muilla perusteilla.

Palauta toimiva käytäntö toimitushäiriössä

Jos tarpeelliset viestit alkavat päätyä roskapostiin tai lähetykset hylätään muutoksen jälkeen, palauta DMARC-tietueeseen edellinen toimiva p-arvo. Tarkista uusi arvo DNS-kyselyllä ja säilytä rua-raportointiosoite, jotta epäonnistuvaa liikennettä voi edelleen seurata. DNS-välimuistit voivat viivästyttää muutoksen näkymistä vastaanottajille.

Selvitä häiriö lähetyslähde kerrallaan. Vertaa epäonnistuneen viestin näkyvää From-verkkotunnusta SPF:n käyttämään lähettäjäverkkotunnukseen ja DKIM-allekirjoituksen d-verkkotunnukseen; tarkista samalla, mikä tunnistus todella hyväksyttiin. Korjaa ulkoisen palvelun asetus, lähetä uusi viesti samaa reittiä ja kiristä käytäntöä uudelleen vasta, kun sekä raportti että koetoimitus osoittavat kyseisen viestityypin toimivan.

Lue myös:

• DMARCin p=reject voi estää oikean postin – ota suojaus käyttöön asteittain
• Hugging Face -mallin latausmäärä voi johtaa harhaan – tarkista nämä tiedot
• WhatsAppin katoava viesti voi säilyä – nämä poikkeukset on tunnettava