Tietoturva

Suojattu sähköposti: SPF, DKIM ja DMARC suomalaisen pk-yrityksen opas

Suojattu sähköposti vaatii SPF, DKIM ja DMARC -tietueet. PowerDMARC 2026: vain 8,9 % suomalaisista domaineista on DMARC-suojattu. Vaiheittainen opas pk-yrittäjälle, p=reject 90 päivässä.

Olli Junes · · 10 min

Yrittäjä avaa puhelimen tiistaiaamuna. Pitkäaikainen tavarantoimittaja kysyy hämmentyneenä, miksi hänelle on lähetetty viesti firman domainista, jossa pyydetään maksamaan 6 200 euroa uudelle IBAN-tilille. Yrittäjä ei ole lähettänyt mitään. Joku muu on. Domainia käytettiin, koska sen sähköpostia ei oltu konfiguroitu suojattavaksi.

Sähköpostiosoite ei ole turvallinen pelkän olemassaolonsa nojalla. Suojaaminen vaatii kolme DNS-tietuetta: SPF, DKIM ja DMARC. Mikään niistä ei näy postilaatikossa, mutta jokainen niistä päättää, pääseekö huijausviesti perille sinun nimissäsi. Alla käydään läpi, mitä kukin tietue tekee, miksi suurin osa suomalaisista pk-yrityksistä on niitä vailla ja miten ne otetaan käyttöön ilman että aito sähköposti hajoaa matkalla.

SPF — kuka saa lähettää sinun nimissäsi

SPF eli Sender Policy Framework on DNS-tietue, joka listaa palvelimet ja palvelut, joilla on lupa lähettää sähköpostia sinun domainisi nimellä. Kun vastaanottava palvelin (Gmail, Outlook, suomalainen sähköpostioperaattori) saa viestin, joka väittää olevansa [email protected], se tarkistaa yritys.fi-domainin SPF-tietueen. Jos lähettävä IP-osoite ei ole listassa, viesti merkitään epäilyttäväksi.

Tietue näyttää tältä:

yritys.fi.  IN  TXT  "v=spf1 include:_spf.hosting.fi -all"

Tärkein osa on loppupääte. -all tarkoittaa, että muualta tulevat viestit hylätään. ~all tarkoittaa, että ne merkitään epäilyttäviksi mutta päästetään läpi. +all tarkoittaa, että kuka tahansa saa lähettää viestejä sinun nimissäsi, eikä sitä pitäisi koskaan nähdä missään.

SPF on välttämätön, mutta yksin riittämätön. Se tarkistaa vain lähettävän palvelimen IP-osoitteen. Se ei tarkista, onko viestin sisältö muuttunut matkalla, eikä se kestä sähköpostin edelleenlähetystä. SPF rikkoutuu joka kerta kun joku uudelleenohjaa viestisi toiseen postilaatikkoon.

DKIM — kryptografinen sinetti viestissä

DKIM eli DomainKeys Identified Mail lisää jokaiseen lähtevään viestiin allekirjoituksen. Lähettävä palvelin allekirjoittaa viestin yksityisellä avaimella, ja julkinen avain on saatavilla domainisi DNS-tietueena. Vastaanottava palvelin hakee julkisen avaimen ja tarkistaa, että allekirjoitus täsmää viestin sisältöön.

Jos joku muuttaa viestiä matkalla, esimerkiksi vaihtaa IBAN-numeron tai lisää linkin, DKIM-tarkistus epäonnistuu. Allekirjoitusta ei voi väärentää ilman pääsyä yksityiseen avaimeen, joka pysyy lähettävällä palvelimella.

DKIM-julkinen avain on DNS-tietue muotoa:

selector1._domainkey.yritys.fi.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Selector-osa (esim. selector1) sallii useamman avaimen rinnakkain. Käytännössä jokainen lähettävä järjestelmä, kuten sähköpostipalvelin, markkinointityökalu tai asiakaspalveluohjelmisto, tarvitsee oman selectorinsa ja avainparin.

DMARC — politiikka joka sitoo SPF:n ja DKIM:n yhteen

SPF ja DKIM ovat tarkistuksia. DMARC on politiikka, joka kertoo vastaanottavalle palvelimelle, mitä tehdä silloin kun tarkistus epäonnistuu. Ilman DMARC:ia jokainen vastaanottava palvelin tekee oman päätöksensä, ja useimmiten päätös on "päästetään perille".

