Dmarc policy none vai reject? Mitä B2B-kylmäpostin lähettäjän kannattaa valita

Moni B2B-lähettäjä julkaisee DMARC-tietueen kerran ja unohtaa sen, jolloin domain jää tasolle p=none eikä se suojaa mitään. Kun kohdennettu kylmäpostikampanja alkaa tuottaa vastauksia ja domain saa näkyvyyttä, myös väärentäjät huomaavat saman domainin – ja ilman quarantine- tai reject-tasoa kukaan ei estä heitä. Tässä käydään läpi, miten dmarc policy nostetaan turvallisesti tasolta none tasolle reject ilman että oma toimitettavuus kärsii.

Miksi dmarc policy on tärkeä osa kylmäpostin toimitettavuutta

Kun auditoin B2B-lähettäjädomaineja, yleisin löydös ei ole puuttuva SPF tai DKIM, vaan dmarc policy not enabled -tilanne: tietue on olemassa, mutta se on jäänyt tasolle p=none, tai koko tietue puuttuu DNS:stä kokonaan. Kumpikaan tilanne ei suojaa domainia miltään – se vain kertoo postilaatikkopalveluille, ettei omistaja ole vielä ottanut kantaa siihen, mitä epäonnistuneille viesteille pitäisi tapahtua.

Kohdennetussa B2B-outreachissa domainin maine on koko kampanjan perusta. Google Workspace ja Microsoft 365 arvioivat lähettävää domainia paitsi sisällön, myös sen perusteella, kuinka hyvin domain on suojattu väärinkäytöltä. Jos joku onnistuu lähettämään roskapostia tai kalasteluviestejä yrityksesi nimissä ilman että dmarc policy reject pysäyttää ne, koko domainin maine – ja sitä myötä oman, laillisen kylmäpostisi perillemeno – kärsii.

p=none, quarantine ja reject – kolme tasoa, kolme eri suojan astetta

DMARC-tietueessa policy-tagi (p=) määrittää, mitä vastaanottavan palvelimen pitäisi tehdä viestille, joka ei läpäise SPF- tai DKIM-alignmentia. Kolme tasoa muodostavat luonnollisen etenemisjärjestyksen valvonnasta täyteen täytäntöönpanoon.

P=none tarkoittaa pelkkää seurantaa: epäonnistuneet viestit toimitetaan normaalisti, mutta ilmoitetut rua-osoitteet saavat aggregate-raportit siitä, mitkä lähteet lähettävät domainin nimissä. Quarantine ohjaa epäonnistuneet viestit roskapostikansioon – ne eivät katoa, mutta eivät myöskään saavuta vastaanottajaa normaalisti. Reject on tiukin: SMTP-yhteys katkaistaan jo vastaanottopalvelimen tasolla, eikä viesti mene perille lainkaan.

• p=none: kerää dataa, ei vaikuta toimitukseen – hyvä lähtöpiste, huono lopputila
• p=quarantine: epäonnistuneet viestit roskapostiin, pct-parametrilla voi rajata osuuden
• p=reject: väärennetyt viestit hylätään täysin, vaatii että kaikki oikeat lähteet on tunnistettu etukäteen

Näin siirryt vaiheittain tasolta none tasolle reject

Suorat hypyt tasolta none tasolle reject ovat yleisin syy siihen, että legitiimitkin viestit alkavat kadota. Turvallinen polku kulkee seurannan ja pienten pct-askelten kautta.

Ensin dmarc record published p=none-tasolla vähintään pariksi viikoksi, rua-osoite mukaan lukien, jotta aggregate-raportit alkavat kertyä. Tämän jälkeen jokainen raportoitu lähde – oma ESP, CRM, laskutusjärjestelmä, uutiskirjetyökalu – käydään läpi ja varmistetaan, että sillä on joko oma DKIM-avain tai se lähettää SPF:n kattaman IP:n kautta. Vasta kun kaikki tunnetut lähteet läpäisevät alignmentin, siirrytään quarantineen pienellä pct-arvolla ja kasvatetaan sitä viikoittain, ennen kuin lopulta siirrytään rejectiin.

• Viikko 0–2: p=none, rua-raportointi päälle, ei muutoksia toimitukseen
• Viikko 3–4: kaikki lähdejärjestelmät kartoitettu raporteista ja SPF/DKIM korjattu
• Viikko 5–8: p=quarantine, pct=25 → pct=50, tarkkaillaan raportteja edelleen
• Viikko 9–12: pct=100, sitten p=reject kun raporteissa ei enää näy selittämättömiä epäonnistumisia

Yleisimmät virheet, kun dmarc-käytäntöä kiristetään

Suurin osa reject-siirtymän epäonnistumisista ei johdu itse DMARC:sta, vaan siitä, että joku lähettävä järjestelmä on jäänyt kartoittamatta ennen kiristystä.

• Siirtyminen suoraan p=reject-tasolle ilman edeltävää monitorointijaksoa
• Kolmannen osapuolen lähettäjien unohtaminen: laskutusjärjestelmä, HR-työkalu tai uutiskirjepalvelu lähettää domainin nimissä ilman omaa DKIM-avainta
• Subdomainien jättäminen huomiotta – sp-tagi puuttuu, jolloin esimerkiksi mail.yritys.fi jää eri suojaustasolle kuin pääasiallinen domain
• Luullaan, että pelkkä dmarc record published riittää, vaikka rua-raportteja ei koskaan lueta
• SPF- ja DKIM-alignmentin strict/relaxed-erojen sekoittaminen, jolloin subdomainista lähetetty posti epäonnistuu yllättäen

Tarkistuslista ennen reject-tasoa ja miten LDM hoitaa tämän kylmäpostikampanjoissa

Ennen kuin domain viedään reject-tasolle, kannattaa käydä läpi lyhyt tarkistuslista – ja pitää mielessä, että kylmäpostikampanjan lähettävä domain kannattaa usein eriyttää pääbrändin domainista, jotta reputaatioriskit eivät sekoitu.

LDM:n kampanjatyössä jokainen lähettävä domain käy läpi saman polun: ensin p=none-seuranta ja aggregate-raporttien läpikäynti dmarcian domain checkerin tai vastaavan dmarc check toolin avulla, sitten asteittainen pct-nosto quarantineen, ja vasta lopuksi reject – rinnan domainin lämmittämisen ja pienten päivävolyymien kanssa. Sama kuri, jolla vältetään spam-merkintöjä kylmäpostissa, pätee myös DMARC-siirtymään: hitaasti, mitaten, ilman oikoteitä.

• Onko dmarc record published ja rua-osoite toimiva vähintään kahden viikon ajan ennen muutoksia?
• Onko kaikki tunnetut lähdejärjestelmät – ESP, CRM, laskutus, uutiskirje – tunnistettu raporteista?
• Läpäisevätkö kaikki nämä lähteet SPF- tai DKIM-alignmentin omalla avaimellaan?
• Onko subdomainien sp-tagi määritelty erikseen, jos niitä käytetään?
• Nostetaanko pct-arvoa vaiheittain ja tarkkaillaanko raportteja jokaisen nousun jälkeen?

Usein kysytyt kysymykset