Mitä SPF, DKIM ja DMARC tarkoittavat kylmän B2B-sähköpostin kannalta
Jos kylmät myyntiviestisi päätyvät roskapostiin tai eivät koskaan tule perille, syy on usein tekninen eikä sisällöllinen. SPF, DKIM ja DMARC ovat kolme DNS-tietuetta, jotka todistavat vastaanottavalle palvelimelle, että viesti todella tulee sinun domainiltasi eikä ole väärennetty. Tämä artikkeli selittää lyhyesti mitä kukin tietue tekee ja miten tarkistat, että omat asetuksesi ovat kunnossa ennen kampanjan käynnistämistä.
- SPF kertoo, mitkä palvelimet saavat lähettää viestejä domainisi nimissä.
- DKIM allekirjoittaa viestin digitaalisesti, joten sitä ei voi muokata matkalla.
- DMARC yhdistää SPF:n ja DKIM:n ja määrää, mitä epäonnistuneille viesteille tehdään.
- Ilman kaikkia kolmea kylmä B2B-sähköposti näyttää suodattimille aina epäilyttävältä.
- Tietueet kannattaa testata ennen kampanjaa, ei vasta kun toimitusaste romahtaa.
Miksi kylmä B2B-sähköposti kaatuu ilman oikeita DNS-tietueita
Tavallinen liikekirjeenvaihto kulkee tuttujen domainien välillä, joilla on jo pitkä historia keskenään — Gmail tai Outlook on nähnyt viestejä samalta lähettäjältä ennenkin. Kylmässä B2B-sähköpostissa tilanne on päinvastainen: vastaanottajan palvelin ei ole koskaan nähnyt domainiasi, eikä vastaanottaja ole pyytänyt viestiä. Suodatin joutuu siis päättämään luotettavuudesta pelkkien teknisten signaalien perusteella.
SPF, DKIM ja DMARC ovat juuri niitä signaaleja. Ilman niitä Gmail, Outlook ja suomalaiset yritysten omat postipalvelimet näkevät lähettäjän, jota ei voi todentaa — ja epävarmassa tilanteessa filtteri valitsee turvallisemman vaihtoehdon eli roskapostikansion tai suoran hylkäyksen. Tässä mielessä email security spf dkim and dmarc explained -tyyppinen perusymmärrys ei ole ylimääräistä teoriaa, vaan edellytys sille, että kampanja ylipäätään pääsee alkuun.
Luvut ovat suuntaa-antavia, kohdennetun B2B-kampanjoinnin käytännön havaintoihin perustuvia.
SPF: kuka saa lähettää viestejä domainisi nimissä
SPF (Sender Policy Framework) on yksinkertainen DNS-TXT-tietue, joka listaa, mitkä palvelimet saavat lähettää sähköpostia domainisi nimissä. Kun vastaanottava palvelin saa viestin, se tarkistaa lähettävän palvelimen IP-osoitteen domainisi SPF-tietueesta — jos osoite ei ole listalla, viesti epäonnistuu SPF-tarkistuksessa.
Käytännön esimerkki: jos lähetät kylmäpostia LDM:n kautta mutta yrityksesi käyttää myös Google Workspacea sähköpostiin, molemmat lähteet pitää lisätä samaan tietueeseen include-mekanismilla. Yksi domaini voi sisältää vain yhden SPF-tietueen — jos kaksi työkalua on lisännyt oman rivinsä erikseen, tarkistus hajoaa kokonaan. Tämä on yksi yleisimmistä spf dkim dmarc dns records -haussa esiin nousevista ongelmista.
Tyypillinen SPF-tietue voi näyttää tältä: v=spf1 include:_spf.google.com include:sendgrid.net ~all — tämä sallii sekä Google Workspacen että SendGridin lähettää viestejä domainin nimissä, ja ~all merkitsee, että muiden lähteiden viestit merkitään epäilyttäviksi mutta ei automaattisesti hylätä.
DKIM: digitaalinen allekirjoitus jokaiselle lähtevälle viestille
DKIM (DomainKeys Identified Mail) lisää jokaiseen lähtevään viestiin salatun allekirjoituksen, joka perustuu domainiin liitettyyn julkiseen avaimeen DNS:ssä ja lähetyspalvelimen hallussa olevaan yksityiseen avaimeen. Vastaanottaja tarkistaa allekirjoituksen julkisella avaimella ja saa kaksi varmuutta kerralla: viesti todella tuli väitetystä domainista, eikä sen sisältöä ole muutettu matkalla.
Jokaisella lähetysalustalla on oma DKIM-selektorinsa (esimerkiksi ldm._domainkey.yritys.fi), joten jos käytät useampaa työkalua — omaa postipalvelinta ja LDM:ää kylmäpostitukseen — kummallakin pitää olla oma, erikseen luotu DKIM-avainpari. Puuttuva tai väärin asetettu DKIM on erityisen paha kylmäpostitukselle, koska se on juuri se signaali, jolla suodatin erottaa aidon lähettäjän domainin väärentämisestä (spoofing).
DMARC: sääntö, joka yhdistää SPF:n ja DKIM:n
DMARC (Domain-based Message Authentication, Reporting and Conformance) ei tarkista mitään uutta itsessään — se kertoo vastaanottavalle palvelimelle, mitä tehdä, jos viesti epäonnistuu SPF- tai DKIM-tarkistuksessa, tai jos ne eivät ole ns. alignment-tilassa eli eivät vastaa Lähettäjä-kentän domainia. Tietue määrittää politiikan kolmella tasolla: p=none (vain seurataan ja raportoidaan), p=quarantine (epäonnistuneet viestit roskapostiin) ja p=reject (epäonnistuneet viestit hylätään kokonaan).
DMARC-tietue tuo mukanaan myös raportoinnin: rua-parametri määrittää osoitteen, johon Gmail, Microsoft ja muut suuret palveluntarjoajat lähettävät päivittäin koosteen siitä, kuinka moni domainisi nimissä lähetetty viesti läpäisi tai ei läpäissyt tarkistuksia. Aloittelijalle tärkein neuvo: älä hyppää suoraan p=reject-tilaan. Aloita p=none-tilasta, seuraa raportteja pari viikkoa, korjaa mahdolliset SPF/DKIM-puutteet, ja nosta politiikkaa vasta sitten asteittain.
Suuntaa-antava arvio siitä, kuinka suuri osa väärennetyistä tai epäonnistuneista viesteistä estetään kullakin politiikkatasolla.
Miten tarkistat SPF-, DKIM- ja DMARC-tietueet käytännössä
Ennen kampanjan käynnistämistä kannattaa tarkistaa kaikki kolme tietuetta suoraan DNS:stä, ei vain luottaa siihen että joku joskus asetti ne. Tähän ei tarvita ohjelmointitaitoja — komentorivi tai ilmainen selainpohjainen spf dkim dmarc tester riittää.
- dig TXT yritys.fi — tarkistaa SPF-tietueen, pitäisi näkyä yksi rivi joka alkaa v=spf1
- dig TXT selector._domainkey.yritys.fi — tarkistaa DKIM-avaimen, selector vaihtelee lähetysalustan mukaan
- dig TXT _dmarc.yritys.fi — tarkistaa DMARC-politiikan ja raportointiosoitteen
- Lähetä testiviesti omaan Gmail- tai Outlook-tiliin ja avaa viestin otsikkotiedot (Authentication-Results) — sieltä näkee suoraan pass/fail-tuloksen kaikille kolmelle
- Google Postmaster Tools -paneeli näyttää domainin maineen ja spam-valitusten määrän ajan myötä, jos lähetysvolyymi ylittää kynnysarvon
Yleisimmät virheet aloittelevilla lähettäjillä
Suurin osa toimitusongelmista ei johdu siitä, ettei tietueita olisi lainkaan, vaan siitä että ne on asetettu puolittain väärin.
- Kaksi erillistä SPF-tietuetta samalle domainille — vain yksi TXT-rivi voi alkaa v=spf1, kaikki lähteet pitää yhdistää yhteen
- Liian monta DNS-hakua SPF:ssä (yli 10 include-riviä) — moni palvelin hylkää koko tarkistuksen tässä tapauksessa
- DKIM asetettu vain yhdelle lähetysalustalle, vaikka kylmäpostitus tapahtuu toisen työkalun kautta
- DMARC nostettu suoraan p=reject-tilaan ilman seurantajaksoa, jolloin myös laillinen liikenne alkaa hylkääntyä
- Kylmäpostitus samalta domainilta kuin pääasiallinen yritysposti, jolloin yksi huono kampanja vahingoittaa koko brändin mainetta
- Alignment-vaatimuksen unohtaminen: DKIM:n allekirjoittava domain (d=) ei vastaa Lähettäjä-kentän domainia, jolloin DMARC epäonnistuu vaikka SPF ja DKIM erikseen ovat kunnossa
Checklist ennen kylmäpostituskampanjan aloittamista
LDM:ssä emme koskaan käynnistä kylmäpostituskampanjaa asiakkaalle ennen kuin kaikki kolme tietuetta on tarkistettu ja lämmitysjakso käyty läpi. Käytännössä tämä tarkoittaa, että kampanjalle luodaan usein erillinen lähetys-subdomain (esimerkiksi outreach.yritys.fi), joka suojaa pääbrändin mainetta jos jokin menee pieleen alkuvaiheessa, ja jonka SPF, DKIM ja DMARC asetetaan ja testataan ennen ensimmäistäkään lähtevää viestiä.
Sen jälkeen seurataan DMARC-raportteja viikoittain ensimmäisen kuukauden ajan, nostetaan lähetysvolyymia asteittain ja pidetään huoli, että vastausprosentti ja bounce-rate pysyvät terveellä tasolla ennen kuin volyymia kasvatetaan lisää.
- SPF-tietue sisältää kaikki todelliset lähetyslähteet, ei ylimääräisiä rivejä
- DKIM-avain generoitu ja aktiivinen juuri sille alustalle, jota kampanjassa käytetään
- DMARC asetettu p=none-tilaan vähintään viikoksi ennen p=quarantine/reject-nostoa
- Testiviesti lähetetty ja Authentication-Results-otsikko tarkistettu manuaalisesti
- Kylmäpostitus tapahtuu erillisestä subdomainista, ei pääasiallisesta yritysdomainista
- DMARC-raportointiosoite (rua) on olemassa ja jonkun vastuulla lukea
Usein kysytyt kysymykset
Mitä eroa on SPF:llä, DKIM:llä ja DMARC:lla?
SPF kertoo, mitkä palvelimet saavat lähettää domainin nimissä. DKIM allekirjoittaa viestin digitaalisesti, jotta sitä ei voi muuttaa matkalla. DMARC yhdistää nämä kaksi ja määrää, mitä tehdään, jos jompikumpi epäonnistuu.
Riittääkö pelkkä SPF kylmän sähköpostin lähettämiseen?
Ei riitä pitkällä aikavälillä. SPF nostaa toimitusastetta jonkin verran, mutta ilman DKIM:ia ja DMARC:ia suodattimet näkevät viestin edelleen osittain todentamattomana, mikä näkyy heikompana toimitusasteena etenkin isoissa postilaatikoissa kuten Gmail ja Outlook.
Voiko DMARC:n asettaa suoraan p=reject-tilaan?
Ei kannata ilman seurantajaksoa. Jos SPF- tai DKIM-asetuksissa on pieniäkin puutteita, p=reject hylkää myös laillisia viestejä. Aloita p=none-tilasta, tarkista raportit, ja nosta politiikkaa vasta kun tulokset ovat puhtaita.
Miten testaan onko domainini tietueet kunnossa?
Käytä dig-komentoa tai selainpohjaista spf dkim dmarc tester -työkalua tarkistaaksesi kaikki kolme TXT-tietuetta, ja lähetä lisäksi testiviesti omaan Gmail- tai Outlook-tiliin nähdäksesi Authentication-Results-otsikon pass/fail-tuloksen.
Tarvitseeko jokainen lähetysalusta oman DKIM-avaimen?
Kyllä. Jos lähetät sekä omalta postipalvelimeltasi että esimerkiksi LDM:n kautta, molemmilla pitää olla oma DKIM-selektorinsa ja avainparinsa, koska DKIM on sidottu tiettyyn lähetysinfraan eikä vain domainiin yleisesti.
Kannattaako kylmäpostitukseen käyttää erillistä subdomainia?
Yleensä kyllä. Erillinen lähetys-subdomain suojaa pääbrändin sähköpostimainetta, jos kylmäkampanjassa ilmenee toimitusongelmia tai spam-valituksia, eikä pääasiallinen yritysposti kärsi tästä.
Haluatko soveltaa tätä omaan outreach-toimintaasi?
Näytämme ennen töiden aloittamista, miten tämä toimii juuri sinun segmentissäsi ja tuotteessasi.
Keskustele kanssamme