DMARC-tietue julkaistaan domainin alidomainissa _dmarc:

_dmarc.yritys.fi.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

Tärkeä osa on p=-tunniste, joka voi saada kolme arvoa:

  • p=none — tarkkailutila. Epäonnistuneet viestit menevät perille, mutta raportit lähetetään domain-omistajalle. Tarkoitettu vain alkuvaiheen datan keräykseen.
  • p=quarantine — epäonnistuneet viestit ohjataan vastaanottajan roskapostikansioon.
  • p=reject — epäonnistuneet viestit hylätään ennen perille tuloa. Vastaanottaja ei näe niitä lainkaan.

Vain p=reject on todellinen suoja. Muut asetukset ovat välivaiheita.

Suomen tilanne 2026 — luvut joista ei puhuta

PowerDMARC:n raportoinnin mukaan DMARC-käyttöönottoaste Suomessa on noin 8,9 prosenttia kaikista domaineista. Yli yhdeksän kymmenestä suomalaisesta verkkotunnuksesta ei siis suojaa itseään lainkaan sähköpostiväärennöksiltä. PowerDMARC:n helmikuun 2024 otoksessa (715 suomalaista domainia) 54,13 prosenttia oli kokonaan ilman DMARC-tietuetta ja 39 prosenttia ilman SPF:ää. Otos on lähes kaksi vuotta vanha, mutta sen jälkeen julkaistut tarkemmat luvut osoittavat samaa suuntaa: suojaus jää tekemättä, ja jos se tehdään, se jätetään puoliväliin.

Maailmanlaajuisesti vain 11,2 prosenttia domaineista on täydessä p=reject-suojassa. Suomessa luku on PowerDMARC:n helmikuun 2024 otoksen perusteella 10,07 prosenttia. Loput julkaistuista DMARC-tietueista ovat p=none- tai p=quarantine-tilassa, jotka eivät hylkää huijausviestejä.

Konkreettisesti tämä tarkoittaa: jos lähetät asiakkaalle laskun ja hänelle saapuu samana päivänä rikollisen lähettämä toinen lasku saman domainin nimissä, asiakkaan postilaatikko ei pysty erottamaan niitä toisistaan. Molemmat näyttävät tulevan sinulta. Vain DMARC p=reject -politiikka olisi estänyt väärän viestin perille tulon.

Logistiikkasektori 80 prosenttia paljaana

PowerDMARC:n samassa helmikuun 2024 otoksessa logistiikka-ala oli erityisen heikossa kunnossa: 80,29 prosenttia logistiikkasektorin suomalaisista domaineista oli ilman SPF-tietuetta. Sama kuvio toistuu rakennusalalla ja autokorjaamoissa, samoin terveyspalveluissa, joissa IT-konfiguraatio on yhden ulkopuolisen kumppanin vastuulla eikä sitä päivitetä, ellei joku erikseen pyydä.

NIS2 ja sähköpostin tietoturva

Suomen kyberturvallisuuslaki 124/2025 astui voimaan 8.4.2025. Se panee toimeen EU:n NIS2-direktiivin ja laajentaa kyberturvallisuusvelvoitteet kattamaan tuhansia suomalaisia organisaatioita, joiden ei aiemmin ole tarvinnut raportoida poikkeamia tai osoittaa riittäviä teknisiä toimia. Suoraan lain piirissä ovat ensi sijassa keskisuuret ja suuret toimijat keskeisillä toimialoilla (energia, liikenne, vesi, terveys, digitaaliset palvelut, hallinto), mutta laki kasvattaa myös niiden alihankkijoiden tosiasiallista vastuuta, eli kaikkien pk-yritysten, jotka toimittavat palveluita näille kohteille.

Lain mukaan organisaation pitää toteuttaa "kohtuulliset ja oikeasuhteiset" tekniset ja organisatoriset toimenpiteet. Vuonna 2026 SPF, DKIM ja DMARC p=reject -tasolla kuuluvat kohtuullisten toimien minimitasoon. Niiden toteuttaminen on ilmaista ja teknisesti suoraviivaista. Niiden tekemättä jättäminen on vaikea perustella, jos viranomainen kysyy syytä toimittajaketjun BEC-tappiolle.

Hallintovastuu on viime kädessä CEO:lla ja hallituksella. Vastaamo-tapauksen käräjäoikeuden langettava tuomio purkautui hovioikeudessa, ja Ville Tapio vapautettiin syytteistä, mutta NIS2-aikakaudella vastuu on rakennettu lain rakenteeseen tavalla, joka ei jätä yhtä paljon tulkinnanvaraa.

Yleisimmät virheet — miksi tietueet eivät toimi

Yleisin yksittäinen syy DMARC:in epäonnistumiseen on, että tietue jää p=none-tilaan pysyvästi. Eräässä laajassa otoksessa 68 prosenttia olemassa olevista DMARC-tietueista käytti p=none-asetusta. Tietue on teknisesti olemassa, sähköpostiraportit kilahtavat domain-omistajan postilaatikkoon, mutta huijausviestit menevät edelleen läpi. Asetus jätetään välivaiheeseen, koska siirtymä p=quarantine-asetukseen vaatii työtä eikä kukaan ehdi.

Toiseksi yleisin virhe on v=DMARC1-versiotunnisteen puuttuminen tai kirjoitusvirhe sen alussa. Tämän takia 94 prosenttia virheellisistä DMARC-tietueista hylätään vastaanottavan palvelimen toimesta, koska tietuetta ei tunnisteta lainkaan DMARC-tietueeksi, vaikka siinä lukisi p=reject. Kolmas yleinen virhe on saman domainin alle julkaistut useat DMARC-tietueet. Vastaanottava palvelin näkee monta tietuetta, ei osaa valita oikeaa ja jättää koko politiikan huomiotta.

Markkinointityökalut ovat oma sudenkuoppansa. Yritys ottaa käyttöön Mailchimpin, HubSpotin tai Brevon, mutta unohtaa lisätä niiden lähetyspalvelimet SPF-tietueeseen ja konfiguroida DKIM-allekirjoituksen omalla domainilla. DMARC p=reject -asetuksen jälkeen kampanjasähköpostit alkavat hylkääntyä, ja markkinointitiimi paniikkivetää koko DMARC-politiikan takaisin tarkkailutilaan. Ongelma ei ole DMARC, vaan se että lähettäviä järjestelmiä ei kartoitettu kunnolla ennen siirtymää.

Käytännön implementointi — 90 päivän siirtymä

Suojauksen rakentaminen kestää käytännössä noin kolme kuukautta, koska väliin tarvitaan oikean sähköpostiliikenteen havainnointia. Aikataulu voi olla nopeampi, jos yrityksellä on vain yksi sähköpostijärjestelmä eikä erillisiä markkinointi- tai laskutusalustoja.

Päivät 1–7 — kartoitus

Listaa kaikki järjestelmät, jotka lähettävät sähköpostia domainisi nimissä: sähköpostipalvelin (Microsoft 365, Google Workspace, oma palvelin), markkinointityökalut, asiakaspalveluohjelmistot, laskutusjärjestelmät, verkkokaupan tilausvahvistukset, ulkoiset CRM:t. Tämä on yleisimmin se vaihe, jossa unohtuu jokin. Tarkista vanhat sopimukset ja kysy laskutuksesta, mille palveluille maksetaan kuukausittain.

Päivät 8–14 — SPF ja DKIM käyttöön

Julkaise SPF-tietue, joka sisältää jokaisen kartoitetun lähettäjän. Esimerkki Microsoft 365:n ja Mailchimpin yhdistelmästä:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all

Konfiguroi DKIM erikseen jokaiselle lähettävälle järjestelmälle. Sähköpostipalveluntarjoaja ja markkinointityökalut antavat ohjeet, ja DNS-tietueiden julkaisu vie 5–10 minuuttia per palvelu. Kestää muutaman tunnin, kunnes DNS päivittyy globaalisti.

Päivät 15–30 — DMARC tarkkailutilaan

Julkaise DMARC-tietue p=none-asetuksella ja raporttiosoitteella:

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]

Sähköposteja alkaa tulla parin päivän sisällä. Raportit ovat XML-muotoisia, joten käytä työkalua kuten dmarcian.com tai PowerDMARC visualisointiin. Etsi raporteista lähettäjiä, joita et tunnista. Ne ovat joko kartoituksessa unohtuneita laillisia palveluita tai jo käynnissä olevaa huijausta sinun nimissäsi.

Päivät 31–60 — korjaa puutteet

Lisää löytämäsi lailliset lähettäjät SPF-tietueeseen ja konfiguroi niille DKIM. Tämä on vaihe, joka vaatii eniten työtä, koska markkinointityökalujen oma konfiguraatio on usein puutteellinen. Tavoite on, että DMARC-raporteissa ei näy yhtään SPF- tai DKIM-epäonnistumista laillisilta lähettäjiltä.

Päivät 61–80 — quarantine

Kun raportit ovat puhtaita, vaihda politiikka:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Seuraa kahden viikon ajan, ettei aitoja viestejä päädy roskapostiin. Kysy isoimmilta asiakkailta ja toimittajilta, ovatko huomanneet ongelmia.

Päivä 90 — reject

Jos quarantine-vaihe meni puhtaasti, siirry lopulliseen tilaan:

v=DMARC1; p=reject; rua=mailto:[email protected]

Tästä eteenpäin huijausviestit hylätään ennen kuin ne ehtivät asiakkaasi postilaatikkoon. Jatka raporttien seurantaa kuukausittain. Uudet lähettävät järjestelmät tai infrastruktuurimuutokset näkyvät raporteissa ennen kuin ne aiheuttavat ongelmia.

Miksi yhden oven malli ratkaisee tämän

Yhdeksän kymmenestä pk-yrityksestä jättää DMARC:in tekemättä, koska siirtymä vaatii kolme kuukautta, viittä eri järjestelmää, DNS-osaamista ja jatkuvaa raporttien seurantaa. Vaihtoehdoksi jää joko ostaa erikoiskonsultti tai jättää tekemättä. Useimmat jättävät tekemättä.

Resahost-paketissa SPF, DKIM ja DMARC konfiguroidaan domain-käyttöönoton yhteydessä, ja siirtymä p=reject-tasolle viedään läpi 90 päivän aikana ilman että yrittäjä joutuu seuraamaan raportteja. Markkinointityökalujen ja muiden lähettäjien lisäys tapahtuu hosting-tuen kautta, ja DMARC-raportit analysoidaan keskitetysti. Yhden oven malli tarkoittaa tässä sitä, että sama taho, joka hostaa sivustosi, vastaa myös siitä että sähköpostisi ei päädy huijareiden työkaluksi. Sama logiikka koskee DDoS- ja DMARC-suojausta yhdessä, eli kahta näkymätöntä aukkoa, jotka kuuluvat saman paketin alle.

Sähköpostin perustietoturva on yksi osa kokonaisuutta. Salattu sähköposti TLS- ja päästä päähän -tasolla käsittelee viestien luottamuksellisuutta matkalla, ja sähköpostin hinnoittelu omalla domainilla kertoo mitä koko paketti maksaa kuukaudessa.

Jos sähköpostiasi käytetään väärin juuri nyt

Jos saat asiakkaalta soiton tai vinkin, että nimissäsi on lähetetty huijausviesti, tee neljä asiaa heti:

  1. Pyydä asiakkaalta alkuperäinen viesti raakamuodossa (Gmail: "näytä alkuperäinen", Outlook: "näytä viestin lähde"). Älä luota välityskaappaukseen.
  2. Tarkista oma SPF-, DKIM- ja DMARC-tilanne osoitteessa dmarcian.com tai vastaavassa työkalussa. Jos tietueet puuttuvat, aloita käyttöönotto välittömästi p=none-tilassa.
  3. Ota yhteyttä omaan hosting- tai sähköpostipalveluntarjoajaasi. Jos huijaus on jatkuvaa, he voivat estää kyseisten lähettäjien IP-osoitteet ja raportoida ne eteenpäin.
  4. Jos asiakas ehti maksaa huijaustilille, ohjaa hänet ottamaan yhteyttä omaan pankkiinsa ja tekemään rikosilmoituksen poliisille. Mitä nopeammin pankki saa tiedon, sitä todennäköisemmin maksu voidaan jäädyttää.

Maksuton domain-audit resahost.net-etusivulta näyttää SPF-, DKIM-, DMARC-, MTA-STS- ja DNSSEC-tilanteen sekä kertoo selkokielellä, mitä korjattavaa on ja kuinka kauan korjaus kestää. Raportti tulee alle vuorokaudessa, ja sen perusteella voit päättää itse, hoidatko korjaukset nykyisen palveluntarjoajan kanssa vai siirrätkö paketin yhden katon alle